6 ms·

Mozilla Server Side TLS – Recommended Configurations

76 points by rhamzeh 7y ago

ufo 7y ago
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?
- dfc 7y ago
  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
  - unilynx 7y ago
    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.
- ChrisSD 7y ago
  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.
  - ChrisSD 7y ago
    The submission title has now been changed to better reflect the content so my comment no longer applies.
- wereHamster 7y ago
  Modern doesn't support IE11, this may be a big issue for some organizations. See also https://caniuse.com/#feat=tls1-3 https://caniuse.com/#feat=tls1-3
- floatingatoll 7y ago
  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.)
ChrisSD 7y ago
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.
- trulyrandom 7y ago
  > 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.
  - beefhash 7y ago
    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.
  - tomwas54 7y ago
    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.
throw0101a 7y ago
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.
- user5994461 7y ago
  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.
  - bostik 7y ago
    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.
lousken 7y ago
That's impossible to do, at least on MS IIS directly since SCHANNEL doesn't support TLS 1.3 yet
- zamadatix 7y ago
  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
  - jeltz 7y ago
    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.
concatime 7y ago
Can someone points me to the commit when OpenSSL changed from TLS13-AES-256-GCM-SHA384 to TLS_AES_256_GCM_SHA384?
- concatime 7y ago
  One of many: https://github.com/openssl/openssl/commit/9d2674c#diff-1bd3127dac4cad3b3268ca9b2e6ff5e4L706 https://github.com/openssl/openssl/commit/9d2674c#diff-1bd31...
- concatime 7y ago
  Also, idk why OpenSSL have used underscore this time when all the rest of ciphers use dash!? https://testssl.sh/openssl-iana.mapping.html https://testssl.sh/openssl-iana.mapping.html
  - MrRadar 7y ago
    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.
giaour 7y ago
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
- user5994461 7y ago
  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.
MrRadar 7y ago
Re-posting my comment from my submission of this, here's a summary of the major changes from the last update (which was published 2.5 years ago): - 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.
bdd 7y ago
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.
- marumari 7y ago
  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.

76 points by rhamzeh 7y ago

ufo 7y ago

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?

dfc 7y ago
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
- unilynx 7y ago
  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.
ChrisSD 7y ago
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.
- ChrisSD 7y ago
  The submission title has now been changed to better reflect the content so my comment no longer applies.
wereHamster 7y ago
Modern doesn't support IE11, this may be a big issue for some organizations. See also https://caniuse.com/#feat=tls1-3 https://caniuse.com/#feat=tls1-3
floatingatoll 7y ago
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.)

ChrisSD 7y ago

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.

trulyrandom 7y ago
> 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.
- beefhash 7y ago
  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.
- tomwas54 7y ago
  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.

throw0101a 7y ago

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.

user5994461 7y ago
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.
- bostik 7y ago
  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.

lousken 7y ago

That's impossible to do, at least on MS IIS directly since SCHANNEL doesn't support TLS 1.3 yet

zamadatix 7y ago
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
- jeltz 7y ago
  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.

concatime 7y ago

Can someone points me to the commit when OpenSSL changed from TLS13-AES-256-GCM-SHA384 to TLS_AES_256_GCM_SHA384?

concatime 7y ago
One of many: https://github.com/openssl/openssl/commit/9d2674c#diff-1bd3127dac4cad3b3268ca9b2e6ff5e4L706 https://github.com/openssl/openssl/commit/9d2674c#diff-1bd31...
concatime 7y ago
Also, idk why OpenSSL have used underscore this time when all the rest of ciphers use dash!? https://testssl.sh/openssl-iana.mapping.html https://testssl.sh/openssl-iana.mapping.html
- MrRadar 7y ago
  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.

giaour 7y ago

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

user5994461 7y ago
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.

MrRadar 7y ago

Re-posting my comment from my submission of this, here's a summary of the major changes from the last update (which was published 2.5 years ago): - 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.

bdd 7y ago

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.

marumari 7y ago
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.