Home / Blogs

HTTPS Interceptions Are Much More Frequent Than Previously Thought

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?


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.

By Russ White, Infrastructure Architect at Juniper Networks

Filed Under


>largely anti-virus softwareHow is this software able Charles Christopher  –  Jul 31, 2018 1:15 AM

>largely anti-virus software

How is this software able to present a certificate to the browser that does not alert the user of the MITM attack? The only certs allowed to be offered are ones which we trust the Root CA (certificate authority) does not have private keys in the wild ...... Or ones we ADD to that list ......

That seem the more startling issue.

Form the article conclusion:

“We investigated popular antivirus and corporate proxies, finding that
nearly all reduce connection security and that many introduce
vulnerabilities (e.g.,  fail to validate certificates).”

Which then suggests to me those high percentages would necessarily be targeting specific networks (corporate networks?), those that have broken SSL by transferring trust away from the trusted 3rd party CA list. I don’t see how this would occur for most home users.

Otherwise we have the much bigger problem of successfully forging certs of trusted CA’s.

By Eduard Kovacs on April 28, 2015 Charles Christopher  –  Jul 31, 2018 1:25 AM

By Eduard Kovacs on April 28, 2015 https://www.securityweek.com/antivirus-software-has-negative-impact-https-security-researcher "According to Böck, all of the security products he tested break Public Key Pinning Extension for HTTP (HPKP), a security feature designed to prevent MitM attacks leveraging forged certificates by instructing the web client to associate a cryptographic key with a certain web server."

With the client->server stream being secure from Phil Howard  –  Aug 7, 2018 3:16 AM

With the client->server stream being secure from MitM, TLS could be extended like: The client generates a key from random and sends it to the server ove the secure transmit link.  The server now encrypts the server->cliebt data with that key, which the client can decrypt using a copy of that key that it kept.  MitM does not get to see this key.  So why not this to secure both links?

Once the "security" software gets in the Charles Christopher  –  Aug 7, 2018 3:56 AM

Once the "security" software gets in the middle it sees everything. That it can without throwing an error on the browser is profound. I have been pondering the stats that Russ included. If I understand them correctly then it seems to me only 4 to 10 percent of the scanned traffic is using "security" devices. Seems to me the number should be higher if that is the source. Which leads me to the next thought. Browsers get a lot of public face time in regards to security, trust is a significant issue. And thus we have open source browsers so everyone can see the code and build the bowser themselves. But do we have such review of the most common "security" software and appliances? From what I have read some browser default CA's will actually roll a full "root" wildcard (intermediates) for the right price, thus trivializing MitM. They do this on the "trust" that the cert is "buried' in silicon, and thus no review regarding how the device may CREATE susceptibility to additional MitM intercepts. Meanwhile why should any CA's that sell intercept certs be default CA's in a browser? .... Hmmm .... The issue here is, once the "security" devices destroys the assumption of a secure connection by the browser, there is no way to know if there is a SECOND MitM occurring. And, perhaps, the "security" devices might make that second intercept trivial. The "security" device is lying, so does it really care about "truth" downstream? If it complains that someone is intercepting the comm, than it reveals it is doing just that, and the ILLUSION of trust is gone. Its better to keep somethings to itself. This study noted perturbations from the norm. It seems to me it can't distinguish from 1 MitM intercepts or 10, or 100 on a given stream. It just suggests it is occurring.

Comment Title:

  Notify me of follow-up comments

We encourage you to post comments and engage in discussions that advance this post through relevant opinion, anecdotes, links and data. If you see a comment that you believe is irrelevant or inappropriate, you can report it using the link at the end of each comment. Views expressed in the comments do not represent those of CircleID. For more information on our comment policy, see Codes of Conduct.

CircleID Newsletter The Weekly Wrap

More and more professionals are choosing to publish critical posts on CircleID from all corners of the Internet industry. If you find it hard to keep up daily, consider subscribing to our weekly digest. We will provide you a convenient summary report once a week sent directly to your inbox. It's a quick and easy read.

I make a point of reading CircleID. There is no getting around the utility of knowing what thoughtful people are thinking and saying about our industry.

Co-designer of the TCP/IP Protocols & the Architecture of the Internet



New TLDs

Sponsored byRadix

Threat Intelligence

Sponsored byWhoisXML API

IPv4 Markets

Sponsored byIPv4.Global

Brand Protection

Sponsored byCSC


Sponsored byVerisign

Domain Names

Sponsored byVerisign