ToDo: security.ssl3.*

[earthlng]

proposals

• A: remove 1214 period, I'm sorry but I trust the mozilla specialists more on this than @pyllyukko
  • Pants says: I am open to making all of 1214 commented out and adding more to the description, but will not remove.
  • 1214 needs renaming
  • earthling says: renamed it, but wontchange atm so we match @pyllyukko's user.js
• B: split 1210 into 1210 and 1210a or something like that.
  • Pants says: No problems with splitting it
  • earthling says: wontchange atm so we match @pyllyukko's user.js
• C: add the 2 static-rsa prefs, but definitely as inactive
  • Pants says: yes, what do we call it?
  • earthling says: pull request pending

original post

I looked at our current settings and I want to share some of my observations.

https://badssl.com/
https://www.howsmyssl.com/
https://wiki.mozilla.org/Security/Server_Side_TLS
https://www.eff.org/deeplinks/2015/10/how-to-protect-yourself-from-nsa-attacks-1024-bit-DH

https://dh2048.badssl.com/ => we break dh2048 due to user_pref("security.ssl3.dhe_rsa_aes_256_sha", false);
The eff article explicitly names that pref and recommends to disable it even though it talks about 1024-bit primes being presumably broken by the NSA, and that pref uses a 2048-bit prime.
There's also this sentence from the mozilla wiki for "Modern compatibility":

• DHE is removed entirely because it is slow in comparison with ECDHE, and all modern clients support elliptic curve key exchanges.

It doesn't say it's easy to break only that it's slow. Do we assume the NSA can also break DHE with a 2048-bit prime, or should we comment out that pref for less breakage (and recommend it only for the paranoid?) - because according to badssl.com dh2048 is still secure.
If we keep it, we may want to rename 1210 to 'disable DHE (Diffie-Hellman Key Exchange)' and remove the 1024 bit part.

'Modern compatibility' ciphers and the matching pref:

1. ECDHE-ECDSA-AES256-GCM-SHA384 => security.ssl3.ecdhe_ecdsa_aes_256_gcm_sha384
2. ECDHE-RSA-AES256-GCM-SHA384 => security.ssl3.ecdhe_rsa_aes_256_gcm_sha384
3. ECDHE-ECDSA-CHACHA20-POLY1305 => security.ssl3.ecdhe_ecdsa_chacha20_poly1305_sha256
4. ECDHE-RSA-CHACHA20-POLY1305 => security.ssl3.ecdhe_rsa_chacha20_poly1305_sha256
5. ECDHE-ECDSA-AES128-GCM-SHA256 => security.ssl3.ecdhe_ecdsa_aes_128_gcm_sha256
6. ECDHE-RSA-AES128-GCM-SHA256 => security.ssl3.ecdhe_rsa_aes_128_gcm_sha256
7. ECDHE-ECDSA-AES256-SHA384 => security.ssl3.ecdhe_ecdsa_aes_256_sha
8. ECDHE-RSA-AES256-SHA384 => security.ssl3.ecdhe_rsa_aes_256_sha
9. ECDHE-ECDSA-AES128-SHA256 => security.ssl3.ecdhe_ecdsa_aes_128_sha (disabled by 1214)
10. ECDHE-RSA-AES128-SHA256 => security.ssl3.ecdhe_rsa_aes_128_sha (disabled by 1214)

Interestingly Firefox sends them in a different order (see howsmyssl.com).
Instead of 1-8 its 5,6,3,4,1,2,7,8
When 9+10 are enabled the order is 5,6,3,4,1,2,7,9,8,10
(+ TLS_RSA_WITH_AES_128_CBC_SHA and TLS_RSA_WITH_AES_256_CBC_SHA at the end [11+12], for the 2 remaining ones that we still allow)

The Rationales explain some of it:
In Modern compatibility:
AES256-GCM is prioritized above its 128 bits variant, and ChaCha20 because we assume that most modern devices support AESNI instructions and thus benefit from fast and constant time AES.

While in Intermediate compatibility (default):
ChaCha20 is prefered as the fastest and safest in-software cipher, followed by AES128. Unlike the modern configuration, we do not assume clients support AESNI and thus do not prioritize AES256 above 128 and ChaCha20. There has been discussions on whether AES256 extra security was worth its computing cost in software (without AESNI), and the results are far from obvious. At the moment, AES128 is preferred, because it provides good security, is really fast, and seems to be more resistant to timing attacks.

Well, anyhow, there's nothing we can do about it anyway.

Apart from the 10 modern ciphers (2 of which we have disabled) we only support 2 older ones: security.ssl3.rsa_aes_128_sha and security.ssl3.rsa_aes_256_sha, which is why static-rsa (https://static-rsa.badssl.com/) still works, but it's listed with an ! and not a red warning sign.

The only other thing that I really don't like is that https://incomplete-chain.badssl.com/ still works.
But maybe this can be fixed if security.nocertdb is set to true; I haven't tested this because I really don't like the current implementation behind that pref.

IMO we should remove 1214, because the 128bit in AES is not the problem, 5+6 have them also.
And the 2 prefs in 1214 are part of the 10 modern ciphers.
Perhaps we were a bit overeager when we added 1214, without really understanding it. (?)

[earthlng]

What bugs me a bit is the "Restore default settings" button on those "Secure Connection Failed" pages.
I want to research what that button exactly does, and if there's a pref to hide/remove that button altogether.

[Atavic]

The strings I have set to false as unsecure:

security.ssl3.ecdh_ecdsa_rc4_128_sha
security.ssl3.ecdh_rsa_rc4_128_sha
security.ssl3.ecdhe_ecdsa_rc4_128_sha
security.ssl3.ecdhe_rsa_rc4_128_sha

Unsecure cryptographic keys aren't issued anymore. So there's a limbo where you stumble on expired CA Certs until they are renewed (and use different keys).

@Thorin-Oakenpants

why is 1214 titled disable 128 when the second has 256 in it's name?

But it has 128 on my screen.

I abstain from crosslinking the discussions on pyllyukko's user.js repo.

Note: adding this to your Chromium shortcut (as the “Arguments”) or command-line
--ssl-version-min=tls1 --cipher-suite-blacklist=0x0005,0x0004,0xc011,0xc007
will block RC4 usage.

[earthlng]

Thank you ;)
1210 - no, it's not included because we have it set to false. 1-10 are all the 'modern' ciphers only.
there's no more DHE, right? - if I understand you correctly: no, the 2 prefs in 1210 are the only old-school DHE, ie without 'elliptic curves'. But all the modern ones still use Diffie-Hellmann but with EC hence ECDHE.
I only brought it up because badssl.com considers the 2nd pref (2048bit) still secure and since you want to keep a balance and low-impact and everything. Disabling it increases the JS-less fingerprint on HTTPS sites blabla. I'll create a pull-request and we can go from there.

1214 - surely if they are 128bit - but that's the thing 5+6, ie the 1st and 2nd choice in FF atm, also use 128AES. They add in some gcm (hmmm sounds delicious, whatever that is) but they ARE the preferred/best ciphers atm. so it can't be that bad.
They are part of the 10 modern ciphers, I'd say we remove 1214.
I saw them originally in @pyllyukko user.js and we also added them because of that.

why is 1214 titled disable 128 when the second has 256 in it's name? it doesn't - you mixed that up buddy ;) or do you mean in the 1-10 list? AES128-SHA256

we support 2 older ciphers those 2 are not in the user.js. member when that security site broke for you and you had to figure out why? oh i member - those 2 ;) badssl has them as 'static-rsa'

'security.nocertdb' I think they are still trying to figure out how to achieve disabling only the certdb without also breaking every other db. Until we have a hardened, chances are they improve it at least slightly.

'restore default settings button' - i didn't dare click on it tbh. only want to see what exactly it does and if it can be blocked. purely out of interest. I can hide/disable the button with custom css on my own machine, but I wanna see if there's a pref for that. (fe. for company environment or so)

@Atavic those are all the RC4 ciphers and they were removed recently from FF anyway.

[earthlng]

Where would it come in the prefered order if enabled? - after 10 and before the 2 static-rsa ones

1. remove 1214 period, I'm sorry but I trust the mozilla specialists more on this than @pyllyukko
2. maybe split up 1210 into 1210 and 1210a or something like that. I can work on a pull-request for this.
3. perhaps add the 2 static-rsa prefs, but definitely as inactive (commented out), for people who wanna go full 'modern' and who can deal with breakage themselves. It broke that security site for you recently, so some sites still use that old stuff if they need/want to support older devices and OSes.

[Edit: removed OT]

[pyllyukko]

what does pyllyukko say (I am, loath to @ him, he has us on watch anyway)

Huh? There's so much going on here :)

Here's the reason to (slowly) move away from 128-bit key sizes:

• https://www.iad.gov/iad/library/ia-guidance/ia-solutions-for-classified/algorithm-guidance/cnsa-suite-and-quantum-computing-faq.cfm
• Grover's algorithm

[earthlng]

Thanks Pants, good stuff.
I read your last OT before you removed it - duly noted. Let's move on. (I'm OT8 now, btw ;)

@pyllyukko well, the 1st site gives me a SEC_ERROR_UNKNOWN_ISSUER and the 2nd one, oh boy the 2nd one.... well let's just say it's slightly over my head (lol, what an understatement).
What matters, if I understood anything it says, is the 2power64 vs 2power128 part.
I did some calculations and if the fastest super-computer would suddenly be able to do quantum-computing today it would still take ~92secs of full-capacity computing time to brute-force AES128.

Imagine what such a machine could do in those 92 seconds other than brute-forcing my encrypted data!
And with TLS1.3 and if session-tickets are disabled, afaik there's no longer a way to store everything and crack it later, meaning it's full forward-secrecy.

All that aside, that's not really the point here. Why do we disable 2 of the 10 modern ciphers because of a theoretical future possibility but at the same time allow 2 older ciphers for compatibility reasons, with one of them also using AES128, and both being arguably weaker than the 2 modern ones?

[earthlng]

Oh, and there's also a theory that says that AES128 is potentially more secure than AES256.
I mean, idk, it's all very theoretical at the moment anyway. Let's deal with the here and now.

[Atavic]

1214: it can be commented out or left as-is-but no removal IMHO.
A read here.

1209: uncomment the line
// user_pref("security.tls.version.max", 4); // allow up to and including TLS 1.3
Another read.

[earthlng]

1214: won't be removed completely. But whatever we end up doing with it, we should agree on something and then use it both here and @pyllyukko user.js. That way we will at least increase "our little group" slightly. (re: cipher fingerprint)

1209: is already set to 4 in https://dxr.mozilla.org/mozilla-central/source/security/manager/ssl/security-prefs.js#6 so I think this will be default in FF52, idk. It can break sites on servers that haven't updated their openssl or whatnot, hence I think we should wait for FF52, at least. Users can enable it already if they want.

[earthlng]

from Atavic's first link:

Now, I rather think that we should be moving TLS to use Quantum Resistant cryptography; but as of right now, TLS is rather far from that goal, and the symmetric key size is a minor issue;

therefore I'd advocate for 1214 to be commented out, because they are 2 of the 10 modern ciphers

[earthlng]

Unfortunately the security-prefs.js also still has the following prefs, so cipher FP will remain a slight problem for us, for now.

pref("security.ssl3.dhe_rsa_aes_128_sha", true);
pref("security.ssl3.dhe_rsa_aes_256_sha", true);
pref("security.ssl3.rsa_des_ede3_sha", true);

What if we regroup parts of that section, and add a note that changing the default values for them can be fingerprinted? for example:

12xx: disable insecure ciphers (Warning: changing the values from FF's defaults, can be used for Fingerprinting)
-> and then move all the relevant prefs into that sub-group, atm 1210, 1213, 1214, each as 12xx a, b, c.

[earthlng]

What bugs me a bit is the "Restore default settings" button on those "Secure Connection Failed" pages.
I want to research what that button exactly does

FYI: It restores/clears/resets all user-set prefs for security.tls.version.* and security.ssl3.*

https://dxr.mozilla.org/mozilla-central/source/browser/base/content/browser.js#2991
https://dxr.mozilla.org/mozilla-central/source/browser/base/content/browser.js#2910

[Atavic]

It does the same as reset on any about:config entry. You can right-click on an about:config entry and there's reset option in the GUI list.