Mozilla Server Side TLS – Recommended Configurations(wiki.mozilla.org)
wiki.mozilla.org
Mozilla Server Side TLS – Recommended Configurations
https://wiki.mozilla.org/Security/Server_Side_TLS#Recommended_configurations
34 comments
Despite the title of this submission, the wiki page actually is recommending the "Intermediate" configuration by default, which also includes TLS 1.2
In practice, how much of a compatibility hit is there between the Intermediate and the Modern configurations?
In practice, how much of a compatibility hit is there between the Intermediate and the Modern configurations?
Indeed the title is wrong though I can see how someone could get confused. These are all "recommend" configurations depending on how bleeding edge (or not) you want to be. But intermediate is the recommended of the recommended configurations.
The submission title has now been changed to better reflect the content so my comment no longer applies.
According to caniuse, TLS1.3 is supported by 75% of browsers in use:
https://caniuse.com/#feat=tls1-3
https://caniuse.com/#feat=tls1-3
And that's just browsers... if you provide an API you may be dealing with external users who are a lot further behind than the browsers.
If your API clients are diverse, turning off pre-TLS1.2 versions even now will probably break a lot of them.
If your API clients are diverse, turning off pre-TLS1.2 versions even now will probably break a lot of them.
Modern doesn't support IE11, this may be a big issue for some organizations.
See also https://caniuse.com/#feat=tls1-3
See also https://caniuse.com/#feat=tls1-3
Glancing at the table of clients, I would personally guess that Modern requires TLS 1.3, OpenSSL 1.1.1, and Java 11, which is a high bar to meet for what’s likely deployed and in use in long-term support production systems. (I don’t know the actual worldwide client data statistics, so this is just a guess.)
On the client side I've been living with my browser set to accepting a minimum of v1.2 without issue for a long while, aside from the odd random page found in search but that's no loss.
I just recently tried bumping it up to the next version but so many sites don't support v1.3 yet, including HN.
I just recently tried bumping it up to the next version but so many sites don't support v1.3 yet, including HN.
> 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.
That's not surprising. Distributions like Debian and Ubuntu do not have a recent enough version of OpenSSL in their stable package repository yet.
And even then, it can still take months to years until those distributions are upgraded to the latest stable version. They've got a few more years of support after the next stable all.
Ubuntu 18.04, the newest LTS, recently backported OpenSSL 1.1.1 to its stable package repository.
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.
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.
A small nit about Curve25519 vs X25519. The name of the curve is Curve25519, while the name of Diffie Hellman function utilizing the curve is X25519. Same with Curve448 and X448.
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.
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.
X25519 is the mechanism for using Curve25519. Software that uses OpenSSL all uses “X25519” and so it would be needlessly confusing to use other verbiage despite being more technically correct.
What is the advantage of dropping support for TLS 1.0 and 1.1 (especially if the server has TLS_FALLBACK_SCSV)?
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.
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.
In practice, I see a bunch of non-browser clients that are capable of doing 1.2 but will only do 1.0 as long as it is being offered. After a multiyear transition, nothing failed the day after we turned off 1.0 on the server end.
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.
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.
It's prohibited from usage by various regulations, like PCI-DSS, so you simple have to turn it off.
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.
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.
Funny that you should mention cargo-culting and regulations.
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.
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.
Maybe I should rephrase. I don't mean cargo culting like that. My grip is with (most) security people whose only handling of vulnerabilities is to spread fear mongering and stupid action ASAP, without any explanation of the issue or solution. Long story short, cyber security is a circus.
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.
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.
Thank you for confirming, I was quite certain it was you.
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.
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.
> 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.
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?
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?
The biggest benefit to dropping TLS 1.0 and 1.1 is that modern AEAD ciphers are only supported by TLS 1.2 and above. In TLS 1.0 your only options are the hilariously-broken RC4 or block ciphers in CBC mode, which is a perennial source of padding oracles (several new ones were just discovered earlier this year[1]). By setting TLS 1.2 as your minimum you can also require the use of AEAD ciphers as Mozilla's new guidelines recommend. (In theory you could support different ciphers with different TLS versions but I don't know how many people did that in practice.)
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...
[3] https://www.ssllabs.com/ssl-pulse/
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...
[3] https://www.ssllabs.com/ssl-pulse/
> The biggest benefit to dropping TLS 1.0 and 1.1 is that modern AEAD ciphers are only supported by TLS 1.2 and above.
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.
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.
As I said the alternatives to AEADs have well-known security issues that AEADs are immune to by design. Keeping 1.0 and 1.1 around requires keeping CBC ciphers around and all the workarounds and careful design required to avoid exposing padding oracles using them, and requires keeping your software patched as new vulnerabilities from those oracles are discovered. Eliminating TLS 1.0 and 1.1 will meaningfully improve the overall security of the TLS ecosystem. Also, you didn't address my point about using a proxy server which should let you keep using your ancient software. (Also also, it looks like that's Mac software from 2007, will it continue working after Apple drops 32-bit support?)
In my case, the problem is not browsers but vendor-provided enterprise tools. When HTTP became the “new tcp”, all sorts of things started using it behind the scenes. Eventually someone added support for ssl/tls, but now we have to wait for $vendor to support any protocol upgrade.
Given the ubiquity of Java 8 in enterprise IT, I think we’ll all be stuck supporting TLS1.2 for at least another 5 years
Java 8 is end of life in 2023. The OpenJDK one maintained by RedHat that's the de facto standard on all Linux.
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.
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.
Can someone points me to the commit when OpenSSL changed from TLS13-AES-256-GCM-SHA384 to TLS_AES_256_GCM_SHA384?
Also, idk why OpenSSL have used underscore this time when all the rest of ciphers use dash!?
https://testssl.sh/openssl-iana.mapping.html
The "official" names of the ciphersuites have always been in the underscore format, the dash format was something OpenSSL invented. I guess with TLS 1.3 changing all the cipher names anyways they decided to just use the standard names to avoid the confusion that comes from their own separate naming scheme.
That's impossible to do, at least on MS IIS directly since SCHANNEL doesn't support TLS 1.3 yet
The generator doesn't support IIS anyways but there are some in it's list that don't support the Modern configuration (gives a comment saying it's unsupported if you try): PostgreSQL, Oracle HTTP Server, and awselb
I wonder what feature is missing from PostgreSQL. It supports TLSv1.3 and supports letting the client pick cipher.
EDIT: NVM, I forgot that ssl_min_protocol_version was added in PostgreSQL 12 which is not released yet.
EDIT: NVM, I forgot that ssl_min_protocol_version was added in PostgreSQL 12 which is not released yet.
- 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.