The use of TLS interception by outbound proxy servers is causing serious problems in updating the TLS standard to Version 1.3.
At the same time, middlebox and antivirus products increasingly intercept (i.e., terminate and re-initiate) HTTPS connections in an attempt to detect and block malicious content that uses the protocol to avoid inspection . Previous work has found that some specific HTTPS interception products dramatically reduce connection security ; however, the broader security impact of such interception remains unclear. In this paper, we conduct the first comprehensive study of HTTPS interception in the wild, quantifying both its prevalence in traffic to major services and its effects on real-world security.
This is the same problem that middleboxes cause anywhere on the Internet – Firewalls, NAT gateways, Inspection, QOS, DPI. Because these complex devices are rarely updated and hard to maintain, they create failures in new protocols. IPv6 rollout has been slowed by difficult upgrades. The same problem is happening with TLS. Its undesirable to fall back to insecure TLS standards that “work” but are insecure.
The EtherealMind View
The business need for proxy servers or protocol interception is for a small range of activities
- Scan Internet content for malware etc.
- Monitor employee behaviour and time is spent working and assist HR as needed.
- Prevent content theft. Or at least, provide audit data for legal cases for theft.
- Prevent unintentional data leakage
Poorly maintained proxy servers mean that real security is being compromised. And by “poorly maintained” I would point the finger at customers and vendors equally. Vendors are slow to update their apps and operating systems while customers have learned not to trust their vendors leading to reluctance to upgrade for fear of service outage.
Source: Link: The Security Impact of HTTPS Interception – https://jhalderm.com/pub/papers/interception-ndss17.pdf
Research Copy. The Security Impact of HTTPS Interception interception-ndss17.pdf
All of these systems are kludges. TLS is not meant to be intercepted and by doing so you will always have issues. Seems like many orgs are dead set in favor of inspecting TLS, well many web companies are dead set against it.
We should probably find a middle ground that allows for some secure inspection that a enterprise can turn on at their will and secure, well maintaining certificate and encryption integrity. Although, I imagine the discussions in the IETF would be brutal.
I agree, strongly. Its possible to prevent interception by forcing end-to-end certificate validation but its not widely implemented.
The root cause of the issue is crappy endpoint security. If we had endpoints that were reliably secure against malicious web content, we wouldn’t need to install boxes to do content inspection in-line.
The HR issue could be worked around via logging on the endpoints if required.
We’ve been having this debate internally (Enterprise Network) for some time. HTTPS decryption for web filtering has been a mess. We have ended up routing many sites around the proxy because of the issues and breakages it causes. End device agents are a much better way to go about this if it’s really a business requirement. Look at the traffic before it’s encrypted… it’s slightly less disturbing than a man in the middle attack.
You’re still kinda doing man-in-the-middle. Just on the end device rather than an upstream connection.
A major reason to to TLS MITM is because you don’t trust the security of your endpoints and want to scan traffic before it is received or as it exits. Given you don’t trust the security of your endpoints, in that instance an endpoint hosted filter is perhaps less reliable.