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

Figure 1: An oversight with consequences: 16.9% of websites surveyed in May 2018 had at least some RC4 cipher suites enabled; however, an overwhelming majority (80.9%) no longer offer support for these vulnerable ciphers (image source: Qualys SSL Labs [2]).

Figure 2: A vulnerable majority: Only a tiny number of sites surveyed in May 2018 (7.6%) support a 3,072-bit key exchange (image source: Qualys SSL Labs [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.