Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

It is time to add support for TLS 1.3 #217

Open
ekr opened this issue Jun 19, 2018 · 48 comments

Comments

Projects
None yet
@ekr
Copy link

commented Jun 19, 2018

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

@tomato42

This comment has been minimized.

Copy link
Member

commented Jun 20, 2018

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

@jrchamp

This comment has been minimized.

Copy link
Contributor

commented Jun 20, 2018

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

This comment has been minimized.

Copy link
Author

commented Jun 20, 2018

@martinthomson

This comment has been minimized.

Copy link
Member

commented Aug 9, 2018

This week folks.

@railjty

This comment has been minimized.

Copy link

commented Aug 19, 2018

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

@Mattia98

This comment has been minimized.

Copy link

commented Sep 5, 2018

Any news about implementing this?

@captn3m0

This comment has been minimized.

Copy link
Contributor

commented Sep 5, 2018

Some WIP at #183 (Discussion at #178)

@jvehent

This comment has been minimized.

Copy link
Contributor

commented Sep 6, 2018

it'll happen, just need to find the time

@virusdefender

This comment has been minimized.

Copy link

commented Sep 11, 2018

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

@Sp1l

This comment has been minimized.

Copy link
Contributor

commented Sep 12, 2018

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

This comment has been minimized.

Copy link
Member

commented Sep 12, 2018

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

This comment has been minimized.

Copy link

commented Sep 12, 2018

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

This comment has been minimized.

Copy link

commented Sep 12, 2018

@tomato42

This comment has been minimized.

Copy link
Member

commented Sep 12, 2018

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

This comment has been minimized.

Copy link

commented Sep 12, 2018

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

This comment has been minimized.

Copy link
Member

commented Sep 12, 2018

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

This comment has been minimized.

Copy link

commented Sep 13, 2018

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

This comment has been minimized.

Copy link

commented Sep 23, 2018

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

This comment has been minimized.

Copy link

commented Oct 13, 2018

Any updates on this?

@Sp1l

This comment has been minimized.

Copy link
Contributor

commented Oct 25, 2018

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

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

@Sp1l

This comment has been minimized.

Copy link
Contributor

commented Oct 25, 2018

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

This comment has been minimized.

Copy link
Contributor

commented Oct 25, 2018

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

This comment has been minimized.

Copy link

commented Oct 25, 2018

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

@Sp1l

This comment has been minimized.

Copy link
Contributor

commented Oct 25, 2018

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

This comment has been minimized.

Copy link

commented Oct 25, 2018

@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

This comment has been minimized.

Copy link

commented Oct 25, 2018

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

This comment has been minimized.

Copy link

commented Oct 25, 2018

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

This comment has been minimized.

Copy link

commented Oct 25, 2018

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

@obendev

This comment has been minimized.

Copy link

commented Oct 25, 2018

Give this man a 🍪

@opsarno

This comment has been minimized.

Copy link

commented Oct 31, 2018


    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

This comment has been minimized.

Copy link

commented Dec 9, 2018

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

@obendev

This comment has been minimized.

Copy link

commented Dec 9, 2018

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

This comment has been minimized.

Copy link

commented Dec 9, 2018

@xnoreq : we are all waiting your contribution

@opsarno

This comment has been minimized.

Copy link

commented Jan 8, 2019

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

This comment has been minimized.

Copy link

commented Jan 11, 2019

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

This comment has been minimized.

Copy link
Member

commented Jan 11, 2019

neither of those are TLSv1.3 ciphers

@obendev

This comment has been minimized.

Copy link

commented Jan 11, 2019

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

This comment has been minimized.

Copy link
Member

commented Jan 11, 2019

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

This comment has been minimized.

Copy link

commented Jan 11, 2019

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

This comment has been minimized.

Copy link
Member

commented Jan 11, 2019

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

@obendev

This comment has been minimized.

Copy link

commented Jan 11, 2019

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

This comment has been minimized.

Copy link

commented Mar 7, 2019


    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

This comment has been minimized.

Copy link
Member

commented Mar 7, 2019

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

@obendev

This comment has been minimized.

Copy link

commented May 3, 2019

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

This comment has been minimized.

Copy link
Member

commented May 3, 2019

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

This comment has been minimized.

Copy link
Contributor

commented May 20, 2019

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

This comment has been minimized.

Copy link
Contributor

commented May 20, 2019

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

This comment has been minimized.

Copy link
Contributor

commented May 20, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.