Americas

  • United States

Asia

Oceania

jmporup
Senior Writer

Should you deploy a TLS 1.3 middlebox?

Feature
Jun 01, 20207 mins
Internet SecurityNetwork SecuritySecurity

Organizations moving to the TLS 1.3 protocol must decide whether to deploy middleboxes that intercept network traffic for greater visibility, but doing so presents security and regulatory risks.

scanning the internet malicious magnifying glass
Credit: Getty Images

To inspect or not to inspect, that is the question.

TLS 1.3 is by far the most secure version of the Transport Layer Security (TLS) protocol, but its use of ephemeral elliptic curve keys–and the deprecation of static RSA keys–means that TLS sessions now offer forward secrecy, a bane to enterprise security administrators who want to maintain visibility into their network traffic.

So, what’s the better security strategy? Deploy TLS 1.3 middleboxes to maintain visibility, thus creating new secure weaknesses, or let it slide and focus on endpoint threat detection and mitigation instead?

“Enterprise network sites often decide to decrypt encrypted traffic at a network proxy, allowing the network admin to scrutinize, log or block the traffic in question. But should enterprise network administrators do this? [emphasis his]” Kurt Andersen, a member of the Messaging, Malware and Mobile Anti-Abuse Working Group (M3AAWG) Board of Directors, tells CSO, speaking in his capacity as a M3AAWG board member.

There are good arguments for doing so and good arguments for not doing so. Since every organization has a different threat model, you can’t offer a black/white, yes/no answer. Here are some considerations to help make a decision on TLS 1.3 interception in an enterprise environment.

TLS 1.3 is coming

Like winter in Westeros, TLS 1.3 is coming. RFC8446 (TLS 1.3) will be an IETF standard, like it or not. Firefox and Chrome now support TLS 1.3, Cloudflare is deploying as well for new zones, and Qualys’ SSL Pulse indicates 30% of websites already support TLS 1.3 as of May 2020.

In the US government network world, NIST SP800-52r2 says that “Servers that support citizen or business-facing applications (i.e., the client may not be part of a government IT system) shall be configured to negotiate TLS 1.2 and should be configured to negotiate TLS 1.3.” NIST also requires that all government TLS servers and clients support TLS 1.3 by January 1, 2024.

“If TLS1.3 deploys (as it has and as we continue to expect it will), ‘everything’ will tend to be much better encrypted (unless network administrators routinely intercept and decrypt that traffic),” Andersen says, adding, “That parenthetical expression (… unless network administrators routinely intercept and decrypt that traffic…) is quite important.”

So, should you intercept?

Why enterprises want to intercept TLS 1.3 traffic

Enterprise security admins have lots of legitimate reasons to want real-time, complete visibility over their network. Until recently they’ve always been able to achieve that level of visibility, and suddenly no longer being able to see everything all the time is concerning for some.

On an enterprise networks, there is typically no expectation of employee privacy, and admins want to make sure employees aren’t browsing websites they shouldn’t, or doing their shopping on company time. At the sharper end of the security stick, there’s also a legitimate desire to prevent data exfil in the event of compromise, to monitor email for spam or phishing emails, and to block malware downloaders or connections to malware command-and-control servers.

If enterprise admins decide to deploy TLS 1.3 interception, they would do so using a middlebox solution that man-in-the-middles (MitMs) all TLS 1.3 traffic, email, web and otherwise.

“The primary approach will be use of a MitM proxy appliance running at an Enterprise Internet gateway,” Andersen says. “That proxy would serve as a middle box between the outside world and inside users. To the outside world, the box would be a ‘client.’ To the inside world, it would act as a ‘server.'”

So far, so good. But what problems can that approach cause, and why might an enterprise security admin think twice before deploying a middlebox solution?

The case against: Insecure middleboxes

While there are legitimate arguments for wanting to deploy TLS 1.3 interception and use cases where it is the right decision, the middlebox solution is far from the slam dunk answer you might think. Deploying an MitM middlebox to inspect TLS 1.3 traffic can be viewed as a security win because of increased visibility, but doing so also creates new security weaknesses in enterprise infrastructure, including threats to confidentiality, integrity and availability.

Most worrisome is that MitM middleboxes themselves have security issues that can be exploited by attackers. “We tested 13 network appliances, and found that all their TLS proxies are vulnerable against the tests under our framework—at varying levels,” the authors of the 2018 research paper “The Sorry State of TLS Security in Enterprise Interception Appliances,” concluded. “While TLS proxies are mainly deployed in enterprise environments to decrypt the traffic in order to scan for malware and network attacks, they introduce new intrusion opportunities and vulnerabilities for attackers.”

So, pushing all enterprise TLS traffic through a single chokepoint–a single point of failure and compromise–means an attacker can gain equal visibility into all parts of your enterprise. Hack the middlebox; see everything the admin sees. The logic from an attacker point of view is beyond obvious.

The case against: TLS inspection violates zero trust

During the COVID-19 pandemic when legions of employees are working from home, more enterprises are deploying a zero-trust model, in which all networks are considered untrusted and security is pushed to user devices.

“The notion of zero trust, as publicly known, would be the completely distributed model,” Michael Bailey, a professor at the University of Illinois at Urbana-Champaign who has researched the security of TLS inspection middleboxes, tells CSO. “Thou shalt not rely on the network to provide any security.”

Pushing security controls out of the network onto user devices provides additional resiliency, Bailey says, comparing a TLS inspection middlebox to a “moat and castle,” where once the attacker is over the wall, it’s game over. “Controls that were placed at the edge of the network, as opposed to centralized, provide some additional resiliencies.”

Enterprises need to be pragmatic and evaluate their threat model, who their adversaries are, and what they’re protecting before deciding to purchase a TLS inspection middlebox solution, Bailey emphasizes.

The case against: Regulatory issues

Another reason to be wary of deploying TLS middleboxes is that you may run into regulatory issues with the US government. US-CERT has publicly warned against TLS middleboxes in their official alert, “HTTPS Interception Weakens TLS Security.

Even the NSA raises concerns about TLS inspection. “Network owners should be aware that TLSI [TLS Inspection] is not a cure-all,” their report “Managing Risk From Transport Layer Security Inspection” says. “TLSI capabilities implemented in enterprise forward proxies can provide visibility into encrypted network traffic to detect adversarial use of encryption, but the devices that break and inspect the TLS traffic may become high priority targets for exploitation and introduce additional risks into an enterprise network. Enterprises must carefully weigh these risks against the benefits of and alternatives to TLSI; and, if TLSI is implemented, address those risks.”

Healthcare organizations concerned about HIPAA compliance should also be aware of the Department of Health and Human Services (HHS)’s concerns about TLS middleboxes. “Covered entities and business associates using HTTPS interception products or considering their use should consider the risks presented to their electronic PHI [protected health information] transmitted over HTTPS, and intercepted with an HTTPS interception products, as part of their risk analysis, particularly considering the pros and cons discussed by the US-CERT alerts, and the increased vulnerability to malicious third-party MITM attacks,” HHS wrote in an advisory entitled “Man-in-the-Middle Attacks and ‘HTTPS Inspection Products.'”

Should you deploy TLS 1.3 middleboxes?

Short answer: It depends.

Long answer: It still depends. What vertical are you in? What is your threat model? What are you protecting and from whom? What regulatory issues are you facing? What’s your budget? What does your security staff look like?

Bottom line: There are a few clear-cut cases where TLS 1.3 interception makes sense, a bunch of cases where it’s a grey area, and tons of places where it makes no sense or is counterproductive. Deploying TLS 1.3 interception may create as many security issues as it solves. Careful analysis before deciding is essential.

jmporup
Senior Writer

J.M. Porup got his start in security working as a Linux sysadmin in 2002. Since then he's covered national security and information security for a variety of publications, and now calls CSO Online home. He previously reported from Colombia for four years, where he wrote travel guidebooks to Latin America, and speaks Spanish fluently with a hilarious gringo-Colombian accent. He holds a Masters degree in Information and Cybersecurity (MICS) from UC Berkeley.

More from this author