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.

Disclaimer: This is my personal view, from a sheer technical IT security perspective. So this is not the full picture: For instance I do not discuss about legal implications, liability or privacy implications, and I do not consider content filtering. This post does not express the views of my employer. And in this article I mean the 'legal' kind of HTTPS interception, done in an enterprise setting, permanently at the company's internet proxy, intercepting internet connections between the WWW and the company's office PCs, with full knowledge of the employees.

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. So intercepted HTTPS connections will have to be re-encrypted, by the intercepting proxy, but this time with a fake certificate.

These fake certificates cannot be purchased from a real CA. A cornerstone of the X509 Public Key Infrastructure is that CAs do identity checks to avoid issuing such false certificates. So the enterprise needs to resort to a trick: It creates an internal (bogus) CA which can create false certificates, for any website, on the fly. [Note that this paragraph was changed following a helpful comment below.]

3. Blinds the browser and the user: Re-encryption using fake certificates effectively makes the browser and the user blind. The browser will no longer be able to warn if the original certificate was suspicious and the end-user has simply no way to see the original certificate anymore to understand if the connection can be trusted or if was intercepted.

This would not be a problem of course if the intercepting proxy was 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). Apart from deteriorating the overall security it also 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. Breaks certificate pinning and transparency: It is not enough to re-encrypt connections with fake certificates. Certificate pinning and Certificate transparency are extra protection measures allowing browsers to check if the certificate is 'normally' used by that website. A browser like Google Chrome, for instance, warns users when a Google page is not appearing with its usual certificate. This measure was a reaction to a string of security breaches and bad practices at CAs. Certificate pinning and certificate transparency are important features which, for instance helped to discover the large-scale MITM attack on Iranian internet users, aka the Diginotar breach. To avoid these warning you need to tweak the endpoints, the devices and browsers, to accept the fake certificates without complaints: The fake certificates need to be trusted completely and certificate pinning and certificate transparency needs to be turned off. [Note that following a helpful comment on this post (see below) this paragraph was changed ad now mentions certificate pinning explicitly.].

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. These personal BYOD devices will need to be tweaked and configured just as mentioned above (trust the fake CA and turn off pinning warnings). This creates work for the IT department, who will need to help users set up their devices. This runs counter to the very idea of BYOD. More importantly it is likely going to raise some eyebrows with the owners of these personal devices. HTTPS interception does not play well with BYOD.

8. Discourages good user practices: Even if we ignore BYOD there is another problem with personal devices: Social media, online banks all ask their customers to inspect certificates and to heed browser warnings. If HTTPS interception is happening in the enterprise then 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 should be treated as an attack. This is a confusing situation for the end-user and this creates risks.

9. Limited benefits: Some of the IT security benefits of HTTPS interception 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 another type of network-based monitoring and detection. Investing in network-based monitoring and detection at this moment is like betting on the horse that is already lagging behind the pack. Not only is it relatively easy for attackers to evade detection, it is also the continuation of the traditional approach based on securing the corporate perimeter (hard-shell-soft-inside) which is known to be flawed. This traditional approach also clashes with the increased mobility of staff and the uptake of cloud services. Implementing HTTPS 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 immediate risks. But to mitigate these risks it would be wiser to invest in other defenses which have a better chance against attackers, such as removing local admin rights from PCs, keeping software updated, and performing detection and monitoring on the endpoint. If you decide to do HTTPS interception, then make sure everybody understands it is a temporary measure and start thinking about what is needed before you can phase it out.