By Nic Hollins, GDT Network Security Engineer
A draft for a new standard has been created by the Internet Engineering Task Force (IETF). It effectually allows people to avoid the scrutiny of surveillance equipment on their networks to perpetuate secure connections.
Three Cisco employees have provided a working draft for the purposed standard. Devices known as “middleboxes” intercept and decrypt traffic to bolster network security. Typically, these types of devices are used by ISPs, corporations, and other organizations to monitor users. However, due to their inherent function of terminating TLS connections, they also can break application services. The new standard would be known as “ATLS” (Application Layer TLS) because it moves the TLS handshake up to the application layer of the OSI model, by transporting TLS records in HTTP message bodies. This will allow private and secure connections to persist between clients and servers, even if the traffic between them is being intercepted by middleboxes (this works by not trusting said equipment).
Middleboxes are deployed to monitor end-user internet activity, inspect application and system software traffic for threats, along with other tasks. For middleboxes to inspect workstation and networking device traffic they must be configured by system administrators as trusted certificate authorities. This enables them to decrypt TLS/SSL-protected connections like HTTPS. In an ideal world, a logical and centrally controlled topology would allow this to be done with ease. However, in the real world of enterprise networking, you often find more sprawling and convoluted network topologies, some of which defy logic itself. Sprinkle in a BYOD (bring your own device) policy and you have a recipe for complexity.
Keeping employees and their gizmos, mission-critical appliances, servers, etc. connected via middleboxes while managing network or configuration updates and other troubleshooting tasks not only keeps an IT department spinning plates, it may lead to their personnel being overextended. This new IETF proposal would provide a standardized mechanism to securely pass data through middleboxes without the added man-hours and loss of productivity that occur when configuring custom root certificate authorities (and their ancillary tasks). Ultimately the standard will be fully compatible with both past and future version of TLS in an effort to minimize the need for reconfiguration.
What are the Pros?
The purposed ATLS standard cites 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.” Besides the financial benefits that would be gained via productivity and efficiency, system administrators may also save a piece of their sanity along with the added bonus of making their job easier. And according to the author’s more technical perks include:
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 between 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.
Essentially the concept is that a client will create two independent TLS connections, one at the transport layer directly with the service, possibly via a middlebox, and one at the application layer. As a fallback, a client could use ATLS only if the transport layer connection is broken 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.”
Finally, it is worth keeping in mind that because the security considerations to this concept are still being worked through the relevant section is listed as “To do”. For more information, you may read the draft published on the IETF’s site.