The Future "Web on Speed"

Motivation

The advent of TLS1.3, of HTTP/2, and of KTLS begs the questions:

• Where does the standardization lead?
• Are there already working implementations?
• Does this mean faster and more secure web browsing for all?

This article will mainly talk about HTTP/2 and in part about KTLS.

HTTP/2

HTTP is a widely used application-level protocol in the web and was used since 1990. So far three versions exist: HTTP/1.0 as described in RFC1945, which then was updated to version HTTP/1.1 in 1999 in RFC2616 (even though it was first proposed in 1997 [1]). As of May 2015 HTTP/2 is specified in the above mentioned RFC7540.

The specification allows for two modes

• h2 (HTTP/2 over TLS),
• h2c (HTTP/2 over TCP)

and it also defines 10 frame types:

• HEADERS,
• CONTINUATION,
• SETTINGS,
• PRIORITY,
• PUSH_PROMISE,
• DATA,
• WINDOW_UPDATE,
• PING,
• GOAWAY,
• RST_STREAM.

Promises

The new HTTP version addresses a number of issues present in previous versions:

• Multiplexing of streams is now possible in one connection
• Prioritization of streams allows for faster handling of more important requests
• Upgrade mechanism allows for older systems in the network that do not understand HTTP/2
• Compression of verbose header fields is possible
• Use of binary message framing further minimizes network usage
• Speculative server push mode for reduced need of inlined content and increased cacheablity

Implementations

As of approximately mid-2015, many consumer products offer support for HTTP/2 in their respective implementations. The following table gives an overview of tools that include support; it does not claim to be complete:

Browser Software	Server-side Software	CDN's
Chromium	Apache	Akamai
Edge (and Internet Explorer)	H2O	AWS
Firefox	Microsoft Server	Microsoft Azure
Opera	nginx	Cloudflare
Safari	SuaveIO	Fastly

It is notable, that while h2c for unencrypted traffic is specified, all major browsers only implement the h2 protocol part . Thus encrypted traffic is the de facto standard when using HTTP/2.

Also of note is the fact, that when used in combination with TLS the header field compression is explicitly disabled by protocol design for security reasons. However, the binary nature of of the headers compared to the verbose textual format employed by previous HTTP versions still provides a significant reduction in bandwidth used by the new protocol version.

Server-side

HTTP/2 comes in two flavours — client-side and server-side. In order to handle the stream-multiplexing proposed in the RFC, servers will need to spawn new worker threads to facilitate these changes. While almost no commercial consumer Browser provides it, many server implementations do indeed offer h2c, enabling server-to-sever communication using HTTP/2 that are therefore not encrypted. Many server-side implementations can be configured so that they as well only support h2. If such a configuration is employed, the h2Direct preamble check may be disabled by that server, as by design it is only required for h2c-connections.

Of note is the fact, that h2Push (speculative server push mode) is generally enabled by default in most implementations.

For example: in Apace resources may be marked for speculative server push by simply adding the following to the mod_headers:

<Location $/path/to/resource/$>
    Header add Link "</file/to/preload.css>; rel=preload"
</Location>

In H2O servers the feature is similarly on by default. H2O does improve on the speculative push a bit, by employing a feature called CASPer (Cache-Aware Server-Push). This feature tracks the clients cache states and the presence of resources in them by way of cookies. If a resource marked as preload is not present within the clients' cache push the resources specified with the link header.

Generally, it is advised by software providers to push contents which were previously inlined in HTTP/1.1. However, if configured incorrectly, use of HTTP/2 might actually increase network usage, as possibly too much of the content is pushed automatically (especially: if the server push does in fact not take the client side caches into account).

Possible shortcommings in the RFC

• Possible Head-Of-Line-Blocking issues are not handled by the RFC and must be dealt with by the implementation. This might lead to inconsistent behaviour regarding this issue.
• In the RFC the Window-Update message seems to be used a bit excessively for the specified goal of reducing/minimizing network usage. A delayed (i.e. aggregated) Window-Update message might be advantageous to further reduce network traffic (see also: delayed ACK's in TCP).
• Cipher spec renegotiation is disabled, which might lead to long lived connections that actually stall due to limitations on the number of possible messages using that cipher. This in turn might lead fallbacks to HTTP/1.1.
• The designed backward compatibility allows for selection of possibly blacklisted cipher-suites, should the application protocol and the cipher-suite be selected independent of one another.
• Further security considerations can be found in RFC 7540 in section 10.

Future proofing

Even though, there are several points in which the specification falls considerably short of the promised improvements on previous versions, it is required by design, that all HTTP/2 implementations willing to communicate using TLS 1.2 (or greater) to include support of the

• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

TLS mode using P-256ec. This mode is mandated by both the new TLS 1.3 version and KTLS as currently included in the Linux kernel. The German BSI is explicitly recommending use of this cipher suite up until 2025+ in its TR-02102-2 document (as of Jan. 2019).

KTLS

Data flow in TLS using OpenSSL

With Linux kernel 4.13 (3.9.2017) Linux Kernel Transport Layer Security (or KTLS for short) was first introduced. In Kernel 4.17 (3.6.2018) KTLS was significantly updated by adding the so far missing TLS decryption. It promises fewer context switches and file copies to be necessary for the encryption process, than when done entirely by user-space libraries (such as OpenSSL) and highly builds upon hardware implementations of AES_GCM that were originally created in support of IPSEC. It does not support asymmetric cryptography and thus requires the complex handshakes to be done by the user-level library. Given the key material, it allows for faster file transfers, due to a reduced number of file copies, as keeping the file in the kernel space saves one copy roundtrip of that file through the user space. The original paper by Facebook's Dave Watson reported a 7% reduction in CPU resources.

Netflix Inc., who have done similar changes for FreeBSD during their migration from only DRM protected motion picture data first reported a drop from achievable datarates of approximately 70% (30-40 Gbps DRM-only-encrypted down to ~8.5 Gbps using Standard OpenSSL). The immediate change for a similar approach as KTLS only resulted in a 5.88% speed increase (~9Gbps), compared to the baseline OpenSSL variant. This approach (also called the sendfile approach) makes use of the kernel level function sendfile(), which allows file transfers without the pictured copy round trip of a given file through the user space. [2] Within a year however, they managed to reach a 247.06% speed increase (to about 29.5Gbps) on the baseline OpenSSL traffic when employing a modified version of OpenSSL. Using highly optimized libraries researches at Netflix Inc. even managed to increase that percentage to 320.59% (~35.75Gbps). With these speeds the network interfaces once again become the limiting bottlenecks, even though the connection is now TLS encrypted. [3]