I have written elsewhere about the problems with the “little green lock” shown by browsers to indicate a web page (or site) is secure. In that article, I considered the problem of freely available certificates, and a hole in the way browsers load pages. In March of 2017, another paper was published documenting another problem with the “green lock” paradigm—the impact of HTTPS interception. In theory, a successful HTTPS session means the session between host and the server has been encrypted, which means no third party can read the contents of the packets passing between the two.

This works, modulo the trustworthiness of the certificates involved in encrypting the traffic, so long as there is no-one in the middle of the connection encrypting packets from the receiver, and re-encrypting them towards the transmitter. This “man in the middle,” or MITM, can read the contents of all the packets in the exchange, even though the data is encrypted on transmit. Surely such MITM situations are rare, right?

Right.

The researchers in this paper set out to discover just how often HTTPS (LTS) sessions are terminated and re-encrypted by some device or piece of software in the middle. To discover how often this occurs, they examined the TLS handshakes generated by popular browsers. Most browsers, when opening a secure session, choose a unique set of options, different than those used by commonly used TLS libraries and interception products. The options selected by each browser varies depending on the hardware capabilities, operating system settings, and user preferences.

They also observed a set of well-known servers to determine their normal behavior. By observing the normal interactions of these browsers with servers, they determined patterns to the browser’s behavior. When this behavior is different than normal, the researchers assume there is a man in the middle intercepting the TLS session.

Using this technique, the determined how often TLS interception was taking place. Once interception was discovered, they tried to determine whether the intercepting party was some software, such as an anti-virus package, or some middlebox. How many sessions were intercepted? The lowest percentage of interception was 4% for communications between the Firefox browser and its corresponding update server. This may seem like a small amount, but since Firefox ships with special certificates just for communicating with the update server, this is still a larger percentage than expected.

For a set of popular ecommerce sites, they measured an interception rate of 6.8%; again, this is much higher than has been widely reported and higher than expected. For Cloudflare based destinations, the researchers observed 10.9% of all sessions were intercepted.

What is intercepting sessions at this level? For those interceptions that can be traced, the answer is largely anti-virus software. Such software apparently acts as a man in the middle so it can check the incoming flows for viruses and other threats. While this might seem like an innocuous enough situation, this does break the end-to-end encryption designed into TLS, and leaves users open to tracking through this third-party software that many do not realize is intercepting encrypted traffic to and from servers on the Internet. There are other devices, middleboxes, but these were hard for the researchers to find and understand for various reasons. These boxes are largely proxy servers, leaving user traffic open to attack if they are poorly maintained or compromised.

The bottom line: HTTPS interceptions are much more frequent than previously thought, leaving open questions about the effectiveness of TLS in the wild to protect user content.