It is time to add support for TLS 1.3 #217

ekr · 2018-06-19T21:56:14Z

TLS 1.3 is now in release in both Chrome and Firefox and supported by Google and Cloudflare.

tomato42 · 2018-06-20T13:20:10Z

the draft is also in AUTH48 state in IETF now, so we can expect it being published as a real RFC Soon™

jrchamp · 2018-06-20T18:27:32Z

I've been reloading the AUTH48 page each day since it went up. A big thank you to all the people who have brought TLS 1.3 to this point.

ekr · 2018-06-20T20:33:35Z

Probably not necessary to reload every day. We're at least a few weeks out. I just got it loaded into Github for first pass yesterday

…

On Wed, Jun 20, 2018 at 11:27 AM, Jonathan Champ ***@***.***> wrote: I've been reloading the AUTH48 page each day since it went up. A big thank you to all the people who have brought TLS 1.3 to this point. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#217 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABD1oYMXWYS8Phod-c5IiaBwZBhsTsIOks5t-pQYgaJpZM4UuTO_> .

martinthomson · 2018-08-09T04:30:29Z

This week folks.

hamjin · 2018-08-19T15:31:12Z

Now TLS1.3 is a RFC(RFC8446),so it is the time to use it!

Mattia98 · 2018-09-05T15:13:26Z

Any news about implementing this?

captn3m0 · 2018-09-05T15:20:38Z

Some WIP at #183 (Discussion at #178)

jvehent · 2018-09-06T12:35:51Z

it'll happen, just need to find the time

virusdefender · 2018-09-11T23:49:30Z

OpenSSL 1.1.1 released, it's time to use TLSv1.3

Sp1l · 2018-09-12T16:17:57Z

None of the browsers currently do TLSv1.3 RFC8446, they only do draft23/28. Only beta and/or nightly has support for the final TLSv1.3.
Sure, this should be added but there's still time (till next Chrome and Firefox releases).
I've seen people running nginx with TLSv1.3, but is that in the releases yet?
As for Apache, support might land in the next point release, a branch is already being tested.

tomato42 · 2018-09-12T17:11:15Z

openssl on Fedora rawhide-testing has RFC8446 final, and if the NSS with TLS 1.3 (3.39.0) isn't yet there, it will be there in the next few days (and automatically picked up by the distribution provided Firefox)

lukastribus · 2018-09-12T17:47:16Z

TLSv1.3 doesn't require any particular configuration, as all of the ciphers are secure, and by default OpenSSL only enables GCM and Chacha20/Polcy1305 for TLSv1.3, without enabling CCM. Also, the applications need to implement a different API to limit TLSv1.3 ciphers, so existing configuration directives won't allow limiting it.

I don't see how it makes any sense trying to advocate for a configuration that application are not ready to set, for something where openssl is secure by default. Other than turning TLSv1.3 on, what is it that you guys are suggesting exactly?

floatingatoll · 2018-09-12T17:53:04Z

"Other than turning TLSv1.3 on" Turning TLSv1.3 on _correctly_ is neither easy nor simple when taking into account _all_ software that the Server Side TLS configuration tool supports, especially if one wishes to maintain compatibility with older clients. Yes, individually, any of us could enable it on a single specific software platform of our preference, but doing so at scale requires meticulous care and attention to horrendously difficult things like "gnutls cipherstrings". So, the meticulous work around enabling TLSv1.3 correctly and without unwanted or undiscovered side effects _can_ be done, and as Julien (owner) indicated above, it will be done. It's just going to take time.

…

On Wed, Sep 12, 2018 at 10:47 AM Lukas Tribus ***@***.***> wrote: TLSv1.3 doesn't require any particular configuration, as all of the ciphers are secure, and by default OpenSSL only enables GCM and Chacha20/Polcy1305 for TLSv1.3, without enabling CCM. Also, the applications need to implement a different API to limit TLSv1.3 ciphers, so existing configuration directives won't allow limiting it. I don't see how it makes any sense trying to advocate for a configuration that application are not ready to set, for something where openssl is secure by default. Other than turning TLSv1.3 on, what is it that you guys are suggesting *exactly*? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#217 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAFqDLUj-5QLfZhjcKp7z7NT9GxZAteeks5uaUilgaJpZM4UuTO_> .

tomato42 · 2018-09-12T20:19:31Z

as all of the ciphers are secure

AES-CCM8 are not considered secure enough for general use, you shouldn't use them and they are not enabled by default by OpenSSL (exactly for that reason)

verifying that this is really the case is exactly why tools like cipherscan are necessary

Also, the applications need to implement a different API to limit TLSv1.3 ciphers, so existing configuration directives won't allow limiting it.

not true, the application needs to implement only one API that was part of OpenSSL since 1.0.2, the SSL_CONF_cmd

then there is the Crypto Policies which can change library defaults to enable different openssl settings outside of openssl (and really, most distributions tweak default openssl set of ciphers)

where openssl is secure by default

openssl is not the only implementation of TLS 1.3, there are many of them

Other than turning TLSv1.3 on, what is it that you guys are suggesting exactly?

supported groups, supported signature algorithms, acceptable groups vs ones that the server is willing to do HRR for, tolerance of 0-RTT handshakes, proper handling of timing differences for 0-RTT handshakes, session ticket lifetimes, just few items from the top of my head

lukastribus · 2018-09-12T21:30:20Z

not true, the application needs to implement only one API that was part of OpenSSL since 1.0.2, the SSL_CONF_cmd

Your wrong here, the application needs to add an additional config knob for TLSv1.3 ciphers, because that's the only way to configure TLSv1.3 ciphers in openssl; via additional API calls unnecessary for <= TLSv1.2.

SSL_CONF_cmd is in 1.0.2, but the TLSv1.3 specific parts (ciphersuites) have only been added in 1.1.1. SSL_CONF_cmd is a convenience feature, not required at all, not for any TLS release and a lot of applications just don't use it (such as apache, nginx and haproxy). So whether the application uses SSL_CONF_cmd or SSL_CTX_set_ciphersuites is besides the point; both are API changes and require new external knobs.

Apache 2.5 calls SSL_CTX_set_cipher_list() to set <= TLSv1.2 ciphers and SSL_CTX_set_ciphersuites() for TLSv1.3 ciphers, just as per OpenSSL documentation.

Now, for Apache 2.5 you can find out today what the TLSv1.3 ciphersuite configuration knob looks like. I assume you cannot predict how other projects like nginx, haproxy or lighttpd will make their knobs look like.

OpenSSL 1.1.1 stable was released less than 48 hours ago and it will be some time before the new API and the required knobs are implemented and released in the applications.

then there is the Crypto Policies which can change library defaults to enable different openssl settings outside of openssl (and really, most distributions tweak default openssl set of ciphers)

Sounds like a good thing to me.

openssl is not the only implementation of TLS 1.3, there are many of them

Relevant for the discussion regarding the Mozilla server side TLS configuration guidelines are only 2 though: openssl and gnutls. And actually, for the config generator, it's really only about openssl.

I'm all for documenting BCP for TLSv1.3. I am saying though the defaults are supposed to be secure and that today the applications lack the configuration knobs.

tomato42 · 2018-09-12T23:47:40Z

SSL_CONF_cmd is in 1.0.2, but the TLSv1.3 specific parts (ciphersuites) have only been added in 1.1.1.

no, both the setting name and the value should be a pass-through for the application, exactly as apache is doing

OpenSSL 1.1.1 stable was released less than 48 hours ago and it will be some time before the new API and the required knobs are implemented and released in the applications.

the applications were being ported to OpenSSL 1.1.1 for many months now, apache master branch was ported and explicitly set to support TLS 1.3 at least 2 months ago, python and perl a good month ago, curl and wget at least few months ago (and might have been ported even a year ago, it's just that I haven't been testing their TLS 1.3 support earlier)

Sounds like a good thing to me.

...until somebody switches the system to LEGACY mode and you haven't noticed because you're not testing for it and it was "just for a minute, to check if it fixes the interoperability issue" and it was left like that

Relevant for the discussion regarding the Mozilla server side TLS configuration guidelines are only 2 though: openssl and gnutls.

no, they are not. The guidelines are implementation agnostic. It's just that they have names of ciphersuites from OpenSSL and GnuTLS to make it easier to understand which ciphers they are talking about.

I am saying though the defaults are supposed to be secure and that today the applications lack the configuration knobs.

and I'm saying that you won't know if they are secure until you test them and the knobs are with us for 3 years for OpenSSL and "forever" (like 10 years) for NSS or GnuTLS

yes, it is much harder to misconfigure TLS 1.3 implementations, but it's not impossible

lukastribus · 2018-09-13T09:56:49Z

SSL_CONF_cmd is in 1.0.2, but the TLSv1.3 specific parts (ciphersuites) have only been added in 1.1.1.

no, both the setting name and the value should be a pass-through for the application, exactly as apache is doing

Agreed, Apache is an exception here though. Rarely do TLS server applications implement SSL_CONF. Not lighttpd, not nginx, not haproxy. Nor did Mozilla ever suggested the use of the SSLOpenSSLConfCmd directive before. It's certainly a good idea, I'm saying it's a new idea.

the applications were being ported to OpenSSL 1.1.1 for many months now, apache master branch was ported and explicitly set to support TLS 1.3 at least 2 months ago, python and perl a good month ago, curl and wget at least few months ago (and might have been ported even a year ago, it's just that I haven't been testing their TLS 1.3 support earlier)

My point exactly: until recently and except for SSL_CONF, the API was not stable, so that is max a few months that application developers had (without guarantee that the API won't change, as happened during the development of openssl 1.1.1). Neither SSL_CONF nor SSL_CTX_set_ciphersuites() is in any of the non-Apache projects supported by the Mozilla SSL Configuration Generator: nginx, haproxy, lighttpd, that is why today, you cannot specify the TLSv1.3 ciphersuites in those projects, not even by using development branches, although you can use TLSv1.3 with the ciphersuites openssl defaults to.

That is why I'm saying applications still have to adapt.

...until somebody switches the system to LEGACY mode and you haven't noticed because you're not testing for it and it was "just for a minute, to check if it fixes the interoperability issue" and it was left like that
[...]
yes, it is much harder to misconfigure TLS 1.3 implementations, but it's not impossible

Sure, OS will always impact the TLS library, due to bugs, deliberate tampering or admin mistakes, whatever it is. I also agree that strict configuration via the application is a good idea, otherwise I wouldn't be here discussing this project.

no, they are not. The guidelines are implementation agnostic. It's just that they have names of ciphersuites from OpenSSL and GnuTLS to make it easier to understand which ciphers they are talking about.

Well, the config generator only supports OpenSSL, and the Wiki page has no configuration to copy&paste, other than OpenSSL (not even GnuTLS). There is the translation table with IANA/OpenSSL/NSS/GnuTLS ciphers, but that doesn't really lend itself to configure a GnuTLS based application.

So while this project may supposed to be implementation agnostic, it also makes it extremely complicated to configure anything other than openssl (as in, you'd have to find the equivalents to each of the Mozilla recommended openssl ciphers and other config knobs manually).

obendev · 2018-09-23T11:13:41Z

https://www.openssl.org/blog/blog/2018/09/11/release111/

Since 1.1.1 is our new LTS release we are strongly advising all users to upgrade as soon as possible.

Edit: Still no enhancement label?

So GnuTLS now also supports TLS 1.3, recommends it and Cloudflare just updated their servers, including 1.1.1.1 DNS with TLS 1.3 support

TLS 1.3 is now also supported in apache2 version 2.4.36 with openssl 1.1.1
https://github.com/apache/httpd/blob/2.4.36/CHANGES

Chrome 70 also supports the final version of TLS 1.3 now... ~~And the next days Firefox will get the update as well.~~

Firefox 63 is released, supporting TLSv1.3 just fine.

obendev · 2018-10-13T17:09:38Z

Any updates on this?

Sp1l · 2018-10-25T11:42:37Z

And the next days Firefox will get the update as well.

Firefox 63 is released, supporting TLSv1.3 just fine.

Sp1l · 2018-10-25T11:45:34Z

So this week TLSv1.3 final RFC 8446 got a real boost:

Chrome 70 release
Firefox 63 release
Apache 2.4.37 release

Anything I can do to help updating the configurator? For now, the default Apache 2.4 config is OK (secure) for TLSv1.3.

jvehent · 2018-10-25T11:46:11Z

Because we haven't had time to work on it, but if someone is up to writing a patch to the configurator, I'll happily review and merge it.

obendev · 2018-10-25T11:51:15Z

What has to be done? Is there a todo or something similar?

Sp1l · 2018-10-25T12:46:59Z

For what it's worth...
The Apache configurations generated will enable TLSv1.3 if Apache is 2.4.37+ and OpenSSL 1.1.1+ is installed. Following ciphers enabled by default:

TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_GCM_SHA256

obendev · 2018-10-25T12:52:03Z

@Sp1l
Apache 2.4.36*+

https://github.com/apache/httpd/blob/2.4.36/CHANGES

2.4.37 only included a fix for HTTP/2

lukastribus · 2018-10-25T13:08:28Z

Because we haven't had time to work on it, but if someone is up to writing a patch to the configurator, I'll happily review and merge it.

Well there is no basic template in the Wiki yet, it doesn't even mention TLSv1.3 at all, adding to that there does not seem to be a consensus of what is needed exactly, if I quote tomato:

supported groups, supported signature algorithms, acceptable groups vs ones that the server is willing to do HRR for, tolerance of 0-RTT handshakes, proper handling of timing differences for 0-RTT handshakes, session ticket lifetimes, just few items from the top of my head

So I think before posting patches we'd actually need to conclude what is needed. Just ciphersuites for now (I'd perfectly agree with that)?

obendev · 2018-10-25T13:17:11Z

Well @oerdnj hasn't yet updated the apache package to 2.4.36(+) and I think this is the target group we have here, so there still is a bit time.
But certbot is waiting for you 😆 certbot/certbot#6367

oerdnj · 2018-10-25T13:41:09Z

It's on my TODO list for next two weeks... :)

obendev · 2018-10-25T13:42:17Z

Give this man a 🍪

opsarno · 2018-10-31T08:11:49Z


    ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;
    ssl_ciphers 'ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS';

YEAH! I think so~

xnoreq · 2018-12-09T13:38:07Z

@oerdnj Oct 25 + 2 weeks + 1 extra month = today.

obendev · 2018-12-09T14:57:09Z

He already added openssl 1.1.1 in his latest apache2 repo. Just mozilla didnt update their conig. You can change the config yourself though, if you are using ondrejs ppa

dangoncalves · 2018-12-09T15:14:08Z

@xnoreq : we are all waiting your contribution

opsarno · 2019-01-08T07:37:40Z

ssl_protocols TLSv1.3;# Requires nginx >= 1.13.0 else use TLSv1.2
ssl_ciphers ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384;

See: https://cipherli.st/

@valentinxxx
if i wanna backward compatibility with old client requests， should i open tlsv1/tlsv1.1 ssl_protocols ?

opsarno · 2019-01-11T09:37:38Z

MY STRONG CIPHER CONFIG

TLSv1.3 ciphers

Delete WEAK cipher DHE-RSA-AES256-GCM-SHA384

ssl_ciphers 'ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384;'

TLSv1.2,TLSv1.3 ciphers

ssl_ciphers 'ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256';

TLSv1.1,TLSv1.2,TLSv1.3 ciphers

ssl_ciphers 'ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA';

Hope to have reference value to everybody.

tomato42 · 2019-01-11T11:34:53Z

neither of those are TLSv1.3 ciphers

obendev · 2019-01-11T11:43:17Z

TLS 1.3 ciphers would be for example:

TLS_AES_256_GCM_SHA384 (0x1302)		ECDH x25519 (eq. 3072 bits RSA)   FS | 256
TLS_CHACHA20_POLY1305_SHA256 (0x1303)	ECDH x25519 (eq. 3072 bits RSA)   FS | 256
TLS_AES_128_GCM_SHA256 (0x1301)		ECDH x25519 (eq. 3072 bits RSA)   FS | 128

Just set SSLCipherSuite to HIGH and you are good to go.
You can disable RSA if you want to.
Some options can be found here: https://httpd.apache.org/docs/2.4/ssl/ssl_howto.html

A good ssllabs report on which you can orientate: https://www.ssllabs.com/ssltest/analyze.html?d=legilimens.de&s=2a01%3A4f8%3A1c1c%3A305f%3A0%3A0%3A0%3A1

tomato42 · 2019-01-11T11:46:19Z

Just set SSLCipherSuite to HIGH and you are good to go.

no, that enables ADH and AECDH - anonymous ciphersuites that are vulnerable to trivial man in the middle

obendev · 2019-01-11T11:52:04Z

Hey tomato42.
I only use TLS 1.2 and TLS 1.3 since chrome will deprecate any other protocol (except QUIC) in the next version (72) and I guess that other big browsers like Firefox and Safari will also do this in near future.
Ciphers like ADH and AECDH won't be included in HIGH with TLS 1.2 or 1.3.
I use these settings on https://www.ssllabs.com/ssltest/analyze.html?d=legilimens.de&s=2a01%3A4f8%3A1c1c%3A305f%3A0%3A0%3A0%3A1 and it works just fine

Well at least if you use apache 2.4.37 (or higher) but TLS 1.3 is only supported from 2.4.36 on.. so yeah 😇

I will post my complete config later today in a new comment.

tomato42 · 2019-01-11T13:54:54Z

yes, certain versions of Apache do unconditionally append !aNULL, but that means it's not a generic solution

obendev · 2019-01-11T17:22:53Z

My config

SSLProtocol             +TLSv1.2 +TLSv1.3
SSLCipherSuite          HIGH:!RSA
SSLHonorCipherOrder     on
SSLCompression          off
SSLSessionTickets       off

Running on apache 2.4.37 and openssl 1.1.1a

astrava · 2019-03-07T19:45:09Z


    ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;
    ssl_ciphers 'ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS';

YEAH! I think so~

!DSS
I wonder why we are not using DSS?

I found that below ciphersuite considered as old backward compatibility.
TLS_DHE_DSS_WITH_AES_256_GCM_SHA384
TLS_DHE_DSS_WITH_AES_128_GCM_SHA256

This is the old ciphersuite that works with all clients back to Windows XP/IE6.
It should be used as a last resort only.

tomato42 · 2019-03-07T19:49:20Z

@astrava that's off-topic for this thread: DSS signatures are not supported in TLS 1.3

obendev · 2019-05-03T09:42:25Z

Note: The ciphers I display here are safe today (2019-05-03). They might be unsafe in the future.

When using TLS 1.3 ciphers in openssl | in openssl with apache2 some things change as it was usual before with TLS 1.2.

Display ciphers (Change -tls1_2 accordingly)
openssl ciphers -s -tls1_2 ALL

Input a TLS 1.2 cipher (IANA TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 for example)
openssl ciphers -s -tls1_2 ECDHE-RSA-AES256-GCM-SHA384

For TLS 1.3 the -ciphersuites parameter comes to work.
Input a TLS 1.3 cipher (IANA TLS_AES_256_GCM_SHA384 for example)
openssl ciphers -s -tls1_3 -ciphersuites TLS_AES_256_GCM_SHA384

In your apache configuration you have to add TLSv1.3 before your ciphers.
So it would look like this with a TLS 1.2 and a TLS 1.3 cipher:

SSLCipherSuite          ECDHE-RSA-AES256-GCM-SHA384
SSLCipherSuite          TLSv1.3 TLS_AES_256_GCM_SHA384

Secure TLS 1.3 ciphers (openssl names)

TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_GCM_SHA256
TLS_AES_128_CCM_8_SHA256
TLS_AES_128_CCM_SHA256

Secure TLS 1.2 ciphers (openssl names)

ECDHE-RSA-AES256-GCM-SHA384
DHE-RSA-AES256-GCM-SHA384
ECDHE-RSA-CHACHA20-POLY1305
DHE-RSA-CHACHA20-POLY1305
DHE-RSA-AES256-CCM8
DHE-RSA-AES256-CCM
ECDHE-ARIA256-GCM-SHA384
DHE-RSA-ARIA256-GCM-SHA384
ECDHE-RSA-AES128-GCM-SHA256
DHE-RSA-AES128-GCM-SHA256
DHE-RSA-AES128-CCM8
DHE-RSA-AES128-CCM
ECDHE-ARIA128-GCM-SHA256
DHE-RSA-ARIA128-GCM-SHA256

For compatibility reasons you should add:

ECDHE-RSA-AES256-SHA384
ECDHE-RSA-AES256-SHA

(Weak encryption is better than no encryption)

There is also a ECDHE-ECDSA compatibility variant, but since certbot doesn't support this from stock I will skip this.

OpenSSL 1.1.1b

martinthomson · 2019-05-03T11:13:15Z

Please don't recommend use of ciphersuites with a 64-bit authentication tag (i.e., CCM8). Those are for specialized applications, not general use.

april · 2019-05-20T18:47:23Z

How's it coming on merging this? I would love to be recommending CHACHA20-POLY1305 and TLS 1.3 when we release the new configuration generator:

https://mozilla.github.io/ssl-config-generator/

The current recommendations are getting pretty dated at this point.

jvehent · 2019-05-20T18:55:48Z

How's it coming on merging this?

All it's waiting for is someone who can cleanup the existing PRs and publish a new revision of the guidelines.

april · 2019-05-20T19:19:35Z

What have we decided upon for each of the three configurations? I'm more than willing to update the JSON files and the wiki.

0xb4lint mentioned this issue Dec 2, 2018

TLSv1 TLSv1.1 Deprecated digitalocean/nginxconfig.io#42

Closed

0xb4lint mentioned this issue Feb 17, 2019

Cheat sheet update/refactor proposal: TLS_Cipher_String_Cheat_Sheet - TLSv1.3 OWASP/CheatSheetSeries#14

Closed

gene1wood added the wiki guidelines Issue related to Mozilla's Server Side TLS Guidelines label Apr 10, 2019

april mentioned this issue Jun 25, 2019

Server Side TLS 5.0 #255

Merged

april closed this as completed in #255 Jun 28, 2019

It is time to add support for TLS 1.3 #217

It is time to add support for TLS 1.3 #217

Comments

ekr commented Jun 19, 2018

tomato42 commented Jun 20, 2018

jrchamp commented Jun 20, 2018

ekr commented Jun 20, 2018 via email

martinthomson commented Aug 9, 2018

hamjin commented Aug 19, 2018

Mattia98 commented Sep 5, 2018

captn3m0 commented Sep 5, 2018

jvehent commented Sep 6, 2018

virusdefender commented Sep 11, 2018

Sp1l commented Sep 12, 2018

tomato42 commented Sep 12, 2018

lukastribus commented Sep 12, 2018

floatingatoll commented Sep 12, 2018 via email

tomato42 commented Sep 12, 2018

lukastribus commented Sep 12, 2018 • edited Loading

tomato42 commented Sep 12, 2018

lukastribus commented Sep 13, 2018

obendev commented Sep 23, 2018 • edited Loading

obendev commented Oct 13, 2018

Sp1l commented Oct 25, 2018

Sp1l commented Oct 25, 2018 • edited Loading

jvehent commented Oct 25, 2018

obendev commented Oct 25, 2018

Sp1l commented Oct 25, 2018

obendev commented Oct 25, 2018 • edited Loading

lukastribus commented Oct 25, 2018

obendev commented Oct 25, 2018

oerdnj commented Oct 25, 2018

obendev commented Oct 25, 2018

opsarno commented Oct 31, 2018

xnoreq commented Dec 9, 2018

obendev commented Dec 9, 2018

dangoncalves commented Dec 9, 2018

opsarno commented Jan 8, 2019

opsarno commented Jan 11, 2019

MY STRONG CIPHER CONFIG

TLSv1.3 ciphers

TLSv1.2,TLSv1.3 ciphers

TLSv1.1,TLSv1.2,TLSv1.3 ciphers

tomato42 commented Jan 11, 2019

obendev commented Jan 11, 2019

tomato42 commented Jan 11, 2019

obendev commented Jan 11, 2019 • edited Loading

tomato42 commented Jan 11, 2019

obendev commented Jan 11, 2019 • edited Loading

astrava commented Mar 7, 2019

tomato42 commented Mar 7, 2019

obendev commented May 3, 2019 • edited Loading

martinthomson commented May 3, 2019

april commented May 20, 2019

jvehent commented May 20, 2019

april commented May 20, 2019

lukastribus commented Sep 12, 2018 •

edited

Loading

obendev commented Sep 23, 2018 •

edited

Loading

Sp1l commented Oct 25, 2018 •

edited

Loading

obendev commented Oct 25, 2018 •

edited

Loading

obendev commented Jan 11, 2019 •

edited

Loading

obendev commented Jan 11, 2019 •

edited

Loading

obendev commented May 3, 2019 •

edited

Loading