50

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?

Honey
  • 103
  • 7
bitmoe
  • 601
  • 1
  • 6
  • 3
  • 6
    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
  • 4
    You mean "trick the user", not "truck the use", yes, Lie? – WHO's NoToOldRx4CovidIsMurder Jun 27 '15 at 21:51

2 Answers2

63

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:

Community
  • 1
Gilles 'SO- stop being evil'
  • 50,912
  • 13
  • 120
  • 179
  • I believe nowadays browsers don't allow you to click through anymore. You just get stuck... – Honey Jul 26 '19 at 23:23
  • @Honey That's not the case in my experience. Or rather, it depends on the reason and the browser. I've clicked through to sites with expired certificates recently in Chrome. On the other hands, HSTS violations typically don't allow click-through. I think the major mobile browsers don't allow click-through. – Gilles 'SO- stop being evil' Jul 27 '19 at 06:12
1

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 they 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.

Thomas C. G. de Vilhena
  • 172
  • 7
  • @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. –  Sep 01 '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 01 '12 at 13:55
  • 4
    @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 'SO- stop being evil' Sep 01 '12 at 14:28
  • In step 1, the client is BELIEVING that the server is the proxy. The proxy is the MITM Server-client. The proxy have its own certificate, and the proxy itself is a client to Facebook. Since this proxy is well known by default, Facebook can block it server-side by the way. Client->Proxy have one symmectic key, Proxy->facebook have other symmetric key. And the Proxy itself is a trickedly-trusted CA that can generate certificates on-the-fly for Facebook and all other sites. Next time if your organization told you to use a proxy and to install theirs Root CA, Think TWICE! – Петър Петров Aug 15 '17 at 22:25