1490902 - TLS 1.3 Adds & Prioritizes 3 Cipher Suites with inferior security to TLS 1.2 Suites

Status: RESOLVED INVALID

(Core :: Security: PSM, defect, P1)

Description

[bojanga]

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0
Build ID: 20100101

Steps to reproduce:

Enable TLS 1.3


Actual results:

3 Extra less secure ciphers were added to the top of the list.

As was discussed here: https://bugzilla.mozilla.org/show_bug.cgi?id=1342272

Quote: TLS 1.3 does not negotiate a key exchange algorithm using cipher suites. The key exchange algorithm is negotiated separately. Also, TLS 1.3 only supports key exchange algorithms that are forward secret (ECDHE and FFDHE).

Then why with TLS 1.3 enabled, we see these weaker cipher suites suddenly appear at the top? 

Confirm by testing here: https://www.ssllabs.com/ssltest/viewMyClient.html

TLS_AES_128_GCM_SHA256 (0x1301)   Forward Secrecy 	128
TLS_CHACHA20_POLY1305_SHA256 (0x1303)   Forward Secrecy 	256
TLS_AES_256_GCM_SHA384 (0x1302)   Forward Secrecy 	256

With TLS 1.3 disabled, these three ciphers are also disabled. Why is that? Does this have to do with middle box compatibility? 

TLS 1.3 adoption has been held back for the past year by SSL/TLS proxies and other load balancing and traffic monitoring middleboxes that break connections.

Browser vendors have held back adding TLS 1.3 by default because tests showed that the error rates for establishing TLS connections grew unacceptably high when this version was enabled. The results were somewhat unexpected because the TLS protocol was built to be agile.

Middlebox Compatibility extensions were designed to counter this problem, the end result is a hack. The on-wire format of TLSv1.3 is tweaked, to make the TLS 1.3 handshake resemble TLS 1.2 session resumption requests, which is just enough to make the connection being able to pass broken middleboxes.

Source: https://news.ycombinator.com/item?id=17739342

There are two versions of the Diffie-Hellman algorithm, a fixed/ static version [the ciphers added by TLS 1.3 use static keys], where both parties use the same public/ private keys (and hence same shared key) across all their previous and future conversations; and an ephemeral version, where one party keeps changing its public/ private key (and hence the shared key) (perfect forward secrecy)

ECDSA certificates contain an ECC public key. ECC keys are better than RSA & DSA keys in that the ECC algorithm is harder to break. 

So by enabling TLS 1.3, a higher priority is given to lower quality security keys. This makes no security sense!. Please elaborate on this and implement a feature to change priority of cipher suites!

Comment 1

[bojanga]

I want to elaborate the fact these 3 inferior cipher suites can only be disabled by disabling tls 1.3.

Comment 2

[Darkspirit]

(In reply to bojanga from comment #0)
> 3 Extra less secure ciphers were added to the top of the list.
> 
> As was discussed here: https://bugzilla.mozilla.org/show_bug.cgi?id=1342272

And you got an answer there: bug 1342272 comment 7

> Quote: TLS 1.3 does not negotiate a key exchange algorithm using cipher suites. The key exchange algorithm is negotiated separately. Also, TLS 1.3 only supports key exchange algorithms that are forward secret (ECDHE and FFDHE).

> TLS_AES_128_GCM_SHA256 (0x1301)   Forward Secrecy 	128
> TLS_CHACHA20_POLY1305_SHA256 (0x1303)   Forward Secrecy 	256
> TLS_AES_256_GCM_SHA384 (0x1302)   Forward Secrecy 	256

I am just a Firefox user.
These are TLS 1.3 ciphers. They are either used with ECDHE_RSA, (FF)DHE_RSA or ECDHE_ECDSA. FFDHE is DHE.
As you quoted, the configuration of TLS 1.3 is more like OpenSSH.
If you wanted to disable a specific FFDHE method or ECDHE curve you might want to vote for bug 1306582.
Marking as "not a bug".