Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

I'm new to the realm of HTTP requests and security and all that good stuff, but from what I've read, if you want your requests and responses encrypted, use HTTPS and SSL, and you'll be good. Someone in a previous question posted a link to this app http://www.charlesproxy.com/ which shows that it is actually possible to sniff HTTPS requests, and see the request and response in PLAIN text.

I tried this with the facebook.com login, and I was indeed able to see my username AND password in plain text. It was too easy. What's going on? I thought that was the whole point of HTTPS - to encrypt requests and responses?

share|improve this question

migrated from stackoverflow.com Sep 1 '12 at 15:57

This question came from our site for professional and enthusiast programmers.

2 Answers 2

You can't break https unless you have access to the session symmetric key. In short, https sessions work this way:

  1. Client and server exchange some initial information
  2. Using this information the client is able to authenticate the server, making sure it is trust worth
  3. The client uses the server's public key to send him an encrypted secret
  4. The server decrypts this secret using his private key (only the authenticated server can do that!)
  5. Both the client and the server use the secret to locally generate the session symmetric key
  6. Now the can talk to each other safely because no one else knows their session symmetric key

If some how along the way a third party is able to get access to the shared secret he will also be able to generate the session symmetric key and decrypt the communication.

share|improve this answer
    
@bitmoe: Most likely CharlesProxy comes up in setp 3, providing the client a fake public key instead of the server's authentic public key. Then, CharlesProxy decrypts the secret half-way and encrypts again it using the authentic public key before sending it to the server. Now, all three parties have access to the shared secret and can generate the session symmetric key. –  Thomas C. G. de Vilhena Sep 1 '12 at 13:49
6  
The problem is that step 2 is hard. You need to check if you want to trust the server. SSL is only as strong as your certificate validation. It all comes down to: Do you accept the MitM's certificate as valid. The logic of out current browsers is: Accept if it's signed by a trusted CA or if the user decides to override. –  CodesInChaos Sep 1 '12 at 13:55
3  
@ThomasC.G.deVilhena No, that's not what's going on. In step 1, the client connects to the proxy (that's the definition of the proxy). In step 2, the client accepts the proxy as genuine, that's the hiccup. –  Gilles Sep 1 '12 at 14:28

This is explained in their page on SSL proxying, perhaps not with enough explanations.

A proxy is, by definition, a man-in-the-middle: the client connects to the proxy, and the proxy connects to the server.

SSL does two things:

  • It ensures the confidentiality and integrity of the established connection.
  • It performs some verification of who you are connecting to.

It's the second part that's important, and seemingly broken, here: you're sitting at your browser, and surprised that your browser is connecting to the proxy whereas you expected it to connect to Facebook. Technically, the proxy is not sniffing the HTTPS traffic, it's relaying it.

Your browser knows that it's connected to Facebook because the site has a certificate that says “I am really www.facebook.com”. Public-key cryptography, by means that I will not get into here, ensures that only the holder of the private key can initiate a valid connection with this certificate. That's only half the battle: you only have the server's claim that it really is www.facebook.com and not randomhijacker.com. What your browser does is additionally check that the certificate has been validated by a certificate authority. Your browser or operating system comes with a list of certificate authorities that it trusts. Again, public-key cryptography ensures that only the CA can emit certificates that your browser will accept.

When you connect to the proxy, your browser receives a certificate that says “I am really www.facebook.com”. But this certificate is not signed by a CA that your browser trusts by default. So:

  • either you received a warning about an insecure HTTPS connection, which you clicked through to see the concent at https://www.facebook.com/;
  • or you added the CA that signed the proxy's certificate (“Charles's CA certificate”) to your the list of CAs that your browser trusts.

Either way, you told your browser to trust the proxy. So it does. An SSL connection is not secure if you start trusting random strangers.

Recommended reading for further information:

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.