Cryptography

Improved transport encryption couldn't have come at a better time. The new generation of Transport Layer Security (TLS) follows on the heels of a series of major cyberattacks that seem to be growing in severity: Alteryx, Tesla, Uber, … the list goes on and on.

The cybersecurity community is on high alert, and so is the executive suite. Forty-four percent of senior executives say that they feel "very" or "extremely" vulnerable to data threats [1] – that's almost one in two. In light of the EU General Data Protection Regulation (GDPR), its worldwide reach, and its steep penalties for data leaks, tightening the screws on cybersecurity has reached a new level of urgency. Businesses are willing to go out of their way to avoid drawing the ire of both the public and regulatory bodies. Given the sorry state of encryption, that is easier said than done.

An ever-growing multitude of cryptographic weaknesses and implementation vulnerabilities in existing TLS versions have rendered the standard all but obsolete. Meanwhile, the cloud revolution has democratized access to massive amounts of inexpensive computing power, putting average end users at a disadvantage. Moreover, the emergence of quantum computing poses a novel threat to pre-quantum encryption, like the ciphers used in TLS.

After a decade in service, TLS 1.2 is showing many signs of aging. The cryptographic building blocks of current versions of the TLS protocol are no match for the cryptographic capabilities of likely adversaries. Something has to give.

Attack Vectors Against TLS

Attack vectors against TLS target either specific design flaws in the protocol itself (e.g., weak cryptographic primitives or purely conceptual blunders), third-party implementation vulnerabilities, or more likely both.

Design flaws in the cryptographic building blocks of TLS have given rise to an avalanche of proof-of-concept exploits in recent years, the likes of CRIME, BREACH, HEIST, and BEAST. Weak cryptographic primitives have been known to facilitate Oracle attacks, such as the Bleichenbacher family of exploits against RSA PKCS#1v1.5, brute-force decryption attempts such as POODLE against insecure cipher-block chaining (CBC) mode padding, and sneaky side channel attacks, a set of novel techniques that bring network-level attacks against TLS to the browser (e.g., HEIST).

Just as the community started thinking the worst was over, ROBOT (Return of Bleichenbacher's Oracle Threat), managed to resurrect a Bleichenbacher-style vulnerability that's been around in various incarnations for close to 20 years and was presumed to be "fixed" – until early December 2017.

Conceptual flaws in the TLS protocol before version 1.3 have opened the possibility of protocol downgrade attacks (Logjam to export-grade cryptography, FREAK to a weak RSA key exchange), connection renegotiation attacks (TLS Renego MITM), and handshake attacks (3Shake), to name just a few.

Additionally, implementation flaws and practical misconfigurations can further undermine the security of the protocol in active deployments. Of course, the high technical complexity of a standard contributes to faulty implementations, particularly with a protocol like TLS, which up to version 1.2 was characterized by a certain ambiguity. For example, a faulty handshake specification left sufficient room for interpretation to facilitate the 3Shake exploit (authenticated client impersonation by a malicious server on the third handshake).

With the increasing complexity of available cryptographic primitives and available options, faulty configurations became the norm. The higher the complexity, the bigger the challenge when it comes to practical implementations.

Server administrators face a quandary. Given the versatility of key exchange mechanisms and ciphers, they are forced to choose between security and compatibility in the face of considerable ambiguity. As a result, correctly configured web servers are in short supply.

According to SSL Pulse, a TLS usage tracking service by Qualys SSL Labs, one in four web servers surveyed in May 2018 still supported at least some RC4 suites that have been discredited multiple times (e.g., bar mitzvah, RC4 NOMORE) (Figure 1). Of sites surveyed, 15.1% did not support the TLS_FALLBACK_SCSV signaling suite. Almost 20% of sites still allowed a weak key exchange of 1,024 bits or less (Figure 2).

On discovering the ROBOT exploit against RSA-based cipher modes in December 2017, researchers identified vulnerable implementations from at least seven vendors, including F5, Citrix, and Cisco, and 27 affected domains among the Alexa top 100 alone, including, most notably, Facebook and PayPal. Configuration blunders tend to magnify attack vectors. The same is true of flaws in TLS software implementations.

The seemingly constant succession of bugs in cryptographic libraries such as OpenSSL keeps supplying ever-so-memorable attack vectors like Heartbleed. A multitude of implementation vulnerabilities in user agents with respect to older versions of TLS also provide additional evidence that transport encryption in practice comes short of its promise.

The architects of TLS 1.3 have thankfully realized as much. As a result, TLS 1.3 is a decisive departure from a long tradition of weak cryptographic primitives and implementation challenges that have repeatedly plagued previous versions of the protocol.

Return of Common Sense

At long last, TLS 1.3 is expected to do away with some major vulnerabilities of its predecessors right out of the box. The return of common sense is evident throughout the specification.

TLS serves three principal objectives: authenticate peers, prevent eavesdropping, and validate the authenticity of communications. To that end, the algorithm that authenticates each message in the secure channel (HMAC, hash-based message authentication code) must be combined with a cipher that will encrypt the payload. Prior versions of TLS relied on MAC-then-encrypt (MtE) schemes for this purpose. MtE gave rise to an avalanche of side-channel attacks like Lucky13, a variant of Vaudenay's attack from 2002 revived in 2013, and padding oracle attacks such as ROBOT, a variant of Bleichenbacher's attack from 1998 that reemerged last December.

The logic underlying MtE in TLS before version 1.3 is faulty at its core: The scheme encrypts plain text after it has been authenticated using the MAC algorithm. As a result, the recipient must first decrypt the message with the session key to verify its authenticity. This approach allows an unauthenticated adversary to send arbitrary messages and force the receiving endpoint to decrypt invalid data that will fail MAC verification.

The recipient should be able to discard spoofed messages right away and not waste CPU cycles on decrypting them. The Encrypt-then-MAC scheme would achieve that purpose, but it has proven notoriously difficult to implement.

Given the experience with earlier versions of the protocol, the architects of TLS 1.3 settled on a third technique that improves security and simplifies implementation: AEAD (Authenticated Encryption with Associated Data). In this scheme, encryption and authentication of messages take place simultaneously – as does verification of authenticity and decryption. Although some might consider AEAD ciphers a second choice, they have been designed with an eye on ease of implementation and robustness. They are not susceptible to padding oracle attacks. The straightforward simplicity of this common sense approach will likely minimize practical vulnerabilities and help restore public trust in TLS.

On top of improved security, AEAD ciphers offer significant performance advantages over MtE. Those benefits, in part, result from their parallelization-friendly design.

The creators of TLS 1.3 were careful not to leave anything to chance. The standard carefully weights the security and performance benefits of ciphers and other features against their compatibility characteristics and – most importantly – potential risks. To that end, TLS has been pruned of a substantial majority of insecure cryptographic primitives.

Gone is the vulnerable CBC mode that gave rise to BEAST, Sweet32, and Lucky13; also gone with it are vulnerable block ciphers like 3DES. The stream cipher RC4 met the same fate (bar mitzvah and RC4 NOMORE). In its place, TLS 1.3 calls for the use of ChaCha20.

In recognition of the vulnerabilities uncovered in RSA-based cipher suites (DROWN, SMACK, ROBOT, etc.), the Internet Engineering Task Force (IETF) has disallowed RSA-based key transport in TLS 1.3. The key exchange now relies on elliptic curve Diffie-Hellman key exchange (ECDHE) or DHE, in either case with ephemeral parameters. Static Diffie-Hellman is no longer allowed. (EC)DHE in TLS 1.3 guarantees perfect forward secrecy when correctly implemented – unlike either static RSA or Diffie-Hellman in TLS 1.2.

Weak hash functions, namely SHA-1 and MD5, are disallowed in favor of SHA-256 and SHA-384, with a few notable exceptions. The use of SHA-1 is permitted with respect to client and server certificates (but not in signed handshake messages). Also, endpoint devices may still negotiate this compromised hash function to maintain backward compatibility with TLS 1.2. The hash functions SHA-1 and MD5 both fell prey to SLOTH-type exploits in the past.

Even though RSA may not be used for key transport in TLS 1.3, the standard still permits RSA-based authentication – presumably so that it would not break existing server configurations that use RSA certificates with TLS 1.2 as a fallback. TLS 1.3 has dropped support for DSA certificates and the DSA signature algorithm, though.

RSA certificates necessitate the use of RSA as a signature algorithm. To mitigate risks involved with unsecure PKCS#1v1.5 padding, TLS 1.3 introduces the RSA Probabilistic Signature Scheme (RSASSA-PSS) as an alternative. It is defined in the PKCS#1v2.1 specification. PKCS#1v1.5 padding is still permissible, though, in certificates.

Clearly, RSA is on its way out. When it comes to signature algorithms, TLS 1.3 offers two far superior choices: EdDSA (Edwards-curve digital signature algorithm) and ECDSA (elliptic curve digital signature algorithm), in addition to RSA.

When it comes to key derivation, TLS 1.3 introduces EdDSA (without a prehash) with two new signature algorithms, ed25519 and ed448. The former is based on SHA-512/256 and Curve25519, the latter on a new elliptic curve known as Ed448-Goldilocks. Alternatives to EdDSA include ECDSA, the soon obsolete RSA, and PSK (the pre-shared key used in session resumption). The key derivation process makes use of the HMAC-based key derivation function (HKDF)-Extract and HKDF-Expand functions based on hashed message authentication code (HMAC).

Padding continues to be a subject of much interest, if for different reasons. Padding refers to the procedure of appending a string of zero-value bytes to a field before encryption – for example, to conform its length to the block size of a bulk cipher. In TLS 1.3, the sender can use padding for all encrypted TLS records to inflate purposefully the size of the ciphertext. This type of cover traffic serves to obscure the size of genuine communications in scenarios where the presence or absence of activity could divulge clues to a malicious observer – with potentially serious consequences. TLS 1.3 thus offers a simple yet effective mitigation technique.

AEAD and the New Cipher Suite Architecture

With the switch to compulsory AEAD encryption, the protocol has been thoroughly and thoughtfully re-engineered. TLS 1.3 builds on a new concept of a cipher suite that separates the authentication and key exchange methods from the bulk cipher and hash function.

A cipher suite in TLS 1.3 comprises only an AEAD algorithm and an HKDF. It does not specify the certificate type or the key exchange mechanism. The key exchange and the method of authentication are negotiated separately. Renegotiation is disallowed.

Owing to these modifications, cipher suites of prior versions of the protocol do not lend themselves to being used with TLS 1.3. The new cipher suites are also incompatible with prior versions of the protocol.

Protocol downgrades and upgrades are no longer permitted. This decision reflects the fact that TLS exploits such as POODLE, Logjam, FREAK, and others rely on protocol downgrade or renegotiation features to prey on the vulnerabilities of the weakest algorithms in a given deployment.

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

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.

Conclusion

TLS 1.3 brings some much-needed improvements (see Table 1 for a summary) at a time of heightened concerns over data security and the integrity of encrypted communications. From state-of-the-art AEAD encryption with perfect forward secrecy to new cipher suites to low-latency session initialization with 1-RTT, the standard represents a major leap forward for data integrity, confidentiality, and authenticity.

The return of common sense is evident throughout the specification. TLS 1.3 boldly eliminates the conceptual flaws of its predecessors that opened grave vulnerabilities, some of which still linger in web hosts all across the Internet. (See the box titled "Checklist for Maximizing the Exploit Resistance of TLS.") Although it does not bring quantum-resistant cryptography, TLS 1.3 effectively shuts down virtually all known attack vectors – including Bleichenbacher's, at long last.

Edge and fog computing demand faster connectivity for cyber physical systems and other IoT/IIoT devices. TLS 1.3 delivers that, too: Both 0-RTT session resumption and the new full handshake in 1-RTT cut down on latency in a big way.

One of the hallmarks of the new standard is its straightforward simplicity. The new low-latency handshake provides a vivid example of a successful match of first-rate performance with top-notch security. The 0-RTT session resumption, however, comes at a high price in terms of its susceptibility to a variety of replay attacks. Even so, concerns over security are limited to software implementations, not the standard itself. It is up to web application developers to incorporate countermeasures against replay attacks on 0-RTT session resumption if they decide to use the feature.

Either way, vulnerabilities stemming from a server-side misconfiguration or weak cryptographic primitives are finally a thing of the past. Linux server administrators can finally breathe a sigh of relief.