search

mozilla / server-side-tls

Server side TLS Tools
https://ssl-config.mozilla.org
Mozilla Public License 2.0
1.12k stars 158 forks source link

Server Side TLS v5.0 #178

Closed jvehent closed 5 years ago

jvehent commented 7 years ago

Brainstorming issue for changes planned for v5 of the guidelines. A few things should be discussed:

  1. 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.

  2. Removing DHE from the intermediate level, and keeping only one non-PFS ciphersuite: AES128-SHA.

  3. 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

  4. Adding X25519 to TLS curves on all levels. Maybe next year we'll have some certificate support 🙏

  5. Removing secp521r1 from all TLS curves and certificates. It's never used and there's some concern about its security.

  6. 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.

  7. 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?

april commented 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! :)

tomato42 commented 5 years ago

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

april commented 5 years ago

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).

tomato42 commented 5 years ago

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

april commented 5 years ago

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:

https://github.com/ssllabs/ssllabs-scan/issues/719

april commented 5 years ago

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.

tomato42 commented 5 years ago

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?

april commented 5 years ago

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.

tylerknott commented 5 years ago

@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.

april commented 5 years ago

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.

april commented 5 years ago

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

jvehent commented 5 years ago

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.

april commented 5 years ago

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.

ekr commented 5 years ago

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 .

april commented 5 years ago

That works for me. That would make this the final Intermediate cipher suite list:

april commented 5 years ago

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: 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

Intermediate:

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

Old

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!!)

ekr commented 5 years ago

I don't think it makes sense to recommend 384-bits for signing, for several reasons.

  1. The server has very little control of the signing algorithm.
  2. Given the relative strength of P-256 and P-384, there's no good reason to think that there are feasible attacks that would break P-256 and not P-384. For instance, a quantum computer would probably break both.
  3. It's actually more important in the face of a hypothetical break of EC to have a strong key establishment algorithm because such a break might be retrospective.
  4. The controlling factor in the security of the TLS connection against impersonation is not the strength of the server's cert but rather the strength of the weakest algorithm that's acceptable to clients. For instance, if clients support P-256, then the server having a P-384-signed cert doesn't add any value because the attacker will just attack P-256 (assuming it can) and impersonate the server.

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 .

tylerknott commented 5 years ago

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.

april commented 5 years ago

Perfect. I've updated the previous post to:

martinthomson commented 5 years ago

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.

ekr commented 5 years ago

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 .

april commented 5 years ago

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.

ekr commented 5 years ago

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?

april commented 5 years ago

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?

martinthomson commented 5 years ago

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.

april commented 5 years ago

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?

april commented 5 years ago

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.

april commented 5 years ago

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?

martinthomson commented 5 years ago

Yes, that would be better. Also, as a server, NSS only supports the 7919 groups.

april commented 5 years ago

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.

april commented 5 years ago

The new config generator now serves up the RFC 7919 group and includes instructions on how to use it. :)

april commented 5 years ago

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

lgarron commented 5 years ago

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

april commented 5 years ago

Not only is it allowed, but it's required. :)

floatingatoll commented 5 years ago

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 .

april commented 5 years ago

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.

april commented 5 years ago

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.

april commented 5 years ago

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?

synapt commented 5 years ago

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

ekr commented 5 years ago

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.

synapt commented 5 years ago

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.

april commented 5 years ago

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.

synapt commented 5 years ago

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)

tylerknott commented 5 years ago

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).

april commented 5 years ago

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.

synapt commented 5 years ago

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.

april commented 5 years ago

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!

Modern

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

Intermediate:

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

Old

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
martinthomson commented 5 years ago

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.

april commented 5 years ago

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.

april commented 5 years ago

Edit: Updated the list above