The S In HTTPS

If you’ve ever bought anything online, checked your bank accounts through the app, or logged on to your favorite social media network, you’ve used a technology called SSL/TLS. The S in HTTPS.

SSL/TLS (just to keep it simple, I’ll refer to as SSL) is the technology used to encrypt the communication between your browser and the site you’re visiting.

This is crucial to ensure that malicious actors—like hackers and cybercriminals—don’t see the contents of your web traffic. But like anything to do with cryptography and encryption, there’s a lot of confusion and misunderstanding.

How Do You Know?

As a user, you rely on your browser to indicate whether a site is safe or not. This includes a number of things like checking to make sure it’s not hosting malware, running malicious javascript, and—for secure sites—that the connection is encrypted.

Sadly, due to the complexities of encryption, checking to see if a connection is valid has boiled down to some combination of the traditional lock icon, a green URL/address bar, and the word “secure.” Most browsers also take things a step further and highlight when you’ve landed on a page where the browser can’t verify the encryption.

But what’s happening in the background? What makes a site show as secure?

Certificates

A site that uses HTTPS to deliver content uses a digital certificate to help confirm its identity. A digital certificate contains a lot of information that can be summed up as two really, really big prime numbers (one private, one public) and data that’s designed to help you trust those two numbers.

The numbers are used for a technique called a key exchange. This is a really interesting mathematical process that lets two entities (in this case, you and the site you’re visiting) create a shared secret over a public channel (the internet).

The rest of the data is designed to help you and your browser verify that the site you’re visiting is in fact the site you intended to visit. This is accomplished through a chain of trust that includes the certificate for the site you’re visiting, a certificate authority, and a root certificate trusted by your operating system or browser.

A chain of trust works just like it sounds. The root certificate is verified by a big organization, typically Microsoft, Apple or Mozilla. In turn, they issue signing certificates to a group of certificate authorities. These are the organizations that either sell or give away certificates to site owners.

Site owners prove to the certificate authority that they own the site in question and then get a certificate to use with you, their user.

SSL/TLS certificate trust chain diagram

Weakest Link?

When you visit a secure site, your browser gets the digital certificate from the site in question…say example[.]com. The certificate says that it was issued from CA01. Your browser knows CA01 and trusts it because it’s on the list from MicrosoftAppleMozilla.

After checking with CA01, your browser knows that the certificate it got from example[.]com checks out. This results in the lock icon/green URL in your browser.

Now this system isn’t foolproof. An attack could hijack the name example[.]com and use another certificate that’s just as valid but it’s unlikely. As with any security system, there are tradeoffs in HTTPS, but the balance struck here is a reasonable one.

Except when someone puts their finger on the scales…

US-CERT Alert

Recently the US-CERT (an organization that helps educate users about potential digital security issues and current threats) issued an alert (TA17-075A) meant to highlight issues with a security control often deployed by enterprises.

Surfing the web over an encrypted connection is great for users, but it can lead to some challenges in a corporate environment. As much as banks and apps are using encryption to help users, cybercriminals are also using it to harm users.

When you’re setting up the defences for your enterprise network, it’s not uncommon to deploy technology to intercept HTTPS connections (typically using a web gateway or outbound proxy). The goal here isn’t (usually) to snoop on your users, but to make sure that you can block malware and other malicious content.

To do this, the interception technology adds another link to the chain of trust.

SSL/TLS certificate trust chain diagram with interception

[This technology has been available for quite a while and full disclosure is warranted here, Trend Micro offers products in this category.]

US-CERT raised the alert based on some recently released research from Carnegie Mellon University (CMU). In this study, they looked at a number of products in this category and found that there are some significant issues that could make users less safe while surfing.

Interception Issues

We’ve already seen that there’s a lot of complexity required to show that simple lock/green URL to the user. The CMU study shows that when an interception technology is in play, that simple indicator can be deceiving. It can show users that their surfing is secure when it actually isn’t and that’s the last thing that users or IT security teams want.

CMU sites seven specific issues in their study, but they essentially stem from one particular issue.

SSL/TLS certificate trust chain diagram with interception and issue pointed out

The interception tools either don’t gracefully handle certificate validation errors or don’t validate them at all. Ouch. That defeats the entire trust part of the chain.

Next Steps

The US-CERT advisory recommends testing any interception solution against https://badssl.com/. That’s a fantastic tool that lets you see how your browser handles various SSL/TLS issues. With the interception tool in place, try each of the scenarios and ensure that they’re properly handled.

Furthermore, if you’re rolling out interception technology here are some concrete steps to make it as smooth as possible:

Interception technology can help defend your enterprise from malware and cybercriminals, but it’s not without potential issues (as shown by the US-CERT alert). This is a case where a little planning and forethought can go a long way.

[ Here’s a link to the Trend Micro security bulletin for TA17-075A. At this time, no Trend Micro products are affected. ]