
Mozilla Server Side TLS – Recommended Configurations - rhamzeh
https://wiki.mozilla.org/Security/Server_Side_TLS#Recommended_configurations
======
MrRadar
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.

------
ufo
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?

~~~
ChrisSD
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
The submission title has now been changed to better reflect the content so my
comment no longer applies.

------
ChrisSD
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
> 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.

~~~
tomwas54
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.

------
bdd
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
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.

------
throw0101a
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
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
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.

~~~
user5994461
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.

~~~
bostik
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.

------
giaour
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
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.

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

~~~
concatime
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
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.

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

~~~
zamadatix
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
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.

