Updating TLS? Use cryptographic entropy for more secure keys
Cryptographic entropy is necessary to secure session encryption keys in TLS 1.2, but RSA key transport is not supported in TLS 1.3. Discover the causes for concern with Judith Myerson.
The recent Transport Layer Security protocol update to TLS version 1.3 dropped support for some potentially insecure or less secure protocols and algorithms. In particular, support for the RSA key transport mechanism for key exchange was dropped from TLS 1.3. This change was made because encrypting network traffic with session keys is not possible without sufficient cryptographic entropy to keep the session keys secure.
Hints to the necessity of sufficient cryptographic entropy to protect TLS session keys can be found in a recently revised NIST draft, "Guidelines for the Selection, Configuration and Use of Transport Layer Security (TLS) Implementations," which calls for all government agencies to support TLS 1.3 by January 2024.
In this tip, we'll take a look at why TLS 1.2 and TLS 1.3 are mandated, why some organizations may need to retain support for RSA key transport in TLS 1.2, and how organizations can safely use RSA key transport with sufficient cryptographic entropy.
NIST's recently proposed draft includes some mention of the importance of entropy, as the authors note that RSA key transport is a "convenient method for key exchange when the server's certificate contains an RSA public key." This approach has several drawbacks, however; the first of which is that the client is responsible for secret generation. "If the client does not have sufficient entropy to generate the secret, the security of the session will suffer."
Now that the TLS 1.3 protocol update has been published, government agencies -- as well as enterprises -- must find ways to securely implement the new protocol version while also supporting TLS 1.2, which still allows for the use of some protocols and algorithms that may be vulnerable to attack.
Understanding the players: TLS versions
TLS 1.2, as specified in RFC 5246, includes the ability to use SHA-1 algorithms for hashing and to create message authentication codes and pseudorandom function (PRF) computations.
TLS 1.3, as specified in RFC 8446, which was published last year, includes a new handshake protocol and a new key derivation process that uses the HMAC-based Extract-and-Expand Key Derivation Function -- replacing the PRF function in TLS 1.2.
The updated specification removed cipher suites that use a static RSA key exchange, Diffie-Hellman key exchange, the Cipher Block Chaining mode of operation, or SHA-1, all of which have been shown to be potentially problematic for securing traffic. Furthermore, the RSA key transport as supported in TLS 1.2 doesn't enable forward secrecy -- though that version of TLS does provide some steps to mitigate attacks.
Many protocol extensions for TLS 1.2 will stop working with TLS 1.3, and NIST is deprecating the use of RSA key transport for TLS 1.2 or earlier for government agencies. However, NIST is still allowing its use for some applications and environments during the transition period to TLS 1.3.
TLS vulnerability and key management concerns
RSA key transport -- the mechanism by which a client and server securely exchange session keys -- is available in TLS versions 1.2 and earlier. However, NIST considers this key exchange mechanism problematic when the server's certificate contains an RSA public key, largely because the client may not use sufficient entropy to generate a random-enough premastered key.
NIST divides the minimum requirements for TLS servers into TLS protocol version support, cryptographic support, extension support, session resumption, compression methods, operational considerations, server keys and certificates, and client authentication.
Weakness in a private key associated with a certificate is often caused by a lack of sufficient cryptographic entropy in the system. An attacker could use this weakness as a way to gain access to encrypted data.
Creating a strong private key is often a function of how much cryptographic entropy is available on the current system, and an attacker who can discover either the server or the client secret keys can also masquerade as the weak key holder in order to decrypt network session data. Worse, the attacker can also get a certificate authority to issue a public key certificate to more authoritatively pose as the targeted entity.
Another issue is that the client and server both contribute randomness to the TLS session keys used to protect messages exchanged during an active TLS session. Attackers do not need to recover these keys. The session keys are not used to protect data at rest, and all the versions of TLS provide mechanisms to store a key related to a session that a user can resume. Keys for a session a user can resume are derived during an abbreviated handshake that uses the stored key as a form of authentication, which can be reversed by a successful attacker.
The success of contributing random numbers to a session key depends on using sufficient cryptographic entropy to generate the relevant keys.
TLS minimum requirements
In its proposed guidelines for TLS, NIST divides the minimum requirements for TLS servers into TLS protocol version support, cryptographic support, extension support, session resumption, compression methods, operational considerations, server keys and certificates, and client authentication.
The minimum requirements for a TLS client are the same as TLS servers; however, client keys and certificates and server authentication differ. Servers that support government-only applications must be configured to use TLS 1.2, and they should be configured to use TLS 1.3. These servers should not be configured to use versions earlier than TLS 1.2.
Likewise, servers that support citizen or business-facing applications connecting to the client must be configured to negotiate TLS 1.2 and TLS 1.3. The client must be configured to use TLS 1.2 and should be configured to use TLS 1.3. The client may also be configured to use versions earlier than TLS 1.2 to facilitate communication with private sector servers. All clients must be configured to use TLS 1.3 by Jan. 1, 2024, in order for TLS 1.2 and TLS 1.3 to coexist.
Insufficient entropy vulnerability
RSA key transport is available for TLS 1.2 and earlier. NIST considers insufficient entropy vulnerability a drawback of this key exchange mechanism when the server's certificate contains an RSA public key. RSA key transport doesn't enable forward secrecy, and its padding scheme has TLS vulnerabilities. Likewise, an attacker could obtain the RSA key to decrypt TLS traffic under certain conditions, and side-channel information may be disclosed due to invalid PKCS #1 v1.5 padding.
In order to mitigate such attacks, admins should reference RFC 5246 for TLS 1.2, as it contains several steps companies should follow, though these techniques don't always work. Because RSA key transport using PKCS #1 v.5 is vulnerable to a Bleichenbacher attack, the CERT Coordination Center identifies the vulnerability as an example of that attack and recommends disabling RSA key transport or applying software updates.
