Closed jvehent closed 5 years ago
Hmm, that looks like a bit overkill for what I'm looking for. I just want to pass in a list of protocols and ciphersuites and see what clients pop out on the other end. But thank you! :)
well, it's not only the question of ciphersuites, advertised signature algorithms and key exchange groups also are part of configuration and affect what kind of clients can connect in practice
Sure, but prime256v1
is supported by everything that support ECDHE (afaik) and will be on every list, and I don't think there is any client software that doesn't support custom DHE groups (which we already recommend).
IIRC old versions of iOS can't do P-384 with SHA-384, but yes, P-256 should be universally supported
custom DHE groups are a bit more complicated: https://github.com/mozilla/server-side-tls/issues/244#issuecomment-491909295
FYI, SSL Labs hasn't updated their getClients
API in roughly nine months, making it very difficult to determine the compatibility of a bunch of clients. I've sent them emails and opened a bug, but I don't have any ETA for it to get updated:
Okay, sorry this took so long. It was annoyingly fiddly.
For Intermediate, if we have the following limitations:
Namely, this list:
Protocols: TLS 1.2, TLS 1.3 Cipher Suites:
Then the compatibility is thus, according to SSL Labs:
If we add back in the SHA-1 HMACs, we push back things a smidgen:
If we add back classic DHE, we don't really get anything more than the previous list. Surprisingly.
To be honest, I'm surprised at how good that first list looks. So I'm inclined to go with that for Intermediate, and move the current Intermediate back to Old.
Any objections? The big thing we lose over the current Intermediate list is any sense of compatibility with Windows XP.
Please remember that the SSLLabs list of clients is very much incomplete – one big omission is GnuTLS, library used for wget, among others.
@april for IE: did you assume both ECDSA and RSA certs installed for backwards compat or just RSA?
While I agree that it's very limited, I don't really know of any alternatives. GnuTLS support for that cipher suite list goes back 2013, or at least something in that ballpark, from what I could research.
Using an ECDSA cert seems to have the exact same compatibility as using an RSA cert, presumably because ECDSA support got implemented at the same time (roughly) as ECDHE.
@april The issue is that IE 11 on Windows 7 and 8 only support RSA+DHE or ECDSA+ECDHE for AES-GCM with forward security. RSA+ECDHE+AES-GCM isn't a supported combination on Windows 7/8 (even though it is on Windows 10). To ensure compatibility with IE 11+Win 7/8 for servers that only have an RSA certificate (which is the most common configuration) you will either need to enable at least one non-EC DHE or one CBC ciphersuite.
Blah, thanks IE. In that case, I guess I would say that it probably seems preferable to stick with AEADs (as recommended in RFC 7525), and add:
Making this the complete list, in order:
How do people like this particular list? I think that supports every major platform in use on the internet at this point.
Oh, and last thing: what should the order be between AES128-GCM, AES256-GCM, and CHACHA20-POLY1305?
Currently, Modern uses: AES256-GCM -> CHACHA20-POLY1305 -> AES128-GCM
And Intermediate currently uses: CHACHA20-POLY1305 -> AES128-GCM -> AES256-GCM
OpenSSL has an order preference identical to the current Modern: AES256-GCM -> CHACHA20-POLY1305 -> AES128-GCM
Whereas TLS 1.3 orders them as: AES128-GCM -> AES256-GCM -> CHACHA20-POLY1305
Has the reasoning from a few years ago changed?
AES256-GCM is prioritized above its 128 bits variant, and ChaCha20 because we assume that most modern devices support AESNI instructions and thus benefit from fast and constant time AES.
That was for Modern, if I recall? I believe CHACHA20-POLY1305 was listed first in Intermediate as a concession to all the mobile hardware that didn't have hardware accelerated AES. That's probably a lot less of a concern now.
We should prioritize GCM across the board. If you want to be sensitive to mobile, you should listen to the client's preferences.
On Mon, Jun 10, 2019 at 9:05 AM April King notifications@github.com wrote:
That was for Modern, if I recall? I believe CHACHA20-POLY1305 was listed first in Intermediate as a concession to all the mobile hardware that didn't have hardware accelerated AES. That's probably a lot less of a concern now.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/mozilla/server-side-tls/issues/178?email_source=notifications&email_token=AAIPLINUBHUCMB4JOJXAOJ3PZZ3TBA5CNFSM4C2ZDC22YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXKKGKA#issuecomment-500474664, or mute the thread https://github.com/notifications/unsubscribe-auth/AAIPLIILYTBRAVLHIXRZNSLPZZ3TBANCNFSM4C2ZDC2Q .
That works for me. That would make this the final Intermediate cipher suite list:
In the process of writing the Wiki guidelines now, but here is the summary until it is available. I did make some tweaks to Modern (384 bit ECDSA or 4098 bit RSA, added X25519), unless people have strong objections in which case I can bump those back down to 256 and 2048 (or 3072).
The thought is that people using Modern are looking for the best security regardless of the performance cost. That could be wrong.
Ciphersuites: TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256:TLS_CHACHA20_POLY1305_SHA256
Protocols: TLSv1.3
TLS curves: X25519, prime256v1, secp384r1
Certificate type: ECDSA
Certificate size: 256-bits (ECDSA), 2048-bits (RSA)
Supported clients: Firefox 63, Chrome 70, Edge 75, Safari 12.1 (on Mojave), iOS 12.2, Android 10.0 ("Q"), Java 11, OpenSSL 1.1.1
Ciphersuites: TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256:TLS_CHACHA20_POLY1305_SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256
Protocols: TLS 1.2, TLS 1.3
TLS curves: X25519, prime256v1, secp384r1
Certificate type: ECDSA (preferred) or RSA
Certificate size: 256-bits (ECDSA) or 2048-bits (RSA)
DH Parameter size: 2048-bits
Supported clients: Firefox 27, Chrome 31, IE 11 (Win 7), Edge, Safari 9, Android 4.4.2, OpenSSL 1.0.1, Java 8u31
Ciphersuites: ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-CHACHA20-POLY1305:DHE-DSS-AES256-GCM-SHA384:DHE-DSS-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-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:DHE-DSS-AES128-SHA256:DHE-DSS-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:ECDHE-ECDSA-ARIA128-GCM-SHA256:ECDHE-ECDSA-ARIA256-GCM-SHA384:ECDHE-ARIA128-GCM-SHA256:ECDHE-ARIA256-GCM-SHA384:DHE-RSA-ARIA128-GCM-SHA256:DHE-DSS-ARIA128-GCM-SHA256:DHE-RSA-ARIA256-GCM-SHA384:DHE-DSS-ARIA256-GCM-SHA384:ECDHE-ECDSA-CAMELLIA128-SHA256:ECDHE-RSA-CAMELLIA128-SHA256:ECDHE-ECDSA-CAMELLIA256-SHA384:ECDHE-RSA-CAMELLIA256-SHA384:DHE-RSA-CAMELLIA128-SHA256:DHE-RSA-CAMELLIA256-SHA256:DHE-RSA-CAMELLIA128-SHA:DHE-RSA-CAMELLIA256-SHA:DHE-DSS-CAMELLIA128-SHA256:DHE-DSS-CAMELLIA256-SHA256:DHE-DSS-CAMELLIA128-SHA:DHE-DSS-CAMELLIA256-SHA:ARIA128-GCM-SHA256:ARIA256-GCM-SHA384:CAMELLIA128-SHA256:CAMELLIA256-SHA256:CAMELLIA128-SHA:CAMELLIA256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:DES-CBC3-SHA:DHE-RSA-SEED-SHA:DHE-DSS-SEED-SHA:SEED-SHA
Protocols: TLS 1.0, TLS 1.1, TLS 1.2, TLS 1.3
TLS curves: X25519, prime256v1, secp384r1
Certificate type: RSA
Certificate size: 2048-bits (RSA)
DH Parameter size: 1024-bits
Supported clients: Java 6, Windows XP (IE 8) (I think!!)
I don't think it makes sense to recommend 384-bits for signing, for several reasons.
On Mon, Jun 10, 2019 at 1:11 PM April King notifications@github.com wrote:
In the process of writing the Wiki guidelines now, but here is the summary until it is available. I did make some tweaks to Modern (384 bit ECDSA or 4098 bit RSA, added X25519), unless people have strong objections in which case I can bump those back down to 256 and 2048 (or 3072).
The thought is that people using Modern are looking for the best security regardless of the performance cost. That could be wrong. Modern
Ciphersuites: ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305 Protocols: TLSv1.3 TLS curves: X25519, prime256v1, secp384r1 Certificate type: ECDSA (given that Ed25519 certs are still hard to come by) Certificate size: 384 (ECDSA), 4096-bits (RSA)
Supported clients: Firefox 63, Chrome 70, Edge 75, Safari 12.1 (on Mojave), iOS 12.2, Android 10.0 ("Q"), Java 11, OpenSSL 1.1.1 Intermediate:
Ciphersuites: ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256 Protocols: TLS 1.2, TLS 1.3 TLS curves: X25519, prime256v1, secp384r1 Certificate type: RSA (ECDSA acceptable if IE11 + Win7 support not needed) Certificate size: 2048-bits (RSA), 256-bits (ECDSA) DH Parameter size: 2048-bits
Supported clients: Firefox 27, Chrome 31, IE 11 (Win 7), Edge, Safari 9, OpenSSL 1.0.1, Java 8u31 Old
Ciphersuites: ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:ECDHE-RSA-DES-CBC3-SHA:ECDHE-ECDSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:DES-CBC3-SHA:HIGH:SEED:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!RSAPSK:!aDH:!aECDH:!EDH-DSS-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA:!SRP Protocols: TLS 1.0, TLS 1.1, TLS 1.2, TLS 1.3 TLS curves: X25519, prime256v1, secp384r1 Certificate type: RSA Certificate size: 2048-bits (RSA) DH Parameter size: 1024-bits
Supported clients: Java 6, Windows XP (IE 8) (I think!!)
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/mozilla/server-side-tls/issues/178?email_source=notifications&email_token=AAIPLIJ2O3WH2CIS2Q3BWZLPZ2YQTA5CNFSM4C2ZDC22YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXLC7BA#issuecomment-500576132, or mute the thread https://github.com/notifications/unsubscribe-auth/AAIPLIN6HW4HOCOVLSXWXKDPZ2YQTANCNFSM4C2ZDC2Q .
Certificate type: RSA (ECDSA acceptable if IE11 + Win7 support not needed)
IE11 + Win 7 supports ECDSA just fine. The only issue it has is the specific combination of RSA + ECDHE + AES-GCM.
Perfect. I've updated the previous post to:
I don't know enough about openssl config to know if you are including TLS 1.3 ciphers in those lists. Going by this old blog, these lists look off.
If you are going to include DHE suites in the list then you should recommend a group, not just a size. The RFC 7919 2048-bit group is fine, but an IKE one also works. You don't want to have people generating random groups.
When you say certificate "size", I think that you want to specifically say "P-256" for ECDSA rather than 256-bit. For RSA, there are numbers between 2048 and 4096. You get pretty good traction out of 3172 for instance and it costs a whole lot less to send it and compute a signature.
Note that the same reasoning applies to RSA key size as to ECDSA key size. There's no point in having a certificate signed with > 2048 bits. It's potentially valuable to have the leaf key be > 2048 bits if you do static RSA (because you're hedging against a passive decryption attack) but if you only do (EC)DHE, then you should just use a leaf key of 2048 bits.
On Mon, Jun 10, 2019 at 6:07 PM Martin Thomson notifications@github.com wrote:
I don't know enough about openssl config to know if you are including TLS 1.3 ciphers in those lists. Going by this old blog https://www.openssl.org/blog/blog/2017/05/04/tlsv1.3/, these lists look off.
If you are going to include DHE suites in the list then you should recommend a group, not just a size. The RFC 7919 2048-bit group is fine, but an IKE one also works. You don't want to have people generating random groups.
When you say certificate "size", I think that you want to specifically say "P-256" for ECDSA rather than 256-bit. For RSA, there are numbers between 2048 and 4096. You get pretty good traction out of 3172 for instance and it costs a whole lot less to send it and compute a signature.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/mozilla/server-side-tls/issues/178?email_source=notifications&email_token=AAIPLIL7KAAILIP4JVO2B2TPZ33DRA5CNFSM4C2ZDC22YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXLUKJI#issuecomment-500647205, or mute the thread https://github.com/notifications/unsubscribe-auth/AAIPLIPJ5Z3KR6J6ARP3UKDPZ33DRANCNFSM4C2ZDC2Q .
I don't know enough about openssl config to know if you are including TLS 1.3 ciphers in those lists. Going by this old blog, these lists look off.
Yes, it should have all the default TLS 1.3 ciphersuites besides AES-CCM:
$ ./openssl ciphers -V | grep 1.3
0x13,0x02 - TLS_AES_256_GCM_SHA384 TLSv1.3 Kx=any Au=any Enc=AESGCM(256) Mac=AEAD
0x13,0x03 - TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any Au=any Enc=CHACHA20/POLY1305(256) Mac=AEAD
0x13,0x01 - TLS_AES_128_GCM_SHA256 TLSv1.3 Kx=any Au=any Enc=AESGCM(128) Mac=AEAD
If you are going to include DHE suites in the list then you should recommend a group, not just a size. The RFC 7919 2048-bit group is fine, but an IKE one also works. You don't want to have people generating random groups.
Very little software lets you choose a group, so I don't know if it's valuable to send them down a rabbit hole to figure out how to do that when it's almost never possible. Currently, the configuration generator tells people:
# generate with: $ openssl dhparam -out /path/to/dhparam.pem 2048
ssl_dhparam /path/to/dhparam.pem;
Which has seemed the best in a world where software otherwise does a very poor job giving you control. For example, in nginx if you don't specify a file you simply don't get DHE. Prior to that change, I believe it just chose a default 1024-bit group. Basically everything is bad with DHE.
When you say certificate "size", I think that you want to specifically say "P-256" for ECDSA rather than 256-bit. For RSA, there are numbers between 2048 and 4096. You get pretty good traction out of 3172 for instance and it costs a whole lot less to send it and compute a signature.
Yes, just shorthand to save time. :)
We can recommend 3072; I had originally written things down as 3072, but switched to 4096 simply because a lot of software only lets you select 2^n-bit RSA key sizes. I don't have particularly strong feelings between 2048, 3072, or 4096. If @ekr thinks 2048-bit is reasonable, that works for me, especially since my plan is to recommend 90-day key rotations for Modern.
If @ekr https://github.com/ekr thinks 2048-bit is reasonable, that works for me, especially since my plan is to recommend 90-day key rotations for Modern.
Why are you recommending key rotation? What's your threat model?
It would be for weird things like Heartbleed, or accidental key disclosure.
Maybe it's not a big deal, and instead we should simply have a maximum recommended certificate lifespan of 90 days (and two years in Intermediate) to force people to work on certificate automation?
Yes, it should have all the default TLS 1.3 ciphersuites besides AES-CCM:
I don't even know if you answered my question here. Was that with the proposed configuration list installed? Because none of the lists you provide include TLS_AES_256_GCM_SHA384
(for example).
Very little software lets you choose a group [...]
Don't penalize the software that does. A generated group is more likely to be rejected.
++ to @ekr regarding the expiration thing. There might be good reasons to have short certificate lifetimes (see also the state of revocation), but I see no advantage in using expiration to manage the risk of key disclosure.
I don't even know if you answered my question here. Was that with the proposed configuration list installed? Because none of the lists you provide include TLS_AES_256_GCM_SHA384 (for example).
Oh, I see what you're saying. Good call. I'll update the lists above; I had forgotten that OpenSSL 1.1.1 is very weird about how it handles ciphers
(e.g. it needs -ciphersuites
to catch that).
Does a 90-day recommended maximum certificate lifespan sound good for Modern? Any objections to that, or do you think we should stay neutral?
Don't penalize the software that does. A generated group is more likely to be rejected.
There basically is no software that lets you configure to a known good group. Note that the Server Side TLS 5.0 guidelines won't say to use dhparam
, it's just the generator that does. And it only does that if the server software doesn't Do The Right Thing(tm), of which basically nothing does right now (except Apache >2.5, afaik).
Software that lets you choose good known group will have its template updated to do so, if said software ever starts existing. Given that nobody seems to care much about it, I think it's far more likely that DHE goes away entirely in the end. But the generator will not penalize software that gets updated to behave well.
I was thinking about this, and a possible alternative would be us to host RFC 7919's ffdhe2048 (as ffdhe2048.txt or whatever) and then have the generator recommend this instead:
# save with: $ curl https://raw.githubusercontent.com/mozilla/server-side-tls/gh-pages/ffdhe2048.txt > /path/to/dhparam.pem;
ssl_dhparam /path/to/dhparam.pem;
Would everyone be okay with that as a reasonable alternative?
Yes, that would be better. Also, as a server, NSS only supports the 7919 groups.
Perfect, I opened up an issue: https://github.com/mozilla/ssl-config-generator/issues/13
And I'll take care of that tomorrow. Thanks, @martinthomson, @ekr, and @tylerknott (and everyone else) - I really appreciate your feedback.
The new config generator now serves up the RFC 7919 group and includes instructions on how to use it. :)
Okay, more updates! It took a pile of work, but the config generator now supports TLS 1.3 for all pieces of software that support it. It's really awkward because ciphers work completely differently in OpenSSL with TLS 1.3.
Most everything we had before is unchanged from the discussion above, aside from changing how servers choose which cipher to use. Namely, for people using the TLS 1.3-only "Modern" configuration, it will now respect the client-ordered list over the server-ordered list.
Previously, we had always used the server-ordered list because many clients used outdated ciphers at the top of the cipher list. Since all TLS 1.3 cipher suites are secure, we've switched to respecting the client-ordered list since the client will (presumably) know best if they have hardware-accelerated AES or not.
If you have a chance, please poke away at the updated website. It is the reflected representation of the updated standards, and I would like it to be bug-free. Thanks!
https://ssl-config.mozilla.org/#server=nginx&server-version=1.16.0&config=modern
If you have a chance, please poke away at the updated website. It is the reflected representation of the updated standards, and I would like it to be bug-free. Thanks!
https://ssl-config.mozilla.org/#server=nginx&server-version=1.16.0&config=modern
https://ssl-config.mozilla.org/#server=caddy&server-version=1.0.0&config=modern appears to show tls1.3
twice!
EDIT: Oh, sorry, that just happens to be matching min and max. Repeating the value is allowed per https://caddyserver.com/docs/tls
Not only is it allowed, but it's required. :)
Their docs seem to note that it might not to be required, but I have no experience with their produce so I can't say if that's valid or incorrect or even correctly matched to the 1.0.0 version:
protocols specifies the minimum and maximum protocol versions to support. See below for valid values. If min and max are the same, it need only be specified once.
On Fri, Jun 14, 2019 at 2:39 PM April King notifications@github.com wrote:
Not only is it allowed, but it's required. :)
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/mozilla/server-side-tls/issues/178?email_source=notifications&email_token=AAAWUDBZSOKUQLHR5FXCMMDP2QFZFA5CNFSM4C2ZDC22YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXYFDMA#issuecomment-502288816, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAWUDHYQABLBUAQOOGYBBTP2QFZFANCNFSM4C2ZDC2Q .
FYI, I've got a PR in for the wiki update to Server Side TLS 5.0 in #255.
You can see the updated text here: https://github.com/mozilla/server-side-tls/blob/cc42719fe3113ec665dab3afad1cd20f202d9dac/Server_Side_TLS.mediawiki
GitHub does strip a lot of the formatting away, so don't be alarmed by weird formatting or missing images.
Thanks for everyone who has reviewed the updated guidelines so far, it's been very helpful.
Barring any objections, I plan on merging this Friday, as it's mostly a reflection of the decisions already reviewed in this thread.
One question that was brought up was, given the set of cipher suites in Intermediate:
0x13,0x02 - TLS_AES_256_GCM_SHA384 TLSv1.3 Kx=any Au=any Enc=AESGCM(256) Mac=AEAD
0x13,0x01 - TLS_AES_128_GCM_SHA256 TLSv1.3 Kx=any Au=any Enc=AESGCM(128) Mac=AEAD
0x13,0x03 - TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any Au=any Enc=CHACHA20/POLY1305(256) Mac=AEAD
0xC0,0x2C - ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(256) Mac=AEAD
0xC0,0x30 - ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD
0xC0,0x2B - ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(128) Mac=AEAD
0xC0,0x2F - ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(128) Mac=AEAD
0xCC,0xA9 - ECDHE-ECDSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH Au=ECDSA Enc=CHACHA20/POLY1305(256) Mac=AEAD
0xCC,0xA8 - ECDHE-RSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH Au=RSA Enc=CHACHA20/POLY1305(256) Mac=AEAD
0x00,0x9F - DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(256) Mac=AEAD
0x00,0x9E - DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(128) Mac=AEAD
Does it make sense to let the client choose which cipher suite gets used?
Obviously for the Old configuration, it makes sense to force them onto the most secure cipher suite. But for Intermediate, is it still necessary to allow the server to choose?
I feel like there should have been more audibly public acknowledgement in making modern be TLS 1.3 only. Personally I'm of a preference of 1.3 + 1.2 w/ GCM rollout (over ECDSA works better because as noted earlier you cover Win7 and Win8 also since microsoft in all their brilliance decided to only implement ECDSA GCM and not RSA GCM in those two cryptolib versions).
With that said I'm still kind of a fan of server-impressed cipher order if anything due to the community concerns and personal preferences of AES-128 over AES-256 from the much-debated key-weakness concerns (however still topical enough that some client software prioritize 128-bit over 256-bit such as Firefox and Chrome for example).
But yeah with all the people that sorta make use of the mozilla ssl-generator tool without really understanding the concepts of everything, making modern TLS 1.3 only isn't a good model yet imo.
Also is the actual cipher string supposed to be missing for the modern configuration? The cipher relative directive in the config examples are empty for the modern option and that might lead to errors in config loading.
Okay, more updates! It took a pile of work, but the config generator now supports TLS 1.3 for all pieces of software that support it. It's really awkward because ciphers work completely differently in OpenSSL with TLS 1.3.
They opt'd to go with the RFC spec naming in the case of TLS 1.3 as I recall, but it still works in a cipher reference together with the 'classic' formats (ie; TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-ECDSA-ARIA256-GCM-SHA384:ECDHE-ECDSA-ARIA128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384
With that said I'm still kind of a fan of server-impressed cipher order if anything due to the community concerns and personal preferences of AES-128 over AES-256 from the much-debated key-weakness concerns (however still topical enough that some client software prioritize 128-bit over 256-bit such as Firefox and Chrome for example).
FWIW, we prefer AES-128 for performance reasons. primarily.
With that said I'm still kind of a fan of server-impressed cipher order if anything due to the community concerns and personal preferences of AES-128 over AES-256 from the much-debated key-weakness concerns (however still topical enough that some client software prioritize 128-bit over 256-bit such as Firefox and Chrome for example).
FWIW, we prefer AES-128 for performance reasons. primarily.
Yeah I was gonna mention that too but usually it ends up with "Meh it's negligible" replies so figured I'd just stick with the current security standings lol
But yeah the performance concerns (especially on mobile hardware or hardware w/out AES-NI capacity) are definitely notable. At least not counting things like Chrome which default to ChaChaPoly usually in those events.
Modern was always intended to be aspirational, when you have control over both the clients and endpoints. There is literally nothing wrong with using the Intermediate configuration: it’s very close to the old Modern configuration and any loosening of Modern would basically make it into Intermediate anyways. It is exactly what you describe: TLS 1.3 + TLS 1.2/FS/AEADs.
And yes, with TLS 1.3 most software chooses not to allow the ordering of cipher suites, which is largely controlled by a global OpenSSL configuration file that almost nobody touches.
I had chosen AES-256 over AES-128 since that had been the preferences in this thread. It seems like a good compromise would be letting the client choose in Intermediate, and preferring AES-128 over AES-256 in Old (which is generally done already). I really like the idea of letting the client choosing the most performant algorithm in a world where all the options are secure.
Well yeah no I wasn't arguing against the intermediate necessarily being used, just that the less tech-ept people are gonna probably go "Oh I better be modern in this day and age of scary hackers" and then wonder why they're lacking a lot of traffic or getting complaints lol. Maybe my years of dealing with VPS's setup by people going with no knowledge going by what "Guides instruct them" may be jading my views though.
As for TLS 1.3 and cipher order, that was (at least at the time discussed in ##openssl on freenode) a bug with OpenSSL, one that oddly still doesn't seem to be fixed w/ 1.1.1c. I'll see if I can dig up the conversation about it or a bug entry in relation to this.
As for AES-256 over 128 as 'security over performance', is there a concern you have with AES 128 I'm not familiar with? Like noted earlier there are actual active security concerns with AES-256, the most I can think of in relation to AES-128 are people worrying about it w/ the evolution of 'quantum computing'. Is that the reason for preference?
At the very least I feel like the directive should be left in the config examples w/ commentary perhaps.
That said, in relation to Intermediate, you should be able to actually drop DHE completely and still keep the specified browser support in the sub-label (see one of my example setups; just ignore the CBC stuff still floating at the bottom)
That said, in relation to Intermediate, you should be able to actually drop DHE completely and still keep the specified browser support in the sub-label (see one of my example setups; just ignore the CBC stuff still floating at the bottom)
As we've previously discussed you need to include the DHE+RSA+AESGCM suites for IE 11 compatibility (on Windows 7 and 8) for servers using only an RSA certificate (by far the most common configuration today). Your example server has an ECDSA certificate (in addition to the RSA certificate) which is why none of the clients require those suites. It might be worth noting in the guidelines that the non-EC DHE suites can be omitted if you're using an ECDSA certificate (since they can only be used with RSA certificates).
Well yeah no I wasn't arguing against the intermediate necessarily being used, just that the less tech-ept people are gonna probably go "Oh I better be modern in this day and age of scary hackers" and then wonder why they're lacking a lot of traffic or getting complaints lol.
If someone ignores all the direction at the top of the configuration, in the supported client list, in the configuration description, and on the SSL Configuration Generator page, that’s on them. It would be immediately obvious it didn’t work and furthermore this is the exact same situation as with the previous Modern configuration where it wasn’t a problem.
It might be worth noting in the guidelines that the non-EC DHE suites can be omitted if you're using an ECDSA certificate (since they can only be used with RSA certificates).
It was a very conscious decision not to do this, for all the configurations where someone is simply pointing at whatever certificate they might have, unaware of what type it is. It doesn’t hurt anything for them to be in there if someone has an ECDSA certificate.
As we've previously discussed you need to include the DHE+RSA+AESGCM suites for IE 11 compatibility (on Windows 7 and 8) for servers using only an RSA certificate (by far the most common configuration today). Your example server has an ECDSA certificate (in addition to the RSA certificate) which is why none of the clients require those suites. It might be worth noting in the guidelines that the non-EC DHE suites can be omitted if you're using an ECDSA certificate (since they can only be used with RSA certificates).
Well the earlier discussion (and I believe noted in another post) is that ECDSA is being recommended as the default anyways no? If we're going so far as to emphasize GCM only because of the recent CBC issues and not support RSA CBC at all, then you might as well default everything to ECDSA priority (which is indeed what that particular one does and what the current intermediate configuration is doing w/ ECDHE-ECDSA-AES256-GCM-SHA384
being the first cipher in the list).
It didn't require the suites because of the order the ciphers were specified, they follow certificate acceptance based on cipher preference order, since my ECDSA ciphers were first, browsers that supported them (ECC) it used them, those that did not (such as the older Safari's) pulled the RSA certificate and utilized those ciphers.
I've not been using any DHE ciphers on any of my setups for at least a year now if not a bit longer (even when I was still MinProtocol
supporting 1.1), usually only with a single certificate. That one was just rolling a dual-pair as I've been doing some testing w/ cipher order loading w/ lighttpd.
If someone ignores all the direction at the top of the configuration, in the supported client list, in the configuration description, and on the SSL Configuration Generator page, that’s on them. It would be immediately obvious it didn’t work and furthermore this is the exact same situation as with the previous Modern configuration where it wasn’t a problem.
True, I guess I'm just getting too used to having to stupid-proof documentation for people lately lol. But I wouldn't necessarily say immediately obvious to tech-inept people, but yeah. I guess time will tell, still feel like making TLS 1.3 a default modern model only is speeding things along a little -too- quickly, but then again a lot of historical security issues was because of slow adoption so perhaps this isn't the worst of motivations.
A reposting of the final proposal, given the comments above. If I can get some r+ on this from @ekr, @martinthomson, or @jvehent, I'd be happy to get this shipped. Thanks everyone!
Ciphersuites: TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256
Protocols: TLS 1.3
TLS curves: X25519, prime256v1, secp384r1
Certificate type: ECDSA (P-256)
Cipher preference: Client chooses
Supported clients: Firefox 63, Chrome 70, Edge 75, Safari 12.1 (on Mojave), iOS 12.2, Android 10.0 ("Q"), Java 11, OpenSSL 1.1.1
0x13,0x01 - TLS_AES_128_GCM_SHA256 TLSv1.3 Kx=any Au=any Enc=AESGCM(128) Mac=AEAD
0x13,0x02 - TLS_AES_256_GCM_SHA384 TLSv1.3 Kx=any Au=any Enc=AESGCM(256) Mac=AEAD
0x13,0x03 - TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any Au=any Enc=CHACHA20/POLY1305(256) Mac=AEAD
Ciphersuites: TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256
Protocols: TLS 1.2, TLS 1.3
TLS curves: X25519, prime256v1, secp384r1
Certificate: ECDSA (P-256, preferred) or RSA (2048-bits)
Cipher preference: Client chooses
DH Parameter size: 2048-bits (ffdhe2048, RFC 7919)
Supported clients: Firefox 27, Chrome 31, IE 11 (Win 7), Edge, Safari 9, Android 4.4.2, OpenSSL 1.0.1, Java 8u31
0x13,0x01 - TLS_AES_128_GCM_SHA256 TLSv1.3 Kx=any Au=any Enc=AESGCM(128) Mac=AEAD
0x13,0x02 - TLS_AES_256_GCM_SHA384 TLSv1.3 Kx=any Au=any Enc=AESGCM(256) Mac=AEAD
0x13,0x03 - TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any Au=any Enc=CHACHA20/POLY1305(256) Mac=AEAD
0xC0,0x2B - ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(128) Mac=AEAD
0xC0,0x2F - ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(128) Mac=AEAD
0xC0,0x2C - ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(256) Mac=AEAD
0xC0,0x30 - ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD
0xCC,0xA9 - ECDHE-ECDSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH Au=ECDSA Enc=CHACHA20/POLY1305(256) Mac=AEAD
0xCC,0xA8 - ECDHE-RSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH Au=RSA Enc=CHACHA20/POLY1305(256) Mac=AEAD
0x00,0x9E - DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(128) Mac=AEAD
0x00,0x9F - DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(256) Mac=AEAD
Ciphersuites: ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305:DHE-DSS-AES128-GCM-SHA256:DHE-DSS-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-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:DHE-DSS-AES128-SHA256:DHE-DSS-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:ECDHE-ECDSA-ARIA128-GCM-SHA256:ECDHE-ECDSA-ARIA256-GCM-SHA384:ECDHE-ARIA128-GCM-SHA256:ECDHE-ARIA256-GCM-SHA384:DHE-RSA-ARIA128-GCM-SHA256:DHE-DSS-ARIA128-GCM-SHA256:DHE-RSA-ARIA256-GCM-SHA384:DHE-DSS-ARIA256-GCM-SHA384:ECDHE-ECDSA-CAMELLIA128-SHA256:ECDHE-RSA-CAMELLIA128-SHA256:ECDHE-ECDSA-CAMELLIA256-SHA384:ECDHE-RSA-CAMELLIA256-SHA384:DHE-RSA-CAMELLIA128-SHA256:DHE-RSA-CAMELLIA256-SHA256:DHE-RSA-CAMELLIA128-SHA:DHE-RSA-CAMELLIA256-SHA:DHE-DSS-CAMELLIA128-SHA256:DHE-DSS-CAMELLIA256-SHA256:DHE-DSS-CAMELLIA128-SHA:DHE-DSS-CAMELLIA256-SHA:ARIA128-GCM-SHA256:ARIA256-GCM-SHA384:CAMELLIA128-SHA256:CAMELLIA256-SHA256:CAMELLIA128-SHA:CAMELLIA256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:DES-CBC3-SHA:DHE-RSA-SEED-SHA:DHE-DSS-SEED-SHA:SEED-SHA
Protocols: TLS 1.0, TLS 1.1, TLS 1.2, TLS 1.3
TLS curves: X25519, prime256v1, secp384r1
Certificate type: RSA (2048-bits)
Cipher preference: Server chooses
DH Parameter size: 1024-bits (custom generated)
Supported clients: Above, plus Java 6, Windows XP (IE 8)
0x13,0x01 - TLS_AES_128_GCM_SHA256 TLSv1.3 Kx=any Au=any Enc=AESGCM(128) Mac=AEAD
0x13,0x02 - TLS_AES_256_GCM_SHA384 TLSv1.3 Kx=any Au=any Enc=AESGCM(256) Mac=AEAD
0x13,0x03 - TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any Au=any Enc=CHACHA20/POLY1305(256) Mac=AEAD
0xC0,0x2B - ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(128) Mac=AEAD
0xC0,0x2F - ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(128) Mac=AEAD
0xC0,0x2C - ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(256) Mac=AEAD
0xC0,0x30 - ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD
0xCC,0xA9 - ECDHE-ECDSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH Au=ECDSA Enc=CHACHA20/POLY1305(256) Mac=AEAD
0xCC,0xA8 - ECDHE-RSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH Au=RSA Enc=CHACHA20/POLY1305(256) Mac=AEAD
0x00,0x9E - DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(128) Mac=AEAD
0x00,0x9F - DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(256) Mac=AEAD
0xCC,0xAA - DHE-RSA-CHACHA20-POLY1305 TLSv1.2 Kx=DH Au=RSA Enc=CHACHA20/POLY1305(256) Mac=AEAD
0x00,0xA2 - DHE-DSS-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=DSS Enc=AESGCM(128) Mac=AEAD
0x00,0xA3 - DHE-DSS-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=DSS Enc=AESGCM(256) Mac=AEAD
0xC0,0x23 - ECDHE-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(128) Mac=SHA256
0xC0,0x27 - ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA256
0xC0,0x09 - ECDHE-ECDSA-AES128-SHA TLSv1 Kx=ECDH Au=ECDSA Enc=AES(128) Mac=SHA1
0xC0,0x13 - ECDHE-RSA-AES128-SHA TLSv1 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA1
0xC0,0x24 - ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(256) Mac=SHA384
0xC0,0x28 - ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA384
0xC0,0x0A - ECDHE-ECDSA-AES256-SHA TLSv1 Kx=ECDH Au=ECDSA Enc=AES(256) Mac=SHA1
0xC0,0x14 - ECDHE-RSA-AES256-SHA TLSv1 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA1
0x00,0x67 - DHE-RSA-AES128-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(128) Mac=SHA256
0x00,0x33 - DHE-RSA-AES128-SHA SSLv3 Kx=DH Au=RSA Enc=AES(128) Mac=SHA1
0x00,0x6B - DHE-RSA-AES256-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(256) Mac=SHA256
0x00,0x39 - DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=SHA1
0x00,0x40 - DHE-DSS-AES128-SHA256 TLSv1.2 Kx=DH Au=DSS Enc=AES(128) Mac=SHA256
0x00,0x38 - DHE-DSS-AES256-SHA SSLv3 Kx=DH Au=DSS Enc=AES(256) Mac=SHA1
0x00,0x9C - AES128-GCM-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(128) Mac=AEAD
0x00,0x9D - AES256-GCM-SHA384 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(256) Mac=AEAD
0x00,0x3C - AES128-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA256
0x00,0x3D - AES256-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA256
0x00,0x2F - AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1
0x00,0x35 - AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1
0xC0,0x5C - ECDHE-ECDSA-ARIA128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=ARIAGCM(128) Mac=AEAD
0xC0,0x5D - ECDHE-ECDSA-ARIA256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=ARIAGCM(256) Mac=AEAD
0xC0,0x60 - ECDHE-ARIA128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=ARIAGCM(128) Mac=AEAD
0xC0,0x61 - ECDHE-ARIA256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=ARIAGCM(256) Mac=AEAD
0xC0,0x52 - DHE-RSA-ARIA128-GCM-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=ARIAGCM(128) Mac=AEAD
0xC0,0x56 - DHE-DSS-ARIA128-GCM-SHA256 TLSv1.2 Kx=DH Au=DSS Enc=ARIAGCM(128) Mac=AEAD
0xC0,0x53 - DHE-RSA-ARIA256-GCM-SHA384 TLSv1.2 Kx=DH Au=RSA Enc=ARIAGCM(256) Mac=AEAD
0xC0,0x57 - DHE-DSS-ARIA256-GCM-SHA384 TLSv1.2 Kx=DH Au=DSS Enc=ARIAGCM(256) Mac=AEAD
0xC0,0x72 - ECDHE-ECDSA-CAMELLIA128-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=Camellia(128) Mac=SHA256
0xC0,0x76 - ECDHE-RSA-CAMELLIA128-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=Camellia(128) Mac=SHA256
0xC0,0x73 - ECDHE-ECDSA-CAMELLIA256-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=Camellia(256) Mac=SHA384
0xC0,0x77 - ECDHE-RSA-CAMELLIA256-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=Camellia(256) Mac=SHA384
0x00,0xBE - DHE-RSA-CAMELLIA128-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=Camellia(128) Mac=SHA256
0x00,0xC4 - DHE-RSA-CAMELLIA256-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=Camellia(256) Mac=SHA256
0x00,0x45 - DHE-RSA-CAMELLIA128-SHA SSLv3 Kx=DH Au=RSA Enc=Camellia(128) Mac=SHA1
0x00,0x88 - DHE-RSA-CAMELLIA256-SHA SSLv3 Kx=DH Au=RSA Enc=Camellia(256) Mac=SHA1
0x00,0xBD - DHE-DSS-CAMELLIA128-SHA256 TLSv1.2 Kx=DH Au=DSS Enc=Camellia(128) Mac=SHA256
0x00,0xC3 - DHE-DSS-CAMELLIA256-SHA256 TLSv1.2 Kx=DH Au=DSS Enc=Camellia(256) Mac=SHA256
0x00,0x44 - DHE-DSS-CAMELLIA128-SHA SSLv3 Kx=DH Au=DSS Enc=Camellia(128) Mac=SHA1
0x00,0x87 - DHE-DSS-CAMELLIA256-SHA SSLv3 Kx=DH Au=DSS Enc=Camellia(256) Mac=SHA1
0xC0,0x50 - ARIA128-GCM-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=ARIAGCM(128) Mac=AEAD
0xC0,0x51 - ARIA256-GCM-SHA384 TLSv1.2 Kx=RSA Au=RSA Enc=ARIAGCM(256) Mac=AEAD
0x00,0xBA - CAMELLIA128-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=Camellia(128) Mac=SHA256
0x00,0xC0 - CAMELLIA256-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=Camellia(256) Mac=SHA256
0x00,0x41 - CAMELLIA128-SHA SSLv3 Kx=RSA Au=RSA Enc=Camellia(128) Mac=SHA1
0x00,0x84 - CAMELLIA256-SHA SSLv3 Kx=RSA Au=RSA Enc=Camellia(256) Mac=SHA1
0xC0,0x08 - ECDHE-ECDSA-DES-CBC3-SHA TLSv1 Kx=ECDH Au=ECDSA Enc=3DES(168) Mac=SHA1
0xC0,0x12 - ECDHE-RSA-DES-CBC3-SHA TLSv1 Kx=ECDH Au=RSA Enc=3DES(168) Mac=SHA1
0x00,0x16 - DHE-RSA-DES-CBC3-SHA SSLv3 Kx=DH Au=RSA Enc=3DES(168) Mac=SHA1
0x00,0x0A - DES-CBC3-SHA SSLv3 Kx=RSA Au=RSA Enc=3DES(168) Mac=SHA1
0x00,0x9A - DHE-RSA-SEED-SHA SSLv3 Kx=DH Au=RSA Enc=SEED(128) Mac=SHA1
0x00,0x99 - DHE-DSS-SEED-SHA SSLv3 Kx=DH Au=DSS Enc=SEED(128) Mac=SHA1
0x00,0x96 - SEED-SHA SSLv3 Kx=RSA Au=RSA Enc=SEED(128) Mac=SHA1
I can say r+, with a suggestion.
I think that it might be time to purge the Old ciphers a little more. I speak specifically of suites with DSS, ARIA, CAMELLIA, and SEED. I also see a couple more DES-CBC3 suites than is necessary. To my knowledge, the DES-CBC3-SHA suite (which corresponds to TLS_RSA_WITH_3DES_SHA if I'm right) is the only one you might need to allow very old TLS 1.0 and 1.1 clients to connect.
Then there is DHE-RSA-AES256-SHA and it's kin. These are technically PFS suites that work in SSLv3 (which is unnecessary), but they are so poorly supported that it really isn't worth the effort of listing them.
I guess if the goal is to include everything we know not to be busted, that's maybe justifiable, but we also should consider whether these things are getting any real attention any more. Offering to negotiate what is effectively abandonware is asking for trouble.
I could certainly see an argument for taking the old Intermediate and making that the new Old cipher list, minus a few, making it basically this:
0x13,0x01 - TLS_AES_128_GCM_SHA256 TLSv1.3 Kx=any Au=any Enc=AESGCM(128) Mac=AEAD
0x13,0x02 - TLS_AES_256_GCM_SHA384 TLSv1.3 Kx=any Au=any Enc=AESGCM(256) Mac=AEAD
0x13,0x03 - TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any Au=any Enc=CHACHA20/POLY1305(256) Mac=AEAD
0xC0,0x2B - ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(128) Mac=AEAD
0xC0,0x2F - ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(128) Mac=AEAD
0xC0,0x2C - ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(256) Mac=AEAD
0xC0,0x30 - ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(256) Mac=AEAD
0xCC,0xA9 - ECDHE-ECDSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH Au=ECDSA Enc=CHACHA20/POLY1305(256) Mac=AEAD
0xCC,0xA8 - ECDHE-RSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH Au=RSA Enc=CHACHA20/POLY1305(256) Mac=AEAD
0x00,0x9E - DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(128) Mac=AEAD
0x00,0x9F - DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(256) Mac=AEAD
0xCC,0xAA - DHE-RSA-CHACHA20-POLY1305 TLSv1.2 Kx=DH Au=RSA Enc=CHACHA20/POLY1305(256) Mac=AEAD
0xC0,0x23 - ECDHE-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(128) Mac=SHA256
0xC0,0x27 - ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA256
0xC0,0x09 - ECDHE-ECDSA-AES128-SHA TLSv1 Kx=ECDH Au=ECDSA Enc=AES(128) Mac=SHA1
0xC0,0x13 - ECDHE-RSA-AES128-SHA TLSv1 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA1
0xC0,0x24 - ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(256) Mac=SHA384
0xC0,0x28 - ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA384
0xC0,0x0A - ECDHE-ECDSA-AES256-SHA TLSv1 Kx=ECDH Au=ECDSA Enc=AES(256) Mac=SHA1
0xC0,0x14 - ECDHE-RSA-AES256-SHA TLSv1 Kx=ECDH Au=RSA Enc=AES(256) Mac=SHA1
0x00,0x67 - DHE-RSA-AES128-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(128) Mac=SHA256
0x00,0x6B - DHE-RSA-AES256-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(256) Mac=SHA256
0x00,0x9C - AES128-GCM-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(128) Mac=AEAD
0x00,0x9D - AES256-GCM-SHA384 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(256) Mac=AEAD
0x00,0x3C - AES128-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA256
0x00,0x3D - AES256-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA256
0x00,0x2F - AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1
0x00,0x35 - AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1
0x00,0x0A - DES-CBC3-SHA SSLv3 Kx=RSA Au=RSA Enc=3DES(168) Mac=SHA1
Which I think what you were getting at, right @martinthomson? I don't have any particular problems with this, other than not having a strong idea of who is using the Old cipher suite list.
If it's only Java 6 and Windows XP IE6, then it's probably great, but if there are weird old systems or systems in Japan/South Korea using Camellia/ARIA, it could break them. That was the initial rationale for the dizzyingly long list, but it might be worth revisiting that assumption. I can always send people to Server Side TLS 4.0 if they want even older systems.
Edit: Updated the list above
Brainstorming issue for changes planned for v5 of the guidelines. A few things should be discussed:
Removing 3DES from the intermediate level. Data shows that TLSv1 DES-CBC3-SHA represents 2.8% of traffic on mozilla.org, a site designed to receive old traffic. I think we can start moving this forward.
Removing DHE from the intermediate level, and keeping only one non-PFS ciphersuite: AES128-SHA.
Removing RSA from the modern guidelines. ECDSA should be the norm and enough clients support it: Firefox 27, Chrome 30, Edge 12, IE 11, Safari 5, Opera 17, Android 4.4.2, OpenSSL 1.0.1h and Java 8b132
Adding
X25519
to TLS curves on all levels. Maybe next year we'll have some certificate support 🙏Removing
secp521r1
from all TLS curves and certificates. It's never used and there's some concern about its security.Requiring the use of certificate authorities that issue CT logs, on all levels. This is new, the phrasing needs work, as do the testing tools, but it's an important requirement that I think we should add.
I'm wondering if we should require short lived certs and key rotation. 90 days max for modern level, 2 years for intermediate. This is going to annoy people, but the security benefit is there to support it.
Anything else I forgot?