-
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
TLS 1.3 ciphers and protocol values #191
Comments
By now, there is a hell mess between TLS1.3 draft-18 and draft-20 in OpenSSL. Majors browsers use the draft-18. So, we could only wait until the final release.
Source. |
See previous comment. |
If you have a server with draft-20 support and browser that has draft-18 support they will simply negotiate TLS1.2. I don't see how this is "interoperability hell"... Just don't disable TLS1.2 and you're fine. |
@tomato42 Could you clarify what change your suggesting in the wiki page or the config generator? |
add
to the list of ciphers in all the versions. For the wiki page, declare them as
|
Need an update on this. For Apache httpd, I have code in trunk that scrapes the Mozilla JSON and makes "modern/intermediate/old" config options for the server. Without any changes, this would mean you want TLSv1.3 disabled for "modern"? How is this supposed to be phased in? |
no, TLSv1.3 should be enabled for modern the general for the policies is that Old is a proper superset of Intermediate and Intermediate is a proper superset of Modern and there's no point in disabling in in Old so it should be part of all three |
In your head maybe. Not in Mozilla's JSON from curl https://statics.tls.security.mozilla.org/server-side-tls-conf.json
|
The final RFC for TLS1.3 has not been published yet. I think we should wait
for that, and maybe some more, before adding it to the guidelines. Early
adopters can tweak their configs, but the majority shouldn't rush in.
…On Wed, Mar 28, 2018, 06:47 Stefan Eissing ***@***.***> wrote:
In your head maybe. Not in Mozilla's JSON from curl
https://statics.tls.security.mozilla.org/server-side-tls-conf.json
...
"configurations": {
"modern": {
"openssl_ciphersuites": ...,
"ciphersuites": [...],
"tls_versions": ["TLSv1.2" ],
...
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#191 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAZXgcbfWpHrwb5Rh_qdOjLf2PPhKlBiks5ti2pBgaJpZM4NXBV->
.
|
The ciphers for TLS1.3 are defined and draft28 has been approved. None of this will change in a way that would impact the Mozilla recommendation. When OpenSSL 1.1.1 is released, and TLSv1.3 has not been specifically disabled by the application, but the cipher configuration won't contain TLSv1.3 ciphers, OpenSSL will fail for all TLS version completely. So upgrading to OpenSSL 1.1.1 will break existing setups with Mozilla recommendations. So if there is consensus about not implementing TLSv1.3 recommendations now, we should then explicitly suggest to disable TLSv1.3. @tomato42 "old" contains most recent TLSv1.2 AEAD ciphers like ECDHE-ECDSA-CHACHA20-POLY1305 and ECDHE-ECDSA-AES128-GCM-SHA256, old must contain everything that is in modern as well. The entire point of this recommendation is that "old" configuration does not break modern software stacks which may not even have obsolete ciphers anymore. |
That sounds like a terrible idea. Why would openssl decide to do this? |
can you go and be rude somewhere else?
that's what I said... If something is in Modern, it needs to be in all three, exactly so that Old configuration is the most compatible, Intermediate less so and Modern least so
likely because disabling TLS 1.3 based on cipherstring would be more surprising |
A valid argument, yet I wonder if this will block a massive rollout of openssl 1.1.1 due to large amount of configurations breaking. |
Well, in my very limited testing, I enabled TLSv1.3 in addition to the setting specified as Mozilla If you see other results in your settings, please let us know. |
Apparently the reason is:
This "design choice" is final: openssl/openssl#5057 So either we add the recommended TLSv1.3 everywhere, or if we decide to wait, we have to suggest to everyone to disable TLSv1.3. I strongly suggest the former (adding "TLS13-AES-128-GCM-SHA256:TLS13-CHACHA20-POLY1305-SHA256:TLS13-AES-256-GCM-SHA384" to the top of the recommendations). @jrchamp @tomato42 yes indeed I misunderstood the point you made. |
To be clear: I'm in favor of adding TLS1.3 to the guidelines. I just want to be mindful about when, to make sure we don't break people's configurations while draft implementations are still out there. Ultimately, I don't think waiting another month or two isn't going to change anything. The OpenSSL incompatibility issue changes this a bit. |
I said: "In your head maybe (but the JSON says otherwise)" This was not intended to be rude. What I meant was that the machine readable specification does not match what you think it should be. I'd like to get an understanding of what it needs to be, so that code may act accordingly and correctly, before we ship it to millions of sites. I agree with you that TLSv1.3 should be in |
I opened this issue to add them there, of course I know they're not there |
Misunderstood you there. Sorry for the wasted cycles. |
@lukastribus while I remember reading about this behaviour before I can't reproduce it now with current master (openssl/openssl@e6e9170) when I run From what I can see, there's a separate API call needed to change behaviour in TLS 1.3: https://www.openssl.org/docs/manmaster/man3/SSL_CTX_set_ciphersuites.html Same for the |
@tomato42 HIGH contains TLSv1.3 ciphers so this is expect. Use the mozilla recommendation (with specific non-TLSv1.3 ciphers, not groups like HIGH) to hit this issue. To be clear and avoid any additional misunderstandings: what I am saying is that OpenSSL 1.1.1 will break with the current Mozilla recommendation, and your proposal resolves this. |
@lukastribus actually no, it is not part of with current master I've filed openssl/openssl#5777 to fix the blog post |
It seems like there are two separate issues here:
Based on the discussion here, I have to say I'm a bit unclear on whether our current recommendations break OpenSSL. If not, I think it's fine -- indeed perhaps preferable -- to delay recommending TLS 1.3 until the RFC is published. OTOH, if we have to change our recommendations anyway, this requires more thought. So maybe we can get consensus on the facts first? |
@tomato42 I see, thanks. And indeed this change fixes the breakage caused by OpenSSL 1.1.1 behavior. So they did change their opinion on this after all, which is good. @ekr correct; now there is consensus though about the breakage, which was fixed by OpenSSL later on. So forget what I said about OpenSSL 1.1.1; also there is no rush at this point to consider TLSv1.3 ciphers. In fact the opposite is the case. as @tomato42 noticed, OpenSSL now has a different API to configure TLSv1.3 ciphers (SSL_CTX_set_ciphersuites()). So actually applications will need to implement this new API and will therefor have to expose a different configuration option to the user. So I'd argue that it doesn't make sense to merge TLSv1.3 with TLS <= 1.2 ciphers in the Mozilla recommendation then, as it will be a different config knob in the application anyway. Sorry for the outdated informations here, I didn't expect the OpenSSL team to do a 180 on this what looked like a "final design decision" ... |
So, my understanding of this:
So 1.2 and 1.3 have separate protocol config sets (at least for ciphers) and those need to be configured separately. So, I better add a config directive to set the ciphers for TLSv1.3 then. |
Yes, OpenSSL changed behavior after alpha-test results came in and showed that what we were doing was not good. So yay, the process worked. :) Because the TLS 1.3 ciphers are really very very very different from everything before them, we decided it is better to have them be handled separately. If TLS 1.3 is enabled, then by default all TLS 1.3 ciphers are enabled (slightly different from @icing's bullets above). Applications that want to disable some of them, or change the order, need to use a new API or command-line flags. So yeah, making a separate config directive is the way I would do it. |
I'll close this as it sounds resolved, if I'm mistaken please let me know and clarify what remains to be done. |
No, the TLS 1.3 ciphers are not described in the document, so it's not resolved |
This is fixed in 5.0. |
Especially for openssl cipher string, the TLS1.3 cipher names could already be added.
In general, we should have a plan when the TLS 1.3 is published as a standard RFC.
The text was updated successfully, but these errors were encountered: