The New Handshake

Some of the most profound improvements in TLS 1.3 focus on the actual flow of communication between the client and the server. One of the hallmarks of TLS 1.3 is its straightforward simplicity. The new handshake in TLS 1.3 provides a vivid example of its practical benefits.

The new, streamlined handshake in TLS 1.3 eliminates one round trip per session, obliterating the usual latency. Where TLS 1.2 requires two round trips per handshake (2-RTT) during the initial exchange, TLS 1.3 performs a 1-RTT handshake. On session resumption, TLS 1.3 can establish a secure channel without even as much as one round trip.

In TLS 1.3, the initial session begins with a ClientHello that already contains the client's key share and a suggested key exchange protocol. The server responds with a ServerHello, specifies a key exchange algorithm, and delivers its key share alongside its certificate chain with its public key signed with the corresponding private key. The transfer concludes with a ServerFinished. All messages that follow the ServerHello are already encrypted – a big step forward over TLS 1.2.

On receipt of the certificate chain during the TLS 1.3 handshake, the client verifies the chain, generates keys based on the key share it obtained from the server, and declares ClientFinished – all in one round trip (1-RTT). By contrast, TLS 1.2 needs a full additional round trip on top of the first to establish a secure channel. The extended back and forth between the peers in TLS 1.2 and prior versions comes at a high cost in terms of latency. Edge and fog computing demand a faster response.

TLS 1.3 delivers with 0-RTT session resumption. This quick procedure is at least as thrilling as the original no-frills handshake, if not more so.

During the initial session, the server and the client have established a pre-shared key (PSK). On session resumption, the client sends a ClientHello alongside the session ticket with the PSK and the client's first request, which is already encrypted with that PSK. The client also issues a new key share to maintain forward secrecy and sends it across. On receipt of this information, the server extracts the PSK from the session ticket, decodes the first client request using that PSK, and encrypts its own response using the new key share. To that end, TLS 1.3 replaces session resumption cipher suites (with and without the server-side state) and all PSK-based cipher suites of its predecessors with a single new PSK exchange.

The benefits of 0-RTT for Internet of Things (IoT) and Industrial IoT (IIoT), particularly with respect to critical infrastructures, cannot be overstated. From the vantage point of application developers, however, 0-RTT session resumption in TLS 1.3 is fraught with pitfalls.

Replay Attacks Against TLS 1.3

Network attackers can take advantage of 0-RTT data to launch replay attacks. TLS 1.3 does not provide inherent protections from such attacks for 0-RTT data, which potentially opens several attack vectors all at once.

A network adversary can launch a replay attack against a web application by merely duplicating 0-RTT data. In this scenario, the attacker submits multiple copies of an application message to the server to cause it to execute on duplicate requests. This threat is not unique to TLS 1.3. Some clients already display similar behavior when counteracting network errors by attempting to retry requests to improve the connection's resilience.

To prevent this type of attack, all servers running an application must share state to guarantee that it accepts this particular set of 0-RTT data no more than once. It is up to the server to provide replay safety by implementing appropriate countermeasures. In most deployments, multiple servers do not share state in this manner. Because client applications have no way of knowing whether the server can counteract this vulnerability, clients may only send early data in 0-RTT that does not endanger the application in the event of a replay attack. Whether all implementations will consistently live up to this requirement is doubtful at best.

On top of this, some types of assaults – such as timing and resource limit exhaustion attacks, among others – can exploit even ordinarily idempotent operations. Application developers are the ones tasked with mitigation. It requires that every 0-RTT payload can be replayed only a limited number of times in the entire scope of the distributed system that is affected. Any individual instance should accept 0-RTT data for a session resumption handshake no more than once, effectively limiting the number of replays to the number of running instances. This, however, may still prove insufficient, particularly on large deployments. The time stamp contained in a ClientHello message allows the server to discern easily at least those messages that were prerecorded by an attacker for en masse perusal. It is thus advisable for a server to maintain an archive of recent ClientHello messages it received and validate new 0-RTT requests against it. The downside to this approach, though, is that although this procedure might help dwarf some types of replay attacks, it also somewhat invalidates the performance benefits of 0-RTT.

In addition to the above points, 0-RTT session resumption in TLS 1.3 opens up another attack surface for any server system that lacks the ability to maintain a globally consistent state. More specifically, 0-RTT poses a threat to any application that runs in multiple zones but declines tickets issued in one zone (A) in any other of its zones (B, C, D, …).

By sending a ClientHello and early data intended for zone A to both A and B, an attacker can force a full handshake in the zone that rejects the data as invalid (B), while the other zone (A) will accept it and respond with a ServerHello in 0-RTT fashion. Should the attacker succeed at preventing this legitimate ServerHello from reaching the legitimate recipient, the client will proceed with the full handshake in the other zone that rejected the ticket; then, it will have to retry its original request. This behavior amplifies the load on the server with only minimal effort on the attacker's part.

At a time when web applications tend to run as distributed, containerized microservices, this threat is very real. The 0-RTT session resumption, considering its potential for load amplification, flies in the face of the very idea of resiliency. The TLS layer has no safeguards against this type of attack. Application developers will have to implement thoughtful countermeasures to minimize the attack surface, particularly if their clients already exhibit the replay behavior.

TLS 1.3 in Practice

Linux users and developers can already dab their fingers into TLS 1.3 in full-fledged deployments. The new protocol requires a Linux kernel version 4.13 or above. OpenSSL debuts TLS 1.3 support in version 1.1.1 beta, as does Nginx in its most current stable release.

Nginx has experienced a steady rise over the last couple of months and is catching up quickly to Apache in terms of its market share. According to a recent survey by W3Techs.com, Apache maintains its lead at 46%, followed tightly by Nginx at an astonishing 38.5% and by Microsoft's IIS in heavily contested third place at a mere 9.8%. Among the busiest websites, Nginx has established a solid leadership (Figure 3).

Figure 3: Taking the lead with TLS 1.3 on board: The Nginx open source web server currently powers a big chunk of the busiest sites in the world, outpacing Apache in this category since July 2014; Microsoft IIS comes in a distant third (image source: Nginx [3]).

Apache does not currently offer any support beyond TLS 1.2. Microsoft's implementation is already in active development. In contrast, TLS 1.3 is going strong in terms of browser support. Firefox, Chrome (both desktop and Android), Opera (when enabled manually), and Samsung Internet already bring mostly feature-complete implementations, which corresponds to 63% of users globally and 47.52% in the US, according to data provided by the Can I Use website [4].

Even on those Linux systems that can fully support TLS 1.3, the prior version should remain enabled for the time being.