-
Notifications
You must be signed in to change notification settings - Fork 158
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
Comments
the draft is also in AUTH48 state in IETF now, so we can expect it being published as a real RFC Soon™ |
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. |
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_>
.
|
This week folks. |
Now TLS1.3 is a RFC(RFC8446),so it is the time to use it! |
Any news about implementing this? |
it'll happen, just need to find the time |
OpenSSL 1.1.1 released, it's time to use TLSv1.3 |
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. |
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) |
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? |
"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_>
.
|
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
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)
openssl is not the only implementation of TLS 1.3, there are many of them
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 |
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 ( 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.
Sounds like a good thing to me.
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. |
no, both the setting name and the value should be a pass-through for the application, exactly as apache is doing
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)
...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
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.
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 |
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.
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.
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.
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). |
https://www.openssl.org/blog/blog/2018/09/11/release111/
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 Chrome 70 also supports the final version of TLS 1.3 now...
|
Any updates on this? |
Firefox 63 is released, supporting TLSv1.3 just fine. |
So this week TLSv1.3 final RFC 8446 got a real boost:
Anything I can do to help updating the configurator? For now, the default Apache 2.4 config is OK (secure) for TLSv1.3. |
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. |
What has to be done? Is there a todo or something similar? |
For what it's worth...
|
@Sp1l 2.4.37 only included a fix for HTTP/2 |
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:
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)? |
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. |
It's on my TODO list for next two weeks... :) |
Give this man a 🍪 |
YEAH! I think so~ |
@oerdnj Oct 25 + 2 weeks + 1 extra month = today. |
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 |
@xnoreq : we are all waiting your contribution |
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 |
MY STRONG CIPHER CONFIGTLSv1.3 ciphersDelete WEAK cipher
TLSv1.2,TLSv1.3 ciphers
TLSv1.1,TLSv1.2,TLSv1.3 ciphers
Hope to have reference value to everybody. |
neither of those are TLSv1.3 ciphers |
TLS 1.3 ciphers would be for example:
Just set 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 |
no, that enables ADH and AECDH - anonymous ciphersuites that are vulnerable to trivial man in the middle |
Hey tomato42. 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. |
yes, certain versions of Apache do unconditionally append |
My config
Running on apache 2.4.37 and openssl 1.1.1a |
!DSS I found that below ciphersuite considered as old backward compatibility. This is the old ciphersuite that works with all clients back to Windows XP/IE6. |
@astrava that's off-topic for this thread: DSS signatures are not supported in TLS 1.3 |
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 Input a TLS 1.2 cipher (IANA TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 for example) For TLS 1.3 the -ciphersuites parameter comes to work. In your apache configuration you have to add TLSv1.3 before your ciphers.
Secure TLS 1.3 ciphers (openssl names)
Secure TLS 1.2 ciphers (openssl names)
For compatibility reasons you should add:
(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 |
Please don't recommend use of ciphersuites with a 64-bit authentication tag (i.e., CCM8). Those are for specialized applications, not general use. |
How's it coming on merging this? I would love to be recommending https://mozilla.github.io/ssl-config-generator/ The current recommendations are getting pretty dated at this point. |
All it's waiting for is someone who can cleanup the existing PRs and publish a new revision of the guidelines. |
What have we decided upon for each of the three configurations? I'm more than willing to update the JSON files and the wiki. |
TLS 1.3 is now in release in both Chrome and Firefox and supported by Google and Cloudflare.
The text was updated successfully, but these errors were encountered: