ToDo: security.ssl3.* about user.js

[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]

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, 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]

[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]

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.