1869515 - HTTP3 ignores TLS1.3 settings

Status: RESOLVED WONTFIX

(Core :: Networking: HTTP, defect, P2)

Description

[[:Jorropo]]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:120.0) Gecko/20100101 Firefox/120.0

Steps to reproduce:

• Go to about:config
• Ensure security.tls13.aes_128_gcm_sha256 is false (and that other tls13 settings are default to on)
• Navigate to a website which supports HTTP3 and where the server prefers the aes_128_gcm_sha256 suite. For example at time of this writing:
  • https://cloudflare-quic.com/
  • https://www.youtube.com/
• Click on the pad lock icon left of the address bar.
• Click: "Connection is Secure >"
• Click: "More Information"

Actual results:

Under "Technical Details" I see "Connection Encrypted: TLS_AES_128_GCM_SHA256"

Expected results:

Under "Technical Details" I see "Connection Encrypted: TLS_AES_256_GCM_SHA384"
or
Under "Technical Details" I see "Connection Encrypted: TLS_CHACHA20_POLY1305_SHA256"

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Firefox::Address Bar' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Monica Chiorean]

I was able to reproduce the issue on Ubuntu 22.04 using Firefox build 120.0, I got the "Connection Encrypted: TLS_AES_128_GCM_SHA256" Under "Technical Details" for https://www.youtube.com/.
Marking issue as New.

Comment 3

[Dana Keeler (she/her) [:keeler]]

Seems more like a neqo issue. netwerk/socket/neqo_glue/src/lib.rs probably needs to call set_ciphers at some point.

Comment 4

[only1ryan]

This issue might be related to Bug 1771972. By the way, bugzilla.mozilla.org behaves in the same, incorrect fashion.

Comment 5

[Randell Jesup [:jesup] (needinfo me)]

FYI, I think this predates your involvement in neqo (or most of it). Should this be higher rank to get into the queue?

Comment 6

[Max Inden]

For the record:

• Yes neqo_glue and thereby the entire Firefox QUIC stack currently ignores the tls13 related prefs.

• Our neqo-client test client does allow users to set ciphers. In other words, doing the same in neqo-glue is not a large project.

Should this be higher rank to get into the queue?

While I can do the work, I don't think I should make the prioritization decision, given my limited knowledge of TLS. Maybe someone from the NSS team? Dennis, do you think being able to set security.tls13.aes_128_gcm_sha256 and the like for QUIC is a relevant Firefox feature that we should prioritize?

Comment 7

[only1ryan]

Is the priority of the cipher suites aes_128, aes_256, chacha20_poly1305? This seems to be from weakest to strongest. Why not run the order in the other direction? That might be what the original complaint really is about.

Comment 8

[[:Jorropo]]

There is no meaningful security difference between aes_128, aes_256 and chacha20_poly1305, they are all good enough.

Then they are ordered by compute overhead (from fastest to slowest).

Comment 9

[only1ryan]

If that's the case, why does Chromium use

chacha20_poly1305_sha256

as the preferred cipher suite? Should Firefox should do the same?

Comment 10

[[:Jorropo]]

I guess you might be running an ARM device, or some other CPU without AES acceleration hardware or implementation.
Hardware AES faster than Software ChaCha Poly faster than Software AES and various smart TLS implementations report different preferences or support based on available accelerated assembly implementations at the cost of increased fingerprintability.

Anyway this isn't what this issue is about, feel free to open a new one explaining why you think the order should be changed.

Comment 11

[Dennis Jackson]

We plan to remove these ciphersuite preferences for TLS1.3 and so will not be adding them for HTTP3. As other commenters have identified, there is no meaningful difference in security for these ciphersuites.