Information Security Stack Exchange is a question and answer site for information security professionals. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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 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 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 Sep 1 '12 at 15:57

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

SSL proxy like Charles works only because the browser is cooperating with the proxy. When you installed Charles, Charles installs its certificate in your browser, which allows it to intercept the SSL connection. An attacker would have to truck the use to install its certificate, and this can't be done without the user's knowledge. In other words, since you're telling your browser to trust the intercepting proxy, so it does exactly what you tell it to do. This is not "breaking" SSL, but rather by design. – Lie Ryan Feb 25 '15 at 11:00
You mean "trick the user", not "truck the use", yes, Lie? – Matthew Elvey Jun 27 '15 at 21:51

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”. 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 and not 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”. 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;
  • 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

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

Your Answer


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.