||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)