Ssl – Man-in-the-middle attack in the SSL scenario

certificateman-in-the-middlessl

I'm trying to understand how would a man-in-the-middle attack affect my web server.

I have a self-signed certificate. This certificate can be faked through the man-in-the-middle attack, which means that everything that I send from the browser will be intercepted and modified?

If the request gets modified, than it won't be decrypted by the web server since the certificate on the server is different. Is this correct?

The request sent from the browser can be intercepted and may get re-directed, but the data on my server won't be affected, is this correct?

I'm starting to understand the theory behind certificates, but it would be great if someone could provide a real world example of the man-in-the-middle attack and to see what problems it caused.

Thank you

Best Answer

As I stated in my previous answer to your question, man-in-the-middle attacks (if successful) can own all the data passed back and forth for an encrypted channel.

Certs, both self-signed and issued from a trusted root, can be faked, so don't be lulled into a false sense of security if you issue one to your users from a trusted root. The only issue I have to overcome with one issued by a trusted root, is getting your user to accept mine when I've arp-poisoned their computer. If you think about most end users, how easy would this be?

Can you see the problems now?

Once the end-user accepts MY cert, I own the connection from that point forward and all data passes through my machine.

Related Solutions

Ssl – Apache SSL Log Incomplete SSL Handshake

SSL connections have extra options for CustomLog but they're not going to break down the step-by-step connection status. You'll probably want to try LogLevel debug, but that will get you plenty of extra junk to wade through.

Honestly, a better idea for this class would be to demonstrate using the openssl s_server command, since it can be configured to show the step-by-step progress of the SSL state machine, you'll be able to see exactly at what step the client dropped the connection.

Something like

openssl s_server -key [somekey.pem] -cert [somecert.pem] -accept 443 -state -www

When someone connects it'll print off the steps of the connection:

SSL_accept:before/accept initialization
SSL_accept:SSLv3 read client hello A
SSL_accept:SSLv3 write server hello A
SSL_accept:SSLv3 write certificate A
SSL_accept:SSLv3 write key exchange A
SSL_accept:SSLv3 write server done A
SSL_accept:SSLv3 flush data
SSL_accept:SSLv3 read client key exchange A
SSL_accept:SSLv3 read finished A
SSL_accept:SSLv3 write change cipher spec A
SSL_accept:SSLv3 write finished A
SSL_accept:SSLv3 flush data

the -www option makes it print some information when someone actually connects to it with a webbrowser. If the user navigates away without accepting the fake cert, then I'm guessing the connection will be broken somewhere in the middle there.

You can use the openssl s_client command in a similar fashion, though I'm not certain how flexible it is about accepting or not accepting invalid certificates.

Man-in-the-middle attack over internet

This is indeed possible, and called "{BGP|IP|route|prefix} hijacking".

These attacks are however more complicated than a lan mitm, but not very stealth.

On April 8th, 2010, a chinese ISP announced A LOT of prefixes, and this was seen by bgp probes all over the world.

Wired has a good article describing it, and you can also read the wikipedia entry.

Best Answer

Related Solutions

Ssl – Apache SSL Log Incomplete SSL Handshake

Man-in-the-middle attack over internet

Related Topic