Breaking HTTPS with a Proxy

I have previously discussed other ways to decrpyt HTTPS traffic, such as sslstrip and key logging, but let’s discuss another way.

When you link to a Web site, you’re hopefully using HTTPS and not HTTP. Our Web traffic used to be encrypted using Netscape’s “Secure Sockets Layer version 3 (SSLv3)”; however, due to some inherent weaknesses, we now use an upgraded version of SSLv3, called “Transport Layer Security version 1 (TLSv1).” TLSv1 is a cryptographic protocol responsible for securing communication over a computer network. So, when you login to your bank’s Web site to check your account, you know your communication between you and the Web server is encrypted.

We send a lot of confidential information over the Internet. Excluding the passwords to every single one of your accounts you own (e.g., bank, E-mail, Facebook, Instagram, Snapchat, Twitter, School), there’s a lot of other personal information that travels through these encrypted sessions. Think social security numbers, addresses, phone numbers, pictures, videos, credit card numbers, and so forth. Good thing we have HTTPS, right?

That’s right, but hackers, the government, your employer, or even you can break HTTPS and downgrade its security to nothing. To understand how this works, let’s first see how HTTPS (or TLSv1) works. To get a fundamental understanding of how HTTPS works, all you really need to know is that your Web browser (the client) is negotiating encryption keys with the a server (for example, a Web server) in a way that only the two of you know the keys. This uses a combination of server-side certificates, symmetric encryption, and asymmetric encryption. When it’s all finished, your session with the server is encrypted, and only you and the server know the secret key to decrypt the session.

But, let’s add a proxy server in the middle to intercept your communication between you and the server. That would look something like this:

Proxy servers serve legitimate purposes. They sit between you and another service, such as a Web server. They make requests to services on your behalf, which allows them to perform caching, content filtering, URL filtering, E-mail filtering, etc. Some companies place these proxy servers inside their internal network. Anytime you make a request out onto the Internet, you must go through the proxy server.

To break HTTPS, the intercepting proxy sits between you and the Web server. Now, when you go to a secure Web site, your Web browser never makes a direct connection to the Web server. Instead, the proxy forwards your request to the Web server on your behalf. However, the Web server does not negotiate the encryption keys with you, but with the proxy instead. The proxy receives the Web server’s digital certificate and public key, creates its own symmetric key to encrypt the session, encrypts this newly generated key with the Web server’s public key, and the Web server decrypts it with its private key.

The proxy forwards your Web browser a forged digital certificate that encrypts the communication between you and the proxy. Normally, if a hacker sets up this proxy, you’ll probably notice because your Web browser will notify you that the certificate is invalid. Some people notice this and others don’t. But, if you’re at your office, your company or agency can set up your device to accept the proxy’s certificate as valid. The proxy is now managing the encrypted session between you and the Web server. Since it has the encryption keys, anything you send to the Web server can be decrypted and read in plaintext. This is a more sophisticated way to perform a trusted Man-in-the-Middle (MitM) attack.

Your HTTPS session, which you think is completely confidential, is really HTTP traffic. Does this really matter in a corporate environment? I mean, after all, you shouldn’t be doing anything you’re not supposed to be doing on the company or agency’s network, right? You cannot violate the AUP or network access policies. But, there is a reasonable expectation of privacy, of course. This depends on whether you’ve signed a consent to monitoring form or similar policies that allow your company to decrypt your information. Your company can configure an intercepting proxy if they have the proper security polices in place and have consulted legal counsel before capturing your data.

Steven Vaughan-Nichols, avid technology writer, suggests the NSA could secretly cooperate with major ISPs or top-Web hosting facilities to essentially “wire-tap” and data-mine American citizens’ communication on the Internet. It’s possible. After all, the NSA and AT&T were caught collaborating back in 2006, spying on a massive amount of domestic and foreign Internet traffic.

 

Reference

Vaughan-Nichols, S. J. (2013). How the NSA, and your boss, can intercept and break SSL. CBS Interactive. Retrieved from http://www.zdnet.com/article/chrome-os-could-be-getting-containers-for-running-linux-vms/