Debian Testing I usually enforce AES256/Chacha20 for TLS 1.3, but ESNI isn't working then: mozregression --launch 2018-10-19 --pref network.trr.bootstrapAddress:"2400:cb00:2048:1::6810:7019" network.trr.mode:3 network.trr.wait-for-portal:false network.security.esni.enabled:true security.tls13.aes_128_gcm_sha256:false -a https://servo.org/cdn-cgi/trace -a https://www.cloudflare.com/ssl/encrypted-sni/ > fl=75f8 > h=servo.org > ip=2003:[censored] > ts=1539972964.672 > visit_scheme=https > uag=Mozilla/5.0 (X11; Linux x86_64; rv:64.0) Gecko/20100101 Firefox/64.0 > colo=HAM > spdy=h2 > http=h2 > loc=DE > tls=TLSv1.3 > sni=plaintext ESNI works if AES128 is allowed: mozregression --launch 2018-10-19 --pref network.trr.bootstrapAddress:"2400:cb00:2048:1::6810:7019" network.trr.mode:3 network.trr.wait-for-portal:false network.security.esni.enabled:true security.tls13.aes_128_gcm_sha256:true -a https://servo.org/cdn-cgi/trace -a https://www.cloudflare.com/ssl/encrypted-sni/ > fl=75f10 > h=servo.org > ip=2003:[censored] > ts=1539973025.414 > visit_scheme=https > uag=Mozilla/5.0 (X11; Linux x86_64; rv:64.0) Gecko/20100101 Firefox/64.0 > colo=HAM > spdy=h2 > http=h2 > loc=DE > tls=TLSv1.3 > sni=encrypted Is this a Cloudflare-side problem?

It's a problem with your configuration. Cloudflare only advertises TLS_AES_128_GCM_SHA256, so if you disable that cipher suite it's not going to work. In general, given that TLS_AES_128_GCM_SHA256 is the only MTI cipher suite in TLS 1.3, there's not a reasonable expectation that having only ChaCha enabled will work, so you're just seeing that here.

Cloudflare supports AES128/AES256/Chacha20 for TLS 1.3: https://www.hardenize.com/report/servo.org/1539979391#www_tls Server owners can't disable TLS 1.3 ciphersuites in Nginx, so everyone will have the good ciphersuites: https://trac.nginx.org/nginx/ticket/1529 security.tls13.aes_128_gcm_sha256;false disables this ciphersuite for TLS 1.3 itself. https://blog.cloudflare.com/content/images/2018/10/encrypted_sni_pcap.png So Cloudflare is offering a different set of ciphersuites for ESNI (=only AES128)? Then I would expect that a) Cloudflare supports the same set of ciphersuites for both TLS 1.3 itself and ESNI, or b) security.tls13.* doesn't affect ESNI. As the client selects the ciphersuite in TLS 1.3 one should be able to enforce 256 bit encryption at least where possible. Thank you.

(In reply to Jan Andre Ikenmeyer [:darkspirit] from comment #2) > Cloudflare supports AES128/AES256/Chacha20 for TLS 1.3: > https://www.hardenize.com/report/servo.org/1539979391#www_tls > > Server owners can't disable TLS 1.3 ciphersuites in Nginx, so everyone will > have the good ciphersuites: https://trac.nginx.org/nginx/ticket/1529 Plenty of people don't use nginx. > security.tls13.aes_128_gcm_sha256;false disables this ciphersuite for TLS > 1.3 itself. Yes, we use the same setting for ESNI. > So Cloudflare is offering a different set of ciphersuites for ESNI (=only > AES128)? > Then I would expect that > a) Cloudflare supports the same set of ciphersuites for both TLS 1.3 itself > and ESNI, or > b) security.tls13.* doesn't affect ESNI. There's nothing in the specification that requires either one of these to be true. > As the client selects the ciphersuite in TLS 1.3 perhaps you mean for ESNI? The client does not select the ciphersuite for TLS 1.3. > one should be able to > enforce 256 bit encryption at least where possible. It's not possible in this case because as a matter of policy Cloudflare has elected not to enable this ciphersuite. In any case, this isn't a defect in Firefox, so I'm marking it as WONTFIX.

Plenty of people use Cloudflare and they support the good stuff like Chacha. Both specifications allow us to have a configuration like comment 0. Users have the flexibility to enforce 256 bit encryption for TLS 1.3. https://tools.ietf.org/html/draft-rescorla-tls-esni-00#page-8 > The cipher suite used to encrypt the SNI. Firefox' ESNI implementation uses TLS 1.3 ciphersuite prefs to configure allowed ciphersuites for ESNI. They are a different thing. The one encrypts my TLS 1.3 session data, the other only the ESNI secret. Real-world implementations (like Cloudflare) apparently may only offer one ciphersuite for ESNI. Firefox' ESNI implementation does not account for it. > perhaps you mean for ESNI? The client does not select the ciphersuite for TLS 1.3. Offtopic: Sorry, I just had in mind that server owners can't enforce curve order with OpenSSL and that nginx server owners can't control TLS 1.3 ciphersuites - without manually compiling OpenSSL. > It's not possible in this case because as a matter of policy Cloudflare has elected not to enable this ciphersuite. > In any case, this isn't a defect in Firefox This is apparently wrong in content, so we have a misunderstanding. Resetting resolution, to ensure content-related triage. Actual : The ESNI implementation uses prefs of a different feature and fails therefore. Expected: It should have its own three ESNI ciphersuite prefs that are left enabled by default.

1. > Actual : The ESNI implementation uses prefs of a different feature and fails therefore. > Expected: It should have its own three ESNI ciphersuite prefs that are left enabled by default. If the spec was different and ESNI ciphersuites should have been used for TLS 1.3 itself, then the connection would have failed, but instead TLS 1.3 is negotiated with Chacha (just without ESNI). Therefore I assume that I'm not misinterpreting the spec and that we only had a misunderstanding. 2. Related problem: STR : Disable AES128 for ESNI. ESNI was found in DNS and the provider only offers AES128 for ESNI. Actual : The TLS 1.3 connection succeeded with Chacha, but without ESNI. Expected: Hardfail, as the provider offers SNI privacy only with a ciphersuite we don't offer.

It seems to me like you are making two points. 1. You would like separate cipher suite settings for TLS 1.3 and ESNI. This is a reasonable position, but I don't think it's the only one. Both of these ciphersuites apply to TLS, albeit to different parts of the protocol, and they come out of the same code point space, and it's not an unreasonable design decision to have them controlled by the same pref, so this is working as designed. It would also be reasonable to design things the way you propose, but we chose not to do that. Additionally, for features which you tweak via about:config versus having a real UI for them, we don't really guarantee that tweaking them leads to sane results (and again, I don't concede that these results are not sane). For these reasons, I don't think this is a valid defect report and I'm marking this WONTFIX. 2. When NSS (and hence Firefox) can't negotiate ESNI, either because the it doesn't recognize the ESNI version or because it can't negotiate cipher suites, it falls back to regular SNI, at which point you get regular TLS 1.3 cipher suite negotiation. You appear to think it should hard fail. This is also a reasonable position, and the spec isn't very clear on this point, but I think it would lead to a lot of negative consequences and make people very unwilling to roll out ESNI, because they would potentially be breaking their servers entirely if they had a disagreement about cipher suites. So I don't think it would be advisable to make that change at this point, especially because we're going to be in a period of version change so there will already be a lot of ESNI records we ignore. In any case, that would not be a bug in Firefox but rather NSS, so if you continue to feel differently, please file an NSS bug to that effect (though I expect we'll probably reach the same resolution there).