What’s in a Downgrade? A Taxonomy of Downgrade Attacks in the TLS Protocol and Application Protocols Using TLS

Abstract

A number of important real-world protocols including the Transport Layer Security (TLS) protocol have the ability to negotiate various security-related choices such as the protocol version and the cryptographic algorithms to be used in a particular session. Furthermore, some insecure application-layer protocols such as the Simple Mail Transfer Protocol (SMTP) negotiate the use of TLS itself on top of the application protocol to secure the communication channel. These protocols are often vulnerable to a class of attacks known as downgrade attacks which targets this negotiation mechanism. In this paper we create the first taxonomy of TLS downgrade attacks. Our taxonomy classifies possible attacks with respect to four different vectors: the protocol element that is targeted, the type of vulnerability that enables the attack, the attack method, and the level of damage that the attack causes. We base our taxonomy on a thorough analysis of fifteen notable published attacks. Our taxonomy highlights clear and concrete aspects that many downgrade attacks have in common, and allows for a common language, classification, and comparison of adowngrade attacks. We demonstrate the application of our taxonomy by classifying the surveyed attacks.

Appendix A The TLS Protocol

1.1 A.1 TLS, a General Overview

The main goal of TLS is to provide a secure communication channel between two communicating parties [13], ideally client (initiator I) and server (responder R). TLS consists of two sub-protocols: the handshake protocol and the record protocol [13]. Briefly, the handshake protocol is responsible for version and ciphersuite negotiation, client and server authentication, and key exchange. On the other hand, the record protocol is responsible for carrying the protected application data, encrypted with the just negotiated keys in the handshake. As of this writing, TLS 1.2 [13] is the currently deployed standard. The coming version of TLS, TLS 1.3 [29], is still work in progress. Figure 3 shows the message sequence diagram for TLS 1.2 using Ephemeral Diffie-Hellman (EC)DHE⁵ key-exchange [14], Fig. 4 shows TLS 1.2 using Rivest-Shamir-Adleman (RSA) key-exchange [30], and Fig. 5 illustrates the changes in the Hello messages in TLS 1.3 based on the latest draft (draft-25 as of this writing) [29]. Our scope in this paper is TLS in certificate-based unilateral server-authentication mode. In the diagrams, the messages are represented by their initials (e.g. CH refers to ClientHello). Throughout the paper, the protocol messages are distinguished by a TypeWriter font.

1.2 A.2 TLS 1.2 Handshake Protocol

We briefly describe the TLS 1.2 handshake protocol in certificate-based unilateral server-authentication mode based on the Internet Engineering Task Force (IETF) standard’s specifications [13]. A detailed description of the protocol can be found in [13]. As depicted in Fig. 3, the handshake protocol works as follows: First, the client sends a ClientHello (CH) message to initiate a connection with the server. This message contains: the maximum version of TLS that the client supports ($vmax _I$); the client’s random value ($n_I$); optionally, a session identifier if the session is resumed ($session _{ ID }$); a list of ciphersuites that the client supports ordered by preference ($[a_1,\ldots ,a_n]$); a list of compression methods that the client supports ordered by preference ($[c_1,\ldots ,c_n]$); and finally, an optional list of extensions ($[e_1,\ldots ,e_n]$).

Second, the server responds with a ServerHello (SH) message. This message contains: the server’s selected TLS version ($v_R$); the server’s nonce ($n_R$); optionally, a session identifier in case of session resumption ($session _{ ID }$); the selected ciphersuite based on the client’s proposed list ($a_R$); the selected compression method from the client’s proposed list ($c_R$); and optionally, a list of the extensions that are requested by the client and supported by the server ($[e_1,\ldots ,e_n]$). After that, the server sends a ServerCertificate (SC), which contains the server’s certificate ($cert _R$) if server authentication is required. Then, if the key-exchange algorithm is (EC)DHE (see [14] for details about the DH algorithm), the server sends a ServerKeyExchange (SKE) message. This message must not be sent when the key-exchange algorithm is RSA (see [30] for details about the RSA algorithm). The ServerKeyExchange contains the server’s (EC)DHE public-key parameters and a signature over a hash of the nonces ($n_I$ and $n_R$) and the (EC)DHE key parameters. In case of DHE (i.e. Finite Field DHE), the key parameters are: the prime (p), the generator (g), and the server’s public value ($g^b$). We omit describing the ECDHE parameters and we refer the reader to [7] for details about ECDHE key parameters. Finally, the server sends a ServerHelloDone (SHD) to indicate to the client that it finished its part of the key-exchange.

Third, upon receiving the ServerHelloDone the client should verify the server’s certificate and the compatibility of the server’s selected parameters in the ServerHello. After that, the client sends a ClientKeyExchange (CKE) to set the pre-master secret. The content of the ClientKeyExchange depends on the key-exchange algorithm. If the key-exchange algorithm is RSA, the client sends the pre-master secret encrypted with the server’s long-term RSA public-key ($[ pms ]^{ pk _R}$) as illustrated in Fig. 4. If the key-exchange algorithm is DHE, the client sends its DHE public value ($g^a$) to allow the server to compute the shared DHE secret-key ($g^{ ab }$) as illustrated in Fig. 3. After that, both parties compute the master secret ($ms$) and the session keys: ($k_I$) for the client, and ($k_R$) for the server, using Pseudo Random Functions PRFs as follows: (kdf_ms) takes the $pms$ and nonces as input and produces the $ms$, while (kdf_k) takes the $ms$ and nonces as input and produces the session keys $k_I$ and $k_R$. There are more than a pair for the session keys, i.e. separate key pairs for encryption and authentication, but we abstract away from these details and refer to the session keys in general by the key pair $k_I$ and $k_R$. Finally, the client sends ChangeCipherSpec (CCS) (this message is not considered part of the handshake and is not included in the transcript hash), followed by a ClientFinished (CF) which is encrypted by the just negotiated algorithms and keys. The ClientFinished verifies the integrity of the handshake transcript (i.e. the $log$ (We adopted the term $log$ from [5]). The ClientFinished content is computed using a PRF which serves as a Message Authentication Code (MAC) that we denote it by (mac) over a hash of the handshake transcript starting from the ClientHello up to, but not including, the ClientFinished (i.e. mac of $log_1$ as shown in Figs. 3 and 4), using the $ms$ as a key. This mac needs to be verified by the server.

Fourth, similar to the client, the server sends its ChangeCipherSpec (CCS) followed by a ServerFinished (SF) that consists of a mac over a hash of the server’s transcript up to this point ($log_2$), which also needs to be verified by the client.

Once each communicating party has verified its peer’s Finished message, they can now send and receive encrypted data using the established session keys $k_I$ and $k_R$. If “False Start” [23] is enabled, the client can send data just after its ClientFinished, and before it verifies the ServerFinished.

Fig. 3.

Message sequence diagram for TLS 1.2 with (EC)DHE key-exchange.

Fig. 4.

Message sequence diagram for TLS 1.2 with RSA key-exchange.

1.3 A.3 TLS 1.3 Handshake, Major Changes

This section is not meant to provide a comprehensive description of TLS 1.3, but to highlight some major changes in TLS 1.3 over its predecessor TLS 1.2. Similar to the previous section, we assume certificate-based unilateral server-authentication mode. A full description of the latest draft of TLS 1.3 (as of this writing) can be found in [29]. Figure 5 illustrates the Hello messages in TLS 1.3, where the TLS version and algorithms are negotiated.

One of the first changes in TLS 1.3 is prohibiting all known weak and unrecommended cryptographic algorithms such as RC4 for symmetric encryption, RSA and static DH for key-exchange, etc. In addition, TLS 1.3 enforces Forward Secrecy (FS) in both modes: the full handshake mode and the session resumption mode (with the exception of the early data in the Zero Round Trip Time (0-RTT) mode that is always sent in non-FS mode), compared to TLS 1.2, where FS is optional in the full handshake mode, and not possible in the session resumption mode. It also enforces Authenticated Encryption (AE) and standard (i.e. non arbitrary) DH groups and curves. Furthermore, unlike TLS 1.2 where all handshake messages before the Finished messages are sent in cleartext, all TLS 1.3 handshake messages are encrypted as soon as both parties have computed shared keys, i.e. after the ServerHello message.

The ClientHello message in TLS 1.3 has major changes. First, in terms of parameters, the following parameters have been deprecated (but still included for backward compatibility): the maximum supported TLS version ($vmax _I$) has been substituted by the “supported_versions” extension ($[v_1,\ldots ,v_n]$); the session ID ($session _{ ID }$) has been substituted by the “pre_shared_key” extension; the compression methods list [$c_1$,...,$c_n$] are not used any more and sent as a single byte set to zero ($c_I$). In addition, unlike TLS 1.2 where extensions are optional, in TLS 1.3, the ClientHello extensions are mandatory and must at least include the “supported_versions” extension. Second, in terms of behaviour, the server can optionally respond to a ClientHello with a HelloRetryRequest (HRR), a newly introduced message in TLS 1.3 that can be sent from server to client to request a new (EC)DHE group that has not been offered in the client’s “key_share” extension ([...,($G_I,g^i$),...]) which is a list of “key_share” entries (“KeyShareEntry”) ordered by preference, but is supported in the client’s “supported_groups” extension ([...,$G_R$,...]). The HelloRetryRequest can also be sent if the client has not sent any “key_share”. After the HelloRetryRequest, the client sends a second ClientHello with the server’s requested “key_share” ([$G_R,g^{ i2 }$]).

Upon receiving a ClientHello, if the client’s offered parameters are supported by the server, the server responds with a ServerHello message. The ServerHello has two major changes: First, unlike TLS 1.2 where the extensions field is optional, in TLS 1.3, the ServerHello must contain at least the “key_share” or “pre_shared_key” extensions (the latter is sent in case of session resumption which is beyond our paper’s scope). Second, as a version downgrade attack defence mechanism (in addition to other mechanisms), the last eight bytes of the server’s nonce $n_R$ are set to a fixed value that signals the TLS version that the server has received from the client. This allows the client to verify that the versions that were sent in the ClientHello have been received correctly by the server. This is because the nonces are signed in the TLS 1.3 CertificateVerify and in the TLS 1.2 ServerKeyExchnage as well.

Fig. 5.

Message sequence diagram for TLS 1.3 Hello messages with DHE key-exchange and HelloRetryRequest. Deprecated parameters that are included for backward compatibility are marked with color.

Finally, the TLS 1.2 ServerKeyExchange is not used in TLS 1.3. This is a result of shifting the key-exchange to the Hello messages, namely to the “key_share” and “pre_shared_key” extensions. The signature over the key parameters that is sent in the ServerKeyExchange in TLS 1.2 to authenticate the server’s key parameters is now sent in a new message, namely the ServerCertificateVerify which is sent after the server’s Certificate message. Most importantly, the signature in the ServerCertificateVerify is computed over a hash of the full transcript from the Hello messages up to the Certificate, and not only over the key parameters as in TLS 1.2 ServerKeyExchange. The signature over the full transcript provides protection against downgrade attacks that exploit the lack of ciphersuite authentication in the ServerKeyExchange as demonstrated in [2] and [4].