The Internet Engineering Task Force (IETF) has just put out a new draft for a standard that would enable folks to effectively bypass surveillance equipment on their networks to maintain secure connections.
The working draft from three Cisco employees notes that so-called middleboxes – which intercept and decrypt connections – are often deployed to scrutinize and improve network security, but can end up breaking application services by terminating TLS connections. Middleboxes can also be used by organizations and ISPs to monitor employees and citizens.
As such, the proposed new standard would lift the TLS handshake further up the OSI stack to the application layer by transporting TLS records in HTTP message bodies. They're calling it "Application Layer TLS" or ATLS (TLS is the successor to SSL).
It allows clients and servers to securely and privately connect to each other even if there are black boxes intercepting their network traffic, and it works by essentially not trusting said equipment.
In an enterprise setting, in which middleboxes are installed to keep tabs on staffers' internet activities as well as catch any software nasties or miscreants moving around networks, sysadmins have to faff around configuring workstations and other devices to accept the eavesdropping equipment as trusted certificate authorities, so that the spy-boxes can successfully decrypt HTTPS and other TLS/SSL-protected connections.
However, that only works well with a clean centrally controlled topology able to push out settings to all endpoints as required. Many real-life corporate networks are much more complex and sprawling, with people adding and removing a wide variety of different client devices all the time.
The chances are that the IT department is constantly fighting fires to keep people and their various gadgets and computers connected via the middleboxes while juggling network updates and adjustments.
Rather than chew up everyone's time and patience, the IETF proposal would simply provide a standard mechanism for securely passing data through middleboxes without having to screw around with custom root certificate authorities, potentially saving a big headache along the way. The goal is to make the standard fully compatible with both past and future versions of TLS in order to keep any reconfiguration to a minimum.
The ATLS proposal also notes that it will "avoid introducing TLS protocol handling logic or semantics into the HTTP application layer i.e. TLS protocol knowledge and logic is handled by the TLS stack, HTTP is just a dumb transport."
Not only would this approach make sysadmins' lives easier, it would also come with additional benefits, the authors claim:
There are several benefits to using a standard TLS software stack to establish an application layer secure communications channel between a client and a service. These include:
- no need to define a new cryptographic negotiation and exchange protocol beween client and service
- automatically benefit from new cipher suites by simply upgrading the TLS software stack
- automaticaly benefit from new features, bugfixes, etc. in TLS software stack upgrades.
The basic idea is that a client will create two independent TLS connections, one at the transport layer directly with the service, potentially via a middlebox, and one at the application layer. A client could use ATLS only as a fallback if the transport layer connection breaks down due to middlebox interference. TLS sessions with multiple clients are tracked through an identifier in JSON messages sent in POST requests, and the approach would result in a new HTTP content type: application/atls+json.
Before you get too excited though, it's worth noting that security considerations to this approach have yet to be considered: the relevant section is listed as simply "To do."
Still, that's what the whole IETF approval process is for. For more information, the draft is available online. ®