Tin Isles

The article you are reading has moved! It is now available at: http://blog.tinisles.com/2006/10/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'.

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: networking, web dev