10 reasons not to do HTTPS interception

HTTPS is the bread-and-butter of online security. Strong cryptography that works magically on all devices without complicating things for users. Thanks to innovative projects like Let’s Encrypt, adoption of HTTPS is rising steadily: Mid 2015 it was at 39%, now it is at 51% of HTTPS requests.

Recent research shows however that HTTPS interception happens quite often: About 10% of connections to CloudFlare are intercepted. Culprits are enterprise network security products, which intercept HTTPS connections to inspect their content.


HTTPS interception is controversial in the IT security community. There are two sides in this debate. Much depends on the setting you are in, but in this article I argue that HTTPS interception is a dead-end street for most organizations. I welcome your comments, arguments and counter-arguments.

Let’s start with the benefits of HTTPS interception, from an enterprise security perspective:

  • Detect malware downloads: In most cyber-attacks the end-user is triggered to download malware or an infected file, for example via a phishing attack, a waterhole attack or a malvertisement attack. HTTPS interception would allow the network proxy to see the binaries and documents downloaded and this means they could be scanned, by comparing with known malware signatures or by opening documents in sandboxes.
  • Detect C&C traffic: Command & Control traffic to exotic domain names and IP addresses is the hallmark of an infected device calling back to the attacker’s infrastructure. To avoid detection, attackers have started to use legitimate websites for C&C traffic, for example a Twitter feed of a burner Twitter account. Without HTTPS connections you can only see there is an internet connection with Twitter. So it blends in with normal user traffic. HTTPS interception would allow the internet proxy to see also the content, for example which Twitter accounts are accessed. This could in principle be used to distinguish C&C traffic from normal user traffic.
  • Detect exfiltration: Attackers could use HTTPS connections to exfiltrate data. In principle HTTPS interception could be used to detect if corporate documents or files are being uploaded, for example by looking for known patterns, markers or headers in documents.
  • Bypass HTTPS weaknesses: You’d be forgiven for having lost patience after more than a decade of problems with HTTPS: First slow adoption by websites, then bad issuing practices by CAs, then security breaches at CAs, then lax implementation by browsers, and finally we have trained all end-users to click blindly on “Yes” or “Can I continue now” with each warning message. Intercepting HTTPS before it reaches the browser or the end-user could in principle be used to bypass the issues with the browsers and the end-users.

But HTTPS interception is controversial in the IT security community for a good reason. Here are some good reasons for not doing HTTPS interception.

1. Are you serious? After a decade of telling everyone to implement HTTPS, educating users to check certificate warnings, preaching about how fundamentally important it is, at the moment that HTTPS is finally picking up, you scramble and start to intercept it, acting out the very man-in-the-middle attacks it was meant to prevent. It does not look very consistent or serious. But let’s move on.

2. Strict transport security: HTTP Strict Transport Security (HSTS) is an internet standard allowing websites to tell the browser to never accept non-HTTPS connections. This is important when a user forgets to type the S in the URL and it prevents from stripping attacks. A similar thing is done with cookies. If the website sets the cookie with a secure flag, then the browser will not send it back without HTTPS. These protections are important to prevent man-in-the-middle attacks. It also means that intercepted HTTPS connections will have to be re-encrypted, by the intercepting proxy, but this time with a fake certificate, a wildcard certificate (*), which is valid for all websites.

Such wildcard certificates are not sold by real CAs, but an enterprise can create one with a local internal CA. This wildcard certificate then needs to be pre-loaded and trusted by all the PC’s in the enterprise.

3. Blinds the browser and the user: Re-encryption with wildcard certificates effectively makes the browser and the user blind. The browser will no longer be able to warn the user about HTTPS connections and the end-user has no way to see if the certificate is valid and if the connection can be trusted.

This would not be a problem of course if the intercepting proxy is perfect and flawless, refusing all the bad connections, accepting only the good ones. But this is a tall order. A recent report actually shows that many of these interception products are very bad when it comes to accepting certificates, effectively opening the door to all sorts of attacks (decryption, downgrade or stripping attacks). This raises some liability questions.

4. Disrupts personal use: Social media, webmail providers and online banks ask their users to verify the HTTPS connection. In the case of HTTPS interception this is impossible. Maybe HTTPS interception requires some legal disclaimer about liability. But apart from the legal matters, many employees would no longer use their corporate PCs for things like social media, personal web mail or web banking. In some settings this is not a problem, but I think that for most organizations it is important to allow some form of personal use of corporate PCs, for example to allow employees during their break to make a bank transfer or buy their groceries online.

5. Certificate transparency: It is not enough to re-encrypt connections with wildcard certificates. Certificate transparency is an extra protection measure allowing browsers to check if a certificate is normally used by that website. A browser like Google Chrome, for instance, warns users when a Google page is shown with a different certificate, even if it is formally valid. It is a reaction to the continuous security problems and breaches at CAs. It is an important feature and it helped to discover the large-scale MITM attack on Iranian internet users, aka the Diginotar breach. So HTTPS interception requires you to tweak also the browser to accept the masquerading of the original certificate without complaints. Certificate transparency needs to be turned off.

So it should be clear that HTTPS interception is not only done at the network layer, but that it involves changing how endpoints, browsers, and ultimately the end-users, handle HTTPS connections. This means that HTTPS interception has wider implications.

6. Breaks with consumerization: IT in the workplace is driven by consumer products and services. Also endpoint and browsers and their security is driven by the consumer market. But because HTTPS interception has no place in the consumer market, this means that important protection like certificate transparency and certificate pinning do not work anymore in the enterprise. It would have to be tweaked or turned off on the browsers, and then implemented again on the intercepting proxy, for example. Also the awareness raising material, tutorials, and warning messages about HTTPS cannot be re-used anymore.

7. Disrupts BYOD: Employees are increasingly using their own personal computers in the office and for work. Sometimes devices are used side-by-side with corporate devices. To implement HTTPS interception personal BYOD devices will need to be tweaked and configured, to install and trust the wildcard certificate, and to turn off browser warnings. This not only leads to a lot of work by the IT department, which runs counter to the very idea of BYOD, but it is also likely to raise some eyebrows with users. HTTPS interception does not play well with BYOD.

8. Discourages good user practices: Even if we ignore BYOD, there is also the problem that employees have personal devices for personal use. Social media, online banks all ask end-users to inspect certificates and to heed browser warnings. With HTTPS interception in the enterprise and no HTTPS interception at home, the employee is dealing with two worlds: At work all HTTPS connections look strange, but they are to be trusted. At home when HTTPS connections look strange it is an attack. This is confusing for the end-user and this creates risks.

9. Limited benefits: At the start of this article I listed some IT security benefits of doing HTTPS interception. Actually these benefits are limited and diminishing: Malware detection is failing. Attackers evade signature-based detection by using polymorphic malware. Sandbox-based detection is being evaded also. It is easy to see that antivirus programs are losing the battle. Network detection will not do better (only worse actually). Attackers know how C&C traffic is detected, so they hide it. For example there are attacks in which the C&C communications are hidden in JPG images posted on Twitter timelines. In these attacks HTTPS was not even used by the attacker! The problem is not the HTTPS encryption but the fact that there is a sea of communications to hide in. The same applies to exfiltration. For an attacker obfuscation is more important than encryption. If needed attackers (insiders and outsiders) could always use an extra layer of cryptography. Perhaps the best reason for HTTPS interception is to bypass the flaws in the browsers and the weakness of the end-user ignoring warnings. But also this benefit is diminishing. Browsers are implementing HTTPS better. It is harder for users to ignore HTTPS warnings.

10. Hard-shell-soft-inside: HTTPS is an extension of network monitoring and detection. Investing in network monitoring and detection now is like betting on the horse that is lagging behind the pack and visibly tired. Not only is it easy for attackers to evade detection, it is a continuation of the traditional approach based on securing the corporate perimeter (hard-shell-soft-inside). It is known that this approach is flawed and it also clashes with the increased mobility of staff and the uptake of cloud services. Implementing HTTPS just goes further down the wrong path.

Instead of going against the wave of HTTPS uptake, by weakening and tweaking how HTTPS works inside the enterprise, for a few limited and short-term benefits, it is smarter to ride the wave and capitalize on the growing adoption of HTTPS. Of course there may be a need to mitigate some risks in the short term. Some organizations rely heavily on network-based monitoring and in these cases the uptake of HTTPS translates to higher risks. But to mitigate this it would be wiser to invest in something that has more of a chance against attackers, such as removing local admin rights from PCs, white-listing software, and detection and monitoring on the endpoint. If you do decide to do HTTPS interception make sure everybody knows it is temporary, and start thinking about taking mitigating measures that will allow to phase it out.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s