SSL spy boxes on your network getting you down? But wait, here's an IETF draft to fix that

TLS over HTTP? Yes please, says every sysadmin, netizen

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. ®

Send us news

Google's Project Ellman: Merging photo and search data to create digital twin chatbot

'This is a brainstorming concept a team is at the early stages of exploring'

Competing Section 702 surveillance bills on collision path for US House floor

End-of-year deadline looms on US surveillance

Musk takes SEC 'Twitter sitter' consent decree appeal to US Supreme Court

Same old argument about free speech – let's see if it sticks this time

Microsoft to intro dedicated mode for Cloud PCs

Latest Insider Build brings new features for Windows 365 Boot

AMD thinks it can solve the power/heat problem with chiplets and code

CTO Mark Papermaster lays out the plan for the next two years

Open source forkers stick an OpenBao in the oven

HashiCorp software faces challenge after licensing change

Uncle Sam plows $42M into nurturing fusion breakthrough

Experimerntal milestone needs work before it can be considered a candidate for power generation

Datacenters feeling the heat to turn hot air into cool solutions

It's tricky to pull off, but new rules may make reuse more common

That call center tech scammer could be a human trafficking victim

Interpol increasingly concerned as abject abuse of victims scales far beyond Asia origins

Messed up metadata could be to blame for Microsoft's Windows printer woes

It looks like everything is coming up HP. Do you want some help with that?

Time for a Geeko remix: openSUSE is looking for a new logo

Days left to decide chameleon's fate ... vote now

Microsoft's relationship with OpenAI now in competition regulator's sights

Has recent CEO, board shenanigans given rise to a merger situation? CMA is asking for a friend