« Home | My SSL-Explorer Questions Answered » | Importing the Geo-Names database into MsSql Server... » | Better Password Management » | Some Things I Currently Think Are Cool » | VMware update » | Trustix + VMware Server » | IE Javascript problem? » | Scott Guthrie's ASP.NET + Atlas Tutorial » | Google Trends » | Microsoft Virtual Labs » 

Sunday, October 08, 2006 

Charles Proxy

Checking out Charles Web Debugging Proxy while I'm having a bit of a look under of the hood of SSL-Explorer. Snooping on an a SSL session works straight out of the box. Must be using a 'man-in-the-middle' method to sit between me an the SSL website.

Yet, when I access https://www.amazon.com via Charles Proxy I get a warning about the certificate. Viewing the certificate 'certification path' shows that the content coming from the proxy has been encrypted with a certificate signed by 'Charles CA Certificate'.

Left: without the proxy. Right: with Charles Proxy.

I know SSL does protect itself against a man-in-the-middle attack - but I don't know exactly how this works. There's an SSL certificate on the server that's been signed by a 'certificate authority (CA)' - and your browser contains public keys of the trusted CAs (IE: Tools -> Options -> Content -> Certificates -> Trusted Root Certification Authorities, Firefox: Tools -> Options -> Advanced -> Security -> View Certificates -> Authorities). How do these pieces fit together to protect against this attack?

More material for a blog post - stay tuned for the update. In the mean time I'll be translating this:

    SSL 3.0 includes support for ephemerally-keyed Diffie-Hellman key-exchange. Since Diffie-Hellman is the only public key algorithm known which can effciently provide perfect forward secrecy, this is an excellent addition to SSL. In a SSL 3.0 Diffie- Hellman key-exchange, the server specifes its Diffie- Hellman exponent as well as the prime modulus and generator. To avoid server-generated trapdoors, the client should be careful to check that the modulus and generator are from a fixed public list of safe values. The well-known man-in-the-middle attack is prevented in SSL 3.0 by requiring the server's Diffie- Hellman exponential to be authenticated.
    (Bruce Schneier - Analysis of the SSL 3.0 Protocol)

Labels: ,

Hi, I'm the author of Charles. I thought I could shed some light on this one!

SSL protects from the man-in-the-middle attack exactly as you've seen it. In order to observe the SSL communication (as Charles does so you can observe it too), Charles has to create a new SSL session with your browser and sign it using its own CA certificate. Unless your CA certificate is trusted by the browser you see a warning as shown, which is how your browser enables you to detect that something is wrong - in this case a man-in-the-middle. Because you're expecting (hopefully!) the man-in-the-middle you can allow it.

I hope that helps!

Kind regards,

Hi Karl, thanks for the detailed comment! I eventually did follow up this 'question' post with a look at the inner workings of SSL : SSL + Man-in-the-Middle

Post a Comment