TLS over http2 frames

[Ben Burkert <[e-mail]>]

Hello,

I believe that there is a need for an http2 extension that allows for TLS over http2 frames. An extension to support simultaneous encryption between the client & intermediary and end-to-end encryption between the client & server on the same connection. The use case is analogous to browsers that send HTTPS requests over an encrypted VPN connection.

The CDN industry has largely evolved around the constraints of the modern web protocols; especially wrt http1.1 and https. In a number of ways the proposed http2 protocol has been designed to address flaws & oversights in http1.1 that made CDNs a necessity. A large amount design effort has been focused on reusing and optimizing a single client/server connection. This is at odds with the CDN practice of serving a website's assets through an out-of-band connection to the CDN's network.

As CDNs adapt to http2 their role may evolve into an intermediary layer that provide their service over the same  http2 connection in between client and server. We are already seeing similar services offered by CDNs. For example, traffic to www.whitehouse.gov is served first through Akamai's network before requests reach the drupal backend servers. This type of service can benefit clients by providing high availability and expanded presence, but at a cost to security; end-to-end encryption is not possible. Encrypted traffic must be terminated by the intermediary and then re-encrypted on it's way to the server. This is the case for http1.1 as well as http2, which is at odds with http2's goal of improved security.

An extension to allow TLS over frames addresses this problem by providing for a second layer of encryption. The outside (existing) layer would be used for communication between the client/server and intermediary, while the inside layer would provide end-to-end encryption between the client and server. Requests and responses would also be layered: the outside request/response would contain headers shared (and actionable upon) by the intermediary and the other two parties. The inside request/response would be passed through blindly by the intermediary. To put it a different way, the outside request/response is there to help the intermediary route/cache/serve the inside request/response which it cannot see.

One possible solution would be to add a TLS_HANDSHAKE frame for initiating the second layer of encryption. This frame would carry the tls messages for the handshake between the client & server. A client would initiate it (with the client hello message) on a new stream. After the handshake is successful, both sides would encrypt the payload of DATA frames with this tls session. the payload of the encrypted data would be the frames of the inner request/response. The outer request/response is comprised of HEADER & CONTINUE frames, but the DATA frame hold the inner request/response (which can be made up of HEADER, CONTINUE, and nested DATA frames). Any streams that depend on this stream would also be expected to encrypt the DATA frames.

This is by no means a completed solution, but I am interested in hearing this group’s opinions on the problem and this potential approach.

Regards,
-Ben