In the first part of this two-part blog we covered certain performance improving features of TLS 1.3, namely 1-RTT handshakes and 0-RTT session resumption. In this part we shall discuss some security and privacy improvements.
Remove Obsolete and insecure cryptographic primitives
Remove RSA Handshakes
When RSA is used for key establishment there is no forward secrecy, which basically means that an adversary can record the encrypted conversation between the client and the server and later if it is able to break the RSA public key (could take years or could be because the attacker was able to get his hands on the private key), all the recorded conversations can be decrypted. In some cases (like when SSLv2 is enabled), RSA key establishment is vulnerable to DROWN. You can still use RSA certificates with TLS 1.3, but all the key establishment has to be done with DH (either finite field or elliptic curve). The primary reason why RSA key exchange was removed was Bleichenbacher and similar attacks; getting PFS is a welcomed bonus.
Remove weak primitives
TLS 1.3 also removes RC4, SHA1, MD5 (vulnerable to SLOTH) which are all considered weak or broken.
No CBC mode
Security weaknesses in CBC Mac-Then-Encrypt mode has been long established and has been the cause behind various named flaws like Lucky-13 and POODLE.
No ChangeCipherSpec
This was removed because it is no longer necessary to mark end of handshake – the two first exchanged messages do that. As an aside, ChangeCipherSpec caused famous CCS injection flaw in OpenSSL.
No negotiation compression
Removes the option of negotiating compression which is vulnerable to CRIME.
Re-key mechanism
Replace session renegotiation, with a simple re-key mechanism.
Removing PKCS #1 v1.5 and some ECDHE groups
PKCS #1 v1.5 encryption in the RSA key exchange is removed since it has multiple flaws. PKCS#1 v1.5 signature algorithm, which isn’t broken, is removed mostly as a “just in case” and to base the protocol on new cryptographic primitives that were designed from ground up to follow good practice. A lot of weak and non-standard ECDHE groups were removed including the custom FFDHE groups now that we finally have a mechanism for clients to advertise key sizes to server.
New cryptographic features and primitives
Anti-downgrade feature
Implementations which support TLS 1.3 will also continue supporting TLS 1.2 for a long time to ensure backward compatibility with older clients. This, however, can lead to downgrade attacks.
A man-in-the-middle (MITM) attacker could modify the CLIENTHELLO message to trick the TLS server into believing that the client only supports TLS 1.2 and less and then use any flaws discovered in TLS 1.2 to complete the MITM attack (read or modify messages between client and the server). TLS 1.3, however, offers an anti-downgrade feature, which is an enhancement of the previous downgrade mechanism in TLS 1.2 FINISHED messages.
When a TLS 1.3 server gets a request from the client to downgrade the following happens:
-
If negotiating TLS 1.2, TLS 1.3 servers MUST set the last eight bytes of their Random value to the bytes: 44 4F 57 4E 47 52 44 01
-
If negotiating TLS 1.1, TLS 1.3 servers MUST, and TLS 1.2 servers SHOULD, set the last eight bytes of their Random value to the bytes: 44 4F 57 4E 47 52 44 00
TLS 1.3 clients receiving a TLS 1.2 or below ServerHello MUST check that the last eight bytes are not equal to either of these values. TLS 1.2 clients SHOULD also check that the last eight bytes are not equal to the second value if the ServerHello indicates TLS 1.1 or below. If a match is found, the client MUST abort the handshake with an “illegal_parameter” alert. This mechanism provides limited protection against downgrade attacks over and above that provided by the Finished exchange. Because the ServerKeyExchange, a message present in TLS 1.2 and below, includes a signature over both random values, it is not possible for an active attacker to modify the random values without detection as long as ephemeral ciphers are used.
New improved session resumption features
Session resumption using tickets and identifiers have been obsoleted by TLS 1.3 and has been replaced by PSK (pre-shared key) mode. A PSK is established on a previous connection after the handshake is completed, and can then be presented by the client on the next visit. Also, forward secrecy can be maintained by limiting the lifetime of PSK identities sensibly. Clients and servers may also choose an (EC)DHE cipher suite for PSK handshakes to provide forward secrecy for every connection, not just the whole session.
New ECC curves
TLS 1.3 includes two additional ECC curves: Curve 25519 and Curve 448. These new curves can easily be implemented in constant time on common hardware (as opposed to the other elliptic curves).
Privacy of certificates during handshake
TLS 1.3 has provision for what it calls “Encrypted Extensions”. The server sends the EncryptedExtensions message immediately after the ServerHello message. This is the first message that is encrypted under keys derived from the “server_handshake_traffic_secret”. The rest of the handshake after this is encrypted, including certificate transmission of certificates (both client and server). This offers protection of extension data from eavesdropping attackers.
Inclusion of ChaCha20/Poly1305
TLS 1.3 only allows AEAD cipher suites, which means AES-GCM/AES-CCM and ChaCha20-Poly1305 are the only options available. They are intended to improve performance and power consumption in devices with acceleration for AES (note: ChaCha20 is not new in TLS 1.3; it is already supported and deployed in TLS 1.2).
Implementations
OpenSSL is currently working on including TLS 1.3 support. It seems likely that OpenSSL 1.1.1 will include this.
NSS 3.29 contains support for TLS 1.3, which is enabled by default. Note that although NSS has support for draft versions of TLS 1.3, one can’t deploy the current NSS and expect it to work with implementations that will deploy real, finished TLS 1.3, as it doesn’t use the same version ID as the finished version will.
GnuTLS is working on TLS 1.3 support.
Certain fuzzers, like the the famous tlsfuzzer, is going to include support for fuzzing TLS 1.3 protocol soon.