Why it is wise to use TLS 1.3?

Many CTO often face the difficult question what to choose:

• the most strict security measures, which though prevent old Android and Windows clients to work with business web and mobile applications

• use the less reliable ciphersuites on their web portals and REST API, but allow a wider audience of users

To make the right decisions usually it is required to compare impact of client audience reduction and the size of the risk. The impact and business losses due to the client drain is quite obvious, however the risk of old TLS version (say 1.2) is not so clear. Let's try to figure it out.

First we will look into key specialites of the TLS 1.3 design:

• It is faster that TLS1.2, especially on the low latency connections, like mobile networks. The speed is achieved with the aid of a shortened handshake phase, which requires only one round trip (RTT) in TLS1.3 instead of two in the older TLS versions. In addition it is possible to use a fast start and send the data in the first TLS1.3 packets (HTTP GET requests), which gives and additional boost to the protocol speed. Modern web application makes hundreds of requests, and reducing the response time from 250ms to 50ms for example, drastically improves the mobile user experience. Also there is a session resumption mechanism which allows 0-RTT (zero round trip time). Most of TLS connections are in deed a resumption of the previous ones, therefore 0-RTT increases their speed. Cloudflare supports 0-RTT TLS 1.3 already several years, Google Chrome implemented the support in May 2021. One important note – 0-RTT increases the risk of replay attacks and removes the forward secrecy property from the connections (without this property the attacker can record a lot of traffic and recover the plain text after stealing the original encryption keys). However in many cases these risks are quite acceptable, web-applications are very resistant to the replay attacks, as they experience them even due to the network errors quite often.

• the EncryptedClientHello feature allows to hide the server name in the browser request. So, whenever your server is behind a Cloudflare or other CDN then traffic interception will not allow to identify the target server. Important note – you will need to have a DNS over HTTP in your browser. These two settings drastically improve client privacy.

• All legacy and dangerous functionality was removed from TLS version 1.3: SHA-1, RC4, DES, 3DES, AES-CBC, MD5, vulnerable DH groups, weak export ciphers (the reason of FREAK/LogJam attack success).

Let’s look at the historical attacks on TLS:

• POODLE – vulnerability in the SSL3.0. Due to incorrect handling of errors in the CBC mode, particularly the improper padding error oracle it was possible to launch an attack at the SSL3.0 session. There were no protection by the MAC on the padding message block. The attacker, who intercepts user traffic forces the user to make multiple requests to the victim site. The requests can be achieved though an iframe+JavaScript injection. After each request the attack is modifies its encrypted blocks in the TLS session and observes the server response. In general it is enough 256 requests to recover one bye of the session cookie.

• Golden poodle, Zombie poodle, 0-length OpenSSL, Sleeping POODLE – modified version of the SSLv3 attacks which use just a different padding/MAC error oracles for the CBC ciphersuites. TLS1.3 is immune as it does not use the CBC mode.

• BEAST – the attack on the TLS1.0 and earlier versions. It is based on the important design weakness. The IV (initialization vector) which is a part of the CBC mode was not chosen randomly for each act of encryption, but rather the last ciphertext block from the previous message was used. The attacker using an iframe+JS technique sends the requests, and tries to repeat the one of the previous ciphertext blocks. Usually it is sufficient 256 requests to recover a cookie byte.

• Lucky13 – uses the time based side channel during the MAC calculation, TLS 1.2 and earlier versions in the CBC mode use MAC-Encode-Encrypt. This means that the MAC is calculated from the plain text, then it is encoded and then encrypted. The MAC (HMAC indeed) is calculated from the 64 byte block, however due to TLS formatting and header, HMAC effectively calculated from the 55 bytes bock. If there’re more than 55 bytes in the block the HMAC should be calculated from two blocks. This requires more CPU cycles and time. The attacker using the iframe+JS injection makes the requests to the server. If the response time is shorter than we can recover a byte of plain text (it equals to the XOR of 0x1 with the modified by the attacker byte value. The amount of efforts to recover one byte is proportinal to the 256. Current OpenSSL implementations are trying to remove MAC calculation side channels, however the more reliable way is to completely turn off the CBC mode.

• Lucky microseconds – the attack on the Amazon TLS implementation. Amazon tried to mitigate the Lucky13 attack with the aid of the constant number of HMAC function calls and random delays. However researchers found that even if the HMAC calls are constant, the number of internal compression HMAC calls is different and depend on the data size. Rand delays were not so random due to the weaknesses in the Unix sleep/usleep library functions.

• CRIME – this bug is based on the weakness related to the data compression before encryption. The attacker may send an HTTP request with iframe+JS technique and in his controlled field enters the “Cookie: sessionid=?” value, where the “?” is going from 0x00 to 0xFF in each subsequent request. If the attack guesses the first byte of the real cookie, then the encrypted request will be a bit shorter. In such a way the attack byte by byte recovers the whole session cookie. The attack had several demonstrations and can be considered to be practical. Most of modern TLS clients and servers turned off the TLS compression in TLS1.2 settings. The TLS 1.3 completely remove the compression from the design.

• TIME – this attack uses the presents of HTTP response compression. For its successfull implementation the attack needs the way to measure the server response time (for example due to the SOP leaks) and he needs a way to impact the the server response (reflect the submitted data back). For example if he needs to find out the CSRF token, he duplicates its start in the server response. If the attacker guesses the first byte of the CSRF token the resposne will be a bit shorter. He specially aligns the responses so whenever the response is long, more TCP segments is required. The time of TCP segment transmission is quite notable for example on the mobile connections. The attack is very practical and does not depend on the TLS version.

• BREACH – the attack is similar to the TIME one. The attacker conducting the MtM and iframe+JS techniques can determine the change in the server response size and recover the CSRF token or other secret. Does not depend on the TLS version.

• FREAK – the attack exploits the support of the export ciphers by the client and the server (512 bit RSA). The attacker substitutes the client request with the list of support ciphers and leaves only the weak ones. TLS1.3 removed the weak ciphers from the design. The attack is very practical on the earlier TLS versions.

• Logjam – a similar to the FREAK attack, however the target is not RSA, but a DH key exchange protocol. The attack is facilitated as there are only few DH groups which are used by a majority of the web servers. The attack can do in advance a required precomputation and recover the exponents in a matter of minutes. This is quite enough to survive TCP session limits and hack the secure conversation.

• ECHE/DHE mixing. At least TLS 1.2 has a probability to wrong interpret EDHE key exchange values as DHE ones. In this case the DHE parameters will be weak and it may be possible to recover the common key. The probability of successful attack is low (at least it is required to make 2^32 connections).

• Raccoon. TLS 1.2 and earlier versions require that leading zeroes at the beginning of the premaster secret should be withdrawn. This affects the time of the common key generation (with the aid of the hash function call). Knowing the first bits of g^a and sending modified g^(a+ri) and measuring their most significant bits the attacker can solve the mathematical task and find out the g^a. The attack probability is low and it is considered non-practical. Anyway it was fixed in the TLS 1.3.

• Tripple handshake. TlS 1.2 and earlier are vulnerable to the “tripple handshake” attack. The attacker is requires from the client to authenticate with its digital certificate and forwards that data to the victim server. The server accepts the forwarded credentials and authenticates the attack as the client. TLS 1.3 fixed that problem.

• Privacy leak. Using the TLS compression weakness it is possible to precisely determine what files is being downloaded from the server. TLS 1.3 fixed that problem by disabling the compression.

• SWEET32 – attack on the ciphers with a short block size (64 bits). Thanks to the birthday paradox attack it is suicient for the attacker to collect 2^32 blocks to find a collision between them. In the CBC mode that means he can find a XOR of two blocks of plain text. Usually the attack may know the first block (e.g. the beginning of the HTTP header Cooke: sessiond=). And therefore he can identify the bytes of the cookie. The attack is practical through the iframe+JS technique. TLS 1.3 fixed the problem by disabling 64 bit blocks ciphers 3DES and Blowfish.

• SLOTH attack uses the fact that TLS 1.2 allows by choose the client authentication mechanism (particularly the MD5 hash as part of that mechanism). It is enough 2^39 operations to find out the collision (hash from the previous messages of the TLS handshake). Then the attacker adds the digital signature of the client and impersonates him in from of the server. The attack is practical and requires only a few hours and a small budget. It was fixed in TLS 1.3.

• CurveSwap. In the TLS 1.2 and earlier version the list o supported elliptic curves during the TLS handshake is not authenticated until the final message. Therefore the attack can inject its own weak curve, and during the handshake find out the discrete logarithm of the DH parameter and recover the master key. Then he forges the final message and intercepts all traffic. The most weak curve is sect163k was used at least in 0.1% of most popular sites. In addition the ECC implementations should verify that client submitted points are valid and conform to certain properties. Otherwise it is possible to launch a set of attacks – invalid curve point attacks, small subgroup attack, not optimized multiplication errors, etc.

• HEIST. We’re listing it here for reference. It is a generic framework to identify the server response size with the aid of TCP segments. It is similar to the TIME TLS attack, but more universal.

• SMACK, SKIP-TLS. As it was found some TLS implementations (client implementations) are not strictly following the TLS specification and can continue its work even if some TLS messages are skipped. It allows for the attacker just to drop some messages during the handshake and get the unencrypted session. These are not bugs of some particular TLS version, but rather mistakes of software developers. SMACK – is a generic term of the TLS state attacks.

• ROCA – due to the bug in the RSA implementation (weak prime numbers generation) in the popular library a lot of RSA keys were affected. The problem is related to the X509 certificates, not the key exchange mechanism, so affects all TLS versions.

• DUHK – a number of Fortinet devices were using a weak random number generator, which was initialized with the embedded in the firmware key. After the key extraction of any device it was easy to decrypt the VPN traffic from another devices. This bug did not related to the TLS protocol version.

• DROWN – attack on the TLS 1.2 with the aid of SSLv2 (cross protocol attack if the server supports both protocols). The attacker after ~10k connections can find out the master encryption key of the TLS 1.2. The direct Bleichenbacher attack against TLS1.2 is not working (as the oracle was fixed), however the SSLv2 with the export grade cryptography has this oracle and allows to get some information about the common bytes of the pre-master key in the TLS1.2 session. The attack is practical. TLS1.3 is protected against it as it is does not use RSA for key exchange. However there some research that shows how the cross protocol attack with the aid of TLS1.2 can be launched on the TLS1.3.

• BERserk – due to the bug in the PKCS#1.5 implementation in the Mozilla NSS library it was possible to forge RSA signature. The bug does not depend on the TLS version.

• CREAM – the name for the attack created by one of bloggers, but I liked it. Here I want to mention multiple architecture and implementation specific attacks. The CREAM particularly relates to the CPU cache design and that through cache time access it is possible to leak AES key bits. Another techniques include FLUSH+RELOAD/clflush, PRIME/PROBE (rdtsc measurements). Spectre/Meltdown should also be considered in a similar threat models.

• ROBOT – the new appearance of the old Bleichenbacher attack. There were found multiple oracles which report the validity of the PKCS#1.5 padding during RSA key exchange. TLS1.3 does not use RSA key exchange and not vulnerable.

• Bleichenbacher – the attack from the 1998 year which was made popular again due to the ROBOT oracles. As it is known the attacker who knows at least one bit of a plain text during the chosen cipher text attack can later recover all messages. Due to the bugs in the PKCS#1.5 padding validation the attacker can obtain information whether the first bytes are 00 02 (valid padding) or something else (invalid padding). It was enough roughly 2^20 ~ 1mln messages to recover the original plain text. TLS 1.3 does not use RSA for key exchange and not vulnerable.

• RC4NOMORE – attack exploits the RC4 weakness. The cipher has many dependencies (biased) bytes of the cipher text (they’re not random). The attack authors utilized the old attacks (which required at least 500GB of cipher text - AlFardan et al./Isobe et al. Attacks) but added newly discovered dependencies (simlar ones to the Mantin’s ABSAB and Fluhrer-McGrew). In general some of them were known already (Manin and Shamir, Maitra et al., Sen Gupta, et al., Paul and Preneel), however they were not considered practical to break the cipher. The attacker can use iframe + JS to generate 75GB of traffic which is sufficient to recover the secret cookie (which is surrounded by the known text) in a matter of minutes. The attack is very practical. TLS1.3 prohibites RC4.

• Bar Mizvan attacks on RC4. Uses the so called Invariance wakness (properties of the keys which are preserved during the encryption) including FMS (S. R. Fluhrer, I. Mantin, and A. Shamir. Weaknesses in the key scheduling algorithm of RC4). The least significant bits of the ciphertext are not random and that allows to recover the information about bytes of open text. It is available only 100 bytes of the text (without the headers only 64). To identify that least significant bits of the plain text it is required to collect a huge number of TLS messages to get probability of a weak RC4 key. Knowledge of the least significant bits reduces the time to brute force an unknown secret (e.g. session cookie). For example the 16 bytes ASP.Net cookie with entropy of 5 bits per character the attack removes 16 bits and reduces the keys space from 2^80 to 2^64. The attack seems not practical, but TLS1.3 completely removed RC4.

• CSS injection. The attack is very specific to the OpenSSL implementation, but we’re listing it here for reference. Very interesting the way how it was found. The researcher used the Coq language (similar to ATS) to model the protocol. OpenSSL incorrectly allows to change the session cipher after session establishement and use the weak ciphers. TLS1.3 reduces this risk as it prohibits weak ciphers at all.

• Alert attack. TLS (as we think the version 1.2 and earlier ones) allows to ignore the TLS alert messages when they’re fragmented in a malicious way. The attacker sends the first part of the fragment (which is not covered by the session integrity protection), and when the real alert bytes are coming they’re wrongly interpreted. TLS1.3 as per RFC8446 prohibits the alert message fragmentation and not vulnerable (see 5.1 and 6 sections of the RFC document).