Skip to content

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)

{ 2 } Comments