Mozilla Server Side TLS – Recommended Configurations
wiki.mozilla.org
wiki.mozilla.org
- TLS 1.3 has been recommended across the board.
- The "Modern" configuration is TLS 1.3-only.
- The "Intermediate" configuration is TLS 1.3 and 1.2-only.
- The "Intermediate" configuration now only uses AEAD ciphersuites with PFS. No more 3DES, CBC, SHA-1, or static RSA key exchange.
- ECDSA certificates (using NIST P-256) are now recommended for the "Intermediate" configuration (in addition to the "Modern" configuration).
- Servers now respect the client's cipher preferences with the "Modern" and "Intermediate" configurations as all enabled ciphers should provide sufficient security. This allows clients without AES hardware acceleration to prefer AES-128 or ChaCha20 over AES-256 and vice-versa.
- The "Old" configuration drops SSLv3 and some uncommon ciphers (CAMELLIA, SEED, DSS). This loses support for IE 6 on Windows XP, bumping the minimum up to IE 8.
- X25519 is now the recommended curve for key exchange (followed by NIST P-256 and P-384). NIST P-521 is no longer recommended as it doesn't provide any major security benefit over the other curves, has less widespread support, and is slower.
In practice, how much of a compatibility hit is there between the Intermediate and the Modern configurations?
If your API clients are diverse, turning off pre-TLS1.2 versions even now will probably break a lot of them.
See also https://caniuse.com/#feat=tls1-3
I just recently tried bumping it up to the next version but so many sites don't support v1.3 yet, including HN.
That's not surprising. Distributions like Debian and Ubuntu do not have a recent enough version of OpenSSL in their stable package repository yet.
Because of this my personal webserver, running nginx on Ubuntu 18.04, started offering TLS 1.3 without any manual action on my part, because the server is configured to auto-apply updates from these repositories.
That's why the line `TLS curves: X25519, prime256v1, secp384r1` should be `TLS curves: Curve25519, [...] `
I'd impose my pedantry on the Mozilla wiki but it's not accepting account registrations, I guess understandably.
Anyone who visits with a client that supports TLS 1.2 will just use that, while any client that can only deal with <1.2 will still be supported. There are various reasons why someone may not be able to use 1.2†, so what use is abandoning them?
† I'm personally still using NetNewsWire 3 because I like how it works compared to anything else out there that I've tried (since the last time I did a comparison), but it is compiled against OpenSSL 0.9.8, and so no TLS 1.2 for me.
There are a few vulnerabilities like CRIME or BEAST with variable impacts, some can be patched. It's very poorly explained so good luck understanding any of that.
There are a few old algorithms that can be decrypted with current computing resources, negating the point of encryption. You have to disable DES, RC4 and NULL.
I personally think the whole TLS 1.0 depreciation is a mess that's very representative of why cyber security is a mess and will never improve. A huge cargo cult telling to turn it off because it's broken, ignoring that it's breaking a lot of clients, and without a single explanation of what's the problems or how to mitigate them.
In my experience, much of the cargo-culting is driven by regulations. And a good part of that has been caused by the industries being regulated, as an unfortunate consequence.
Now... I think that warrants an explanation.
Regulations that make sense are often not descriptive - capturing the intent and scope of a rule often requires technical expertise. More than that, it's the type of expertise most organisations do not have. And instead of improving themselves, these companies, who may form the grand majority of the industry, petition the regulators to provide a safe checklist of technical mitigations that can be implemented to remain compliant.
You can probably see where this is going. (I am going to make a wild guess and say that you likely work in the banking industry.) Instead of providing these mitigation checklists as external annexes, they are instead incorporated directly into the regulations themselves.
Regulations always trail reality by a few years -- and in some cases, by decades.[0] The very same checklists that were originally meant to help the smaller players from caving under the regulatory burden are now a drag anchor on entire industries. Instead of doing the right thing and meeting the planned intent, companies are instead ticking nonsensical boxes that the regulators and their auditors demand.
Blindly.
Mindlessly.
Divorced from reality.
And worst of all, unable to improve. Because if you made an improvement that deviates from the historically old, untouched checklist, you would no longer be compliant.
0: Don't ask. I have given a couple of talks on the subject, but refuse to go on record, let alone state the details of my beliefs publicly.
Turning off TLS 1.0 in 2015 would have cut at least 30% of your user base (internet explorer) and was simply not an option for anybody. If there was an explanation of what is the issue, the impact and how to mitigate, this could have been evaluated and implemented (or not), but it's never been given.
We worked together. You should recognize me really ;)
Regulations are largely fine. You should known from doing the audits. They are usually worded to say that something should follow the generally accepted standards or good practices, without specifying what they are. Either way, it's always fairly easy to delay or argue that whatever you're doing is the right thing.
And I do agree with you, within reason: financial industry tech regulation is largely fine. ("Sane") The regulations tend to state the intent of a rule, and may even specify something that clearly is not fine.
More recently I have come across different sets of rules. While it is obvious that these particular regulations have been written with the best intentions in mind, they end up making things worse. Instead of specifying what the goal and the reason for any rule is, they state only The One True Way. Reason has to be inferred, because it is unstated.
Doesn't matter if the truth in The Way may have been induced by bad 'shrooms. Once written down, it's gospel.
Yup. Everyone should strive to use 1.2+. But some can't for whatever reason.
What's the harm in keep <1.2 around for the legacy clients (assuming no regulatory stuff) that can't / won't upgrade? Or do we want to turn off the proverbial Internet lights on anyone that doesn't keep up?
A week later we turned off 1.1, as the logs said that no 1.1 connection had good credentials. Nothing failed then, either.
My recommendation: turn off 1.0 and 1.1 at the server end, enable 1.3 when you have that capability.
The Wikimedia Foundation has a dashboard showing TLS statistics for their services[2]. As they run one of the most popular websites on the Internet I think this data can be considered to be representative of clients on the public web. That dashboard shows 99+% of connections use TLS 1.2 and only 0.5% of TLS 1.2 connections use non-AEAD ciphers. Now, for someone operating at the scale of the Wikimedia Foundation dropping TLS 1.0 and 1.1 is probably not a good idea right now, but for smaller sites (particularly sites that are non-commercial/non-monetary in nature) it should be just fine.
Servers have already been dropping TLS 1.0 support for years now. According to SSL Pulse[3] only 67% of servers support TLS 1.0 compared to 95% support for TLS 1.2. At its peak, TLS 1.0 support was at 99%. If you want to continue using ancient software with the modern Internet you should probably use a modern proxy server anyways just due to the sheer number of security fixes your old software's TLS implementation will be missing.
[1] https://blog.qualys.com/technology/2019/04/22/zombie-poodle-...
[2] https://grafana.wikimedia.org/d/000000458/tls-ciphersuite-ex...
Great. And that's a good reason to use a client that support 1.2. But what's so bad about keeping 1.0 and 1.1 around?
If I'm running a client that only supports <1.2, how does mandating only 1.2+ help me? If a client supports 1.2+, then it will use it anyway.
I understand supporting 1.2+, and everyone should have their server offer it. But what's the advantage of dropping 1.0 and 1.1? I'm just leaving those folks are may be stuck with older clients twisting in the wind with no service whatsoever.
Java 7 is end of life in 2020. It only support TLS 1.2 if you have a recent JVM release. Don't expect people on java 7 to ever update their JVM though.
EDIT: NVM, I forgot that ssl_min_protocol_version was added in PostgreSQL 12 which is not released yet.