Can your client or employer read your HTTPS traffic?

So you’re working for a client or employer who doesn’t let you bring your own device for security reasons. This is quite common and makes a lot of sense in several ways. But could they really read your HTTPS browser traffic?

This post was inspired by an unnerving discovery I made after working a few months with a client of mine, many, many years ago. It has affected the way I look at using clients’ computers since.

The padlock icon means nobody’s listening, right?

2017 has seen a global record-high adoption rate of HTTPS on web sites, partly because this grants sites higher rankings on Google and other search engines, but also because starting with the upcoming version of Chrome, any site that doesn’t have TLS (the protocol behind HTTPS) will sport an unflattering “not secure” warning banner in the browser.

Banking, e-commerce and web mail services, to name a few, have had TLS encryption for a long time. And you’d think that this means that no corporate firewall or network administrator could browse your e-mails or read your bank statements. Right?

Without getting too deep into the technical details of public-key cryptography, here’s roughly how TLS (formerly known as SSL) works:

  • Your browser connects to a site, say, login.live.com
  • The web server presents the browser with a certificate, kind of like a photo ID card, that tells your browser that it’s really talking to login.live.com and not a scammer trying to get your password.
  • Just like a photo ID, the certificate has an issuer, an entity that guarantees its authenticity, so you can trace back every site’s certificate to a relatively short list of root certificates. These root certificates are already stored on your computer (probably with the operating system) and are implicitly trusted by your browser.
  • When the browser is happy with the certification path, an encrypted session is established to the remote server.

It’s a lot more complicated and detailed in real life, but for our purposes, this is the jist of it.

Checking the certification path (also known as the certificate hierarchy) varies a little between browsers and operating systems. Here’s a screenshot of Internet Explorer connecting to a TLS-secured site:

Clicking the lock icon in the address field shows that this site has a certificate issued by DigiCert Baltimore Root, which is a trusted root certificate. You can click “View certificates” to see the whole path:

Now, if someone were to put something on the network between your computer and login.live.com, they would not be able to present you with a correct certificate and you would get the classic “certificate is invalid” message, which should raise suspicions if you’re logging in to your Azure dashboard or your online bank.

How someone might be listening

If you wanted to have a proxy server or a firewall inspect your HTTPS traffic, you would have to create your own root certificate, which is relatively easy, and install that as a trusted root certificate on each computer on the network.

That way, the firewall can identify itself as any site it wants to (using the root certificate), establish an HTTPS session with the computer, and in turn establish its own HTTPS session with the site. This is known as a man-in-the-middle (MITM) attack (although I’m sure there’s a cool corporate euphemism for it). Your browser thinks it’s connected to the real deal, but it’s actually only talking to the firewall. The firewall decrypts everything, reads all your traffic, then re-encrypts the stream and passes it on to the web server.

This is pretty common in types of organizations where security is really important, typically defense, law enforcement, some banks, certain national assets and parts of government. Now, obviously, chances are extremely slim that your employer or client is reading your e-mails or eBay purchase history. More likely, the firewall is scanning for viruses and malware that would otherwise sneak in under the cloak of TLS encryption.

How you can tell

There’s no certain way to tell, particularly if you don’t have administrative rights to your workstation. Things you could check:

  • A proxy server might be an indication that somebody’s reading your traffic, but it could just be a proxy server.
  • Look at the certification path of any random site you visit. Compare this with the certification path when browsing from home or your own mobile device. They should match.
  • Also, check the list of trusted root certification authorities on your workstation. On Windows, you can do this by running “certlm.msc” from a command prompt.

There are other measures that are not as easy to identify, like special endpoint software (antivirus suites, etc) that could be running on your computer. Some can be seen and configured, others are well-hidden.

If you’re concerned with your personal privacy, wait until you’re on your own computer before doing online banking, communicating confidential information with other clients, etc. And don’t install a Dropbox client or your personal e-mail account on your workstation. If the information can be read or hacked, someone just might..

References

One thought on “Can your client or employer read your HTTPS traffic?

  1. Pingback: What’s in my backpack | sqlsunday.com

Let me hear your thoughts!

This site uses Akismet to reduce spam. Learn how your comment data is processed.