Consider disabling TLS ciphersuites containing SHA-1

added Icebox label

Also note: FF97+ Bugzilla 1745678 Remove TLS 1.0/1.1 override UX

added Backlog Sponsor 131 Task ~95597 labels and removed Icebox label

changed milestone to %Sponsor 131 - Phase 3 - Major ESR 102 Migration

marked this issue as related to #32796 (closed)

removed Backlog label

added Doing label

assigned to @richard

added Backlog label and removed Doing label

added Next label and removed Backlog label

If I'm understanding things correctly, we could disable the SHA-1 using ciphers via these prefs:

pref	value
security.ssl3.deprecated.rsa_des_ede3_sha	true
security.ssl3.dhe_rsa_aes_128_sha	false
security.ssl3.dhe_rsa_aes_256_sha	false
security.ssl3.ecdhe_ecdsa_aes_128_gcm_sha256	true
security.ssl3.ecdhe_ecdsa_aes_128_sha	true
security.ssl3.ecdhe_ecdsa_aes_256_gcm_sha384	true
security.ssl3.ecdhe_ecdsa_aes_256_sha	true
security.ssl3.ecdhe_ecdsa_chacha20_poly1305_sha256	true
security.ssl3.ecdhe_rsa_aes_128_gcm_sha256	true
security.ssl3.ecdhe_rsa_aes_128_sha	true
security.ssl3.ecdhe_rsa_aes_256_gcm_sha384	true
security.ssl3.ecdhe_rsa_aes_256_sha	true
security.ssl3.ecdhe_rsa_chacha20_poly1305_sha256	true
security.ssl3.rsa_aes_128_gcm_sha256	true
security.ssl3.rsa_aes_128_sha	true
security.ssl3.rsa_aes_256_gcm_sha384	true
security.ssl3.rsa_aes_256_sha	true

So if it ends in _sha we wnt to disable/set to false?

ping @ma1 @thorin

this may be a duplicate of #32796 (closed) - ~~but as I'm going through this, I see there is pretty much nothing in common with the lists. What is the purpose of this ticket?~~

that list above looks rather long and we do not want to be flipping 15 prefs - shit WILL break [and I am not a cipher expert]

from my comments (#32796 (comment 2817358))

https://browserleaks.com/ssl seems to be down or no longer maintained: but from memory they listed a bunch of ciphers as "non-modern" - i think it's these ones

   6 : 0.01% : TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA 
   4 : 0.00% : TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
   3 : 0.09% : TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
   5 : 0.52% : TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
  61 : 0.25% : TLS_RSA_WITH_AES_128_CBC_SHA
  63 : 0.27% : TLS_RSA_WITH_AES_256_CBC_SHA

   // user_pref("security.ssl3.ecdhe_ecdsa_aes_256_sha", false);
   // user_pref("security.ssl3.ecdhe_ecdsa_aes_128_sha", false);
   // user_pref("security.ssl3.ecdhe_rsa_aes_128_sha", false);
   // user_pref("security.ssl3.ecdhe_rsa_aes_256_sha", false);
   // user_pref("security.ssl3.rsa_aes_128_sha", false); // no PFS
   // user_pref("security.ssl3.rsa_aes_256_sha", false); // no PFS

So, yes, anything ending in CBC_SHA we can enforce as false. ~~Your list has NONE of these listed.~~ these six are in your list (damnit, the prefs don't contain cbc)

The other two ciphers that at least arkenfox has mentioned in the past as somewhat weak these two, because they have no perfect forward secrecy - these two ARE in your list

// no telemetry
   - :   n/a : TLS_RSA_WITH_AES_128_GCM_SHA256
   - :   n/a : TLS_RSA_WITH_AES_256_GCM_SHA384

   // user_pref("security.ssl3.rsa_aes_128_gcm_sha256", false); // no PFS
   // user_pref("security.ssl3.rsa_aes_256_gcm_sha384", false); // no PFS

So that's it. I agree we can likely disable SIX prefs based on telemetry and being really old, and maybe TWO more prefs (but we lack telemetry). All the rest sounds like you just want to break encryption (IANAExpert on ciphers but there will be a reason they are true by default)

edit: updated to correct that all eight are in richard's list

sorry if I misinterpreted what the list was for. If that is the complete list of all prefs, then yes, anything ending in _sha = eight prefs (two of which are default false) = which leaves the six "non-modern" ciphers all of which we have telemetry for and all of which are super low usage and we should be able to flip given telemetry

for the record and patch (but you should double check, these names/strings are somewhat convoluted/easy-to-mix-up)

/* bug 40183: disable remaining sha-1 ciphers */
pref("security.ssl3.ecdhe_ecdsa_aes_256_sha", false);
pref("security.ssl3.ecdhe_ecdsa_aes_128_sha", false);
pref("security.ssl3.ecdhe_rsa_aes_128_sha", false);
pref("security.ssl3.ecdhe_rsa_aes_256_sha", false);
pref("security.ssl3.rsa_aes_128_sha", false);
pref("security.ssl3.rsa_aes_256_sha", false);

now IDK if that covers it everywhere but it should at least fix urlbar requests

for the record and patch (but you should double check, these names/strings are somewhat convoluted/easy-to-mix-up)

lgtm, thanks.

@thorin thanks for following up!

added Doing label and removed Next label

mentioned in merge request !433 (merged)

mentioned in issue #32796 (closed)

marked this issue as related to tor-browser-build#40668 (closed)

closed

mentioned in issue #41468 (closed)

mentioned in merge request !503 (merged)

Current stable version of Tor Browser (12.5.2) still exhibits the following:

security.ssl3.deprecated.rsa_des_ede3_sha	true

So i think this is yet to be done? cc @richard

security.ssl3.deprecated.rsa_des_ede3_sha

That's not an issue, because we've been locking security.tls.version.enable-deprecated to false (which overrides the deprecated cyphersuite prefs) for ~10 years now.

removed Doing label

mentioned in issue mullvad-browser#361 (closed)

Consider disabling TLS ciphersuites containing SHA-1

Designs

Child items 0

Activity