The ability to tunnel under monitoring middleboxes poses a security risk
The ability to tunnel under monitoring middleboxes poses a security risk
An Internet Engineering Task Force (IETF) draft  for the Network Working Group, proposes a standard for Transport Layer Security (TLS) over HTTP. By moving the TLS handshake up the Open Systems Interconnection (OSI) stack, the authors hope to overcome the challenges faced in establishing secure connections where surveillance 'middleboxes' are present on the network. 

In short, they want secure and private connections using TLS at the application layer, treating traffic intercepting middleboxes as untrusted transport. 

The question is whether this ability to effectively bypass monitoring middleboxes is a good thing, both for the enterprise and more broadly network security?

The answer depends largely on your view of middleboxes in general, and could easily be seen as just another part of the backdoor debate. However, it goes a little deeper than that. For a start, not all middleboxes are created equal; everything from load-balancers to firewalls can fit the description. But where the issue becomes more polarised is when talking about HTTPS intercepts to supposedly improve security posture in some way. 

Like implementing such interception technology to vet data on the outbound path to prevent unsanctioned data leaving the enterprise boundaries for example. Bharat Mistry, principal security strategist at Trend Micro, told SC Media UK that "by implementing these technologies now more so than ever organisations will have to be mindful of data privacy especially if its PII data and which would fall under the regulations imposed by the GDPR."

But what about when used to track malware activity rather than data exfiltration per se? Earlier this year US-CERT released alert TA17-075A covering the issue of HTTPS intercepts weakening TLS security. Which might come as a surprise to those using either software or a hardware middlebox product to detect malware using HTTPS connections to malicious servers for example. 

The US-CERT alert pointed out that unless an HTTPS inspection product was performing the correct TLS certificate validation, and not conveying error message to the user, have the potential to weaken rather than strengthen end-to-end security posture. The best explanation of this I heard was that it's akin to leaving the front door wide open in order to check that the key fits. Researchers at the time, in a paper entitled 'The Security Impact of HTTPS Interception', suggested that 58 percent of middleboxes had severe security vulnerabilities and 62 percent of connections made with them were less secure than without.

That's pretty much where the IETF draft comes in, to deal with the problem of application services that get broken by terminated TLS connections. It should enable enterprise network monitoring, be that of employee or malware activity, without the reduced security scenarios of poorly configured implementations.

By implementing a standard that passes data securely through these middleboxes without requiring complex root certificate authority configurations, it's hoped to kill all birds with a single standardised stone. Which is also where it potentially falls down. 

Venafi vice president, Craig Stewart, points out that the IETF proposal "would essentially open up more tunnels across the network – allowing traffic to bypass certain inspection points." Stewart isn't saying this is necessarily a bad thing, but does warn "if organisations can't verify the traffic within these tunnels, they could unwittingly allow cyber-criminals to pass inspection points undetected; the IETF's proposal could expose some organisations to additional risk."

From the purely practical side of the fence, if the middlebox is there to intercept traffic for a reason (and this can be a legal or regulatory compliance one) then with a standard to bypass that interception we'll end up in a catch 22 situation. Most likely some kind of bodge to intercept the traffic another way; a more configurationally complex way with the potential to break more services than before. 

And that's without considering the malware scenarios whereby the bad guys will be looking to move their wares using the new route out of sight of the enterprise and any middleboxes. Indeed, in the draft itself there is a clue that security aspects could be problematical; a pretty big clue as it happens. 

Section 10 of the draft, entitled 'Security Considerations' currently consists of just the single slightly concerning statement: "todo"