Skip to content
New issue

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

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

Already on GitHub? Sign in to your account

Server Side TLS v5.0 #178

Closed
jvehent opened this issue Dec 27, 2016 · 103 comments

Comments

Projects
None yet
@jvehent
Copy link
Contributor

commented Dec 27, 2016

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?

@ekr

This comment has been minimized.

Copy link

commented Dec 27, 2016

  1. I think it's fine to remove 3DES
  2. I assume AES128-SHA is OpenSSL notation for TLS_RSA_AES_128_CBC_WITH_SHA? If so, why not TLS_RSA_WITH_AES_128_GCM_SHA256
  3. I don't think this is reasonable. To the best of our knowledge, RSA-2048 is a strong algorithm, it's just a lot slower than ECDSA. Plenty of sites still use RSA.
  4. I'm not opposed to Ed25519 certificates, but it's not clear how it makes things any better.
  5. What are those concerns about its security? I agree that P521 is unnecessary.

In general, you need to distinguish between the key in the certificate and the algorithm used to sign it.

I do not think you should add points 6 or 7. It's not clear how either provides significant security benefit for the server. Specifically, CT primarily provides security against misissuance by CAs other than your own, so having CT in your own cert doesn't get you much because the attacker can get a cert from any of the n-1 CAs. You could, of course, also do HPKP in which case there might be some incremental benefit, in that you could then ensure your own CA doesn't misissue (has this ever happened?). However, given that you don't recommend HPKP...

Similar reasoning applies to point 7. The primary benefit of short-lived certs for your site is if your key is compromised. Do we have data on how often that happens? I'm unaware of any evidence that server-side key rotation provides a security benefit. What's your reasoning for that? The restriction on intermediates seems to provide no benefit whatsoever. Two years is way too long to not require
actual revocation. I would also note that LE's intermediate expires in 2021, so this would ban LE.

@jcjones

This comment has been minimized.

Copy link

commented Dec 27, 2016

Speaking specifically to 6, the CT point: Rather than requiring the use of a CA that logs, it might be better to suggest that server operators register with a service that provides CT-logging notifications, such as crt.sh's atom feed, or similar -- the value they'd see out of CT would be unexpected issuance for their domain(s).

@ekr

This comment has been minimized.

Copy link

commented Dec 27, 2016

@jcjones Yes, I think that's a reasonable suggestion, though I would put it at a SHOULD level.

@mozfreddyb

This comment has been minimized.

Copy link

commented Dec 27, 2016

@jvehent I'm surprised we neither recommend nor require OCSP Stapling in any of the levels.

@ekr

This comment has been minimized.

Copy link

commented Dec 27, 2016

@mozfreddyb: I'm not against stapling but unless you have must staple (does anyone do that?) it's primarily a performance enhancement

@floatingatoll

This comment has been minimized.

Copy link

commented Dec 27, 2016

@ekr

This comment has been minimized.

Copy link

commented Dec 27, 2016

@floatingatoll: I'm not really following your reasoning here.

  1. For the foreseeable future, every client in the world will need to verify RSA certificates.
  2. As long as those clients support RSA, then having your server only support ECDSA doesn't clearly make your site more secure ("more sensitive sites") because the attacker can instead attack the RSA key of a CA, which is a higher value target.

Your last paragraph suggests that what you're trying to do is somehow improve the ecosystem by excluding old browsers; if so, this is an extremely inefficient way to do that, preclsely because any vaguely modern browser supports ECDSA, which means that support for ECDSA is not a useful signal for whether a browser is secure; lots of browsers with serious vulnerabilities will still be compatible with "modern". Firefox 50.0, for instance.

@floatingatoll

This comment has been minimized.

Copy link

commented Dec 27, 2016

@ekr

This comment has been minimized.

Copy link

commented Dec 27, 2016

1: Sure, but it's still important to encourage ECDSA adoption wherever
possible, right?

Why? This seems like something we can safely have no opinion on.

2: Either we should, or we should not, encourage sites to pursue ECDSA
rather than RSA for their site certificates.

Yes, I'm saying that we should take no position on this.

If we should, then there's no
reason to include RSA. If we shouldn't, then we should drop ECDSA from
Modern.

No, I don't think that this follows at all. Just as we can be ambivalent about GCM versus ChaCha we can be ambivalent about RSA versus ECDSA. What we should say is that ECDSA is much faster (which is true) and that there are old clients which don't support it (which is also true).

I think the former is more appropriate. Raising the bar for clients
is an important step, even if that bar cannot be raised far enough to solve
the problems you describe. We can't cure Firefox 50.0 or RSA intermediates
by raising the bar for Modern, but that's no reason to give up.

I'm not finding this particularly persuasive. If you want to force clients to be modern, start by checking user-agent. If you're not willing to do that, then I don't think you're actually serious about it, because ECDSA is not a useful proxy.

Generally, these guidelines are represented as being Mozilla's position and for that reason it's best to be conservative about how prescriptive we are. Otherwise we risk people claiming that "Mozilla says 'don't use RSA'" which we do not. It's particularly important to be conservative in cases where it's not clear there is any direct security benefit to the site, but there's some kind of amorphous ecosystem story. This is the same reason why I don't want to take a position on certificate lifetime.

@floatingatoll

This comment has been minimized.

Copy link

commented Dec 27, 2016

@ekr

This comment has been minimized.

Copy link

commented Dec 27, 2016

I note that Modern is advertised as
"For services that don't need backward compatibility, the parameters below provide a higher level of security.". But for the reasons I indicated above, ISTM that this is in fact not an obvious statement

@franziskuskiefer

This comment has been minimized.

Copy link
Member

commented Dec 28, 2016

Looking at [1] I'm wondering what ECDH Parameter size is supposed to do? It doesn't give you the security level and you'll have to adapt it for x25519.

I think modern should only have AEADs.

[1] https://wiki.mozilla.org/Security/Server_Side_TLS

@april

This comment has been minimized.

Copy link
Contributor

commented Dec 28, 2016

My personal opinion is that Modern should have only AEADs with EC key exchange. Essentially only ECDHE for key exchange, only ECDSA for authentication, only AES-GCM, AES-CCM and ChaCha20-Poly1305 for the symmetric-key encryption/MAC.

Rationalization:

  • DHE is too easy to mess up, leaving ECDHE as the only forward-secret form of key exchange
  • ECDSA has incredibly broad support, and by having ECDSA as our recommended certificate signature, we have in sort of de-facto eliminated RSA from use in Modern anyways over the last year or so. Sure, you can have both RSA and ECDSA certs, but:
    • Almost nobody knows how to do it
    • Our configuration generator doesn't do it automatically
    • I've been running my own site this way (ECDSA only) for quite a while now, and I've had no complaints except for a couple involving an extremely old browser (IE6?) which is nowhere close to modern anyways
  • AEADs are (complaints about GCM notwithstanding) a better construction and I think we should be pushing them.

I feel pretty strongly about ECDHE only, reasonably strongly about ECDSA only, and somewhat strongly about AEADs (recognizing that there is a decent amount of stuff out there without GCM support). If we are going to continue to allow RSA in Modern, we should update our configuration generator to show people how to set things up with RSA+ECDSA.

As for @jvehent's original post:

  1. I agree about removing 3DES from Intermediate. There aren't any known issues with it, but it isn't exactly getting a lot of scrutiny at this point and who knows if there are any boogeymen lying about. Old browsers that prefer/use 3DES aren't anywhere close to modern and are likely filled with security holes anyways.
  2. I agree about removing DHE; people continue to get it wrong and the ecosystem hasn't improved such that software is abstracting away the ability to screw it up.
  3. I agree about RSA (see above)
  4. I don't see any downside here with recommending x25519 for key exchange, but I don't think we're anywhere close to being able to recommend EdDSA certs.
  5. Agreed
  6. I agree, although I think it's very hard for administrators to know if this is happening. I don't know if it really belongs in the guidelines, simply because it's often far out of their control and it's hard for them to research (short of us making recommendations for CAs, which I think we should avoid)
  7. I think 90 days / 2 years is reasonable, but I would also be fine with 90 days / no recommendation, or continuing to not make recommendations as per @ekr. OCSP Stapling + OCSP Must Staple is a far better way to solve this problem, but until every browser supports both I think I can tentatively get behind a recommendation at least for in Modern.

@ekr:

The restriction on intermediates seems to provide no benefit whatsoever. Two years is way too long to not require actual revocation. I would also note that LE's intermediate expires in 2021, so this would ban LE.

@jvehent is referring to the intermediate recommendation level, not intermediate certificate authorities. :)

Anyways, bringing in @noncombatant, @agl, and @lgarron, since they've often had feedback on this in the past.

@ekr

This comment has been minimized.

Copy link

commented Dec 28, 2016

Once again, the issue isn't that I object to ECDSA. What I object to is the positioning that people shouldn't use RSA or that having an RSA certificate makes your site weaker. Do you have any evidence that that is in fact true?

The basic point is that there are two reasons why you might choose particular settings:

  1. It makes your site stronger.
  2. It has some ecosystem benefit.

These guidelines are clearly positioned as the former and that means that everything in them needs to be justifiable on that basis.

A few other points:

  1. I don't object to removing DHE.
  2. AFAIK no browser supports EdDSA signatures in certs. I know that neither Firefox nor Chrome does. So yeah we're not anywhere near close.
  3. There are actually known issues with 3DES. See: https://sweet32.info/
  4. AES-CCM? Does any browser support it? Neither Chrome nor Firefox does.
@april

This comment has been minimized.

Copy link
Contributor

commented Dec 28, 2016

Again, I have literally no problems with RSA certs: it's just that dual certs are reasonably complicated and so the vast majority sites do and will support either RSA or ECDSA but not both. We could leave it as-is, but we should cognizant that recommending either RSA or ECDSA certs essentially eliminates one or the other from being an authentication option.

I prefer recommending ECDSA certificates for Modern, simply because they have broad support and it allows for smaller certificates with faster handshakes. The recommendation for ECDSA certificates (as it already exists in Modern) removes RSA for non-dual-cert sites and having ECDHE-RSA in the cipher suite options really only serves the purpose of keeping sites from footgunning themselves when they get an RSA cert.

@april

This comment has been minimized.

Copy link
Contributor

commented Dec 28, 2016

AES-CCM? Does any browser support it? Neither Chrome nor Firefox does.

It made the cut for TLS 1.3, so I assume that support for it will come eventually, maybe. That said, I'm fine with leaving it as just AES-GCM and ChaCha20-Poly1305 until/if support does arrive.

@ekr

This comment has been minimized.

Copy link

commented Dec 28, 2016

It made the cut for TLS 1.3, so I assume that support for it will come eventually, maybe.

This is not a sound assumption. TLS 1.3 is for more than the Web and CCM is in wide use for IOT. To the best of my knowledge, no browser intends to implement CCM.

@april

This comment has been minimized.

Copy link
Contributor

commented Dec 28, 2016

IoT devices are exactly the sort of configuration that Modern is meant for, because there is no need for backwards compatibility with browsers. It's designed specifically for things like APIs and private services where you control the audience.

Given what modern targets and that CCM is widely used in IoT, it seems like it would make sense to support AES-CCM inside the modern configuration. Is there any downside to supporting it that I am unaware of?

@ekr

This comment has been minimized.

Copy link

commented Dec 28, 2016

"IoT devices are exactly the sort of configuration that Modern is meant for, because there is no need for backwards compatibility with browsers. It's designed specifically for things like APIs and private services where you control the audience."

If that's in fact the intent, then this document needs some serious rework, because that's not how it advertises itself at all:
"Three configurations are recommended. Pick the right configuration depending on your audience. If you do not need backward compatibility, and are building a service for modern clients only (post Firefox 27/Chrome 22), then use the Modern configuration."

"For services that don't need backward compatibility, the parameters below provide a higher level of security. This configuration is compatible with Firefox 27, Chrome 30, IE 11 on Windows 7, Edge, Opera 17, Safari 9, Android 5.0, and Java 8."

This seems clearly targeted at the Web and HTTPS. If you're trying to target IoT (which often isn't even HTTP and may in fact be CoAP) then you need an entirely different set of parameters. For instance, in many cases -- and I suspect but not know that these are similar cases to those where you want CCM -- these devices don't even have certificates but use PSK w/ or W/O (EC)DHE. With that said, I don't see why we would be making recommendations in that arena, given that that's not an arena where we have any particular expertise.

@april

This comment has been minimized.

Copy link
Contributor

commented Dec 28, 2016

If that is the case, perhaps it should be called Server Side HTTPS?

@lgarron

This comment has been minimized.

Copy link

commented Dec 29, 2016

Anyways, bringing in @noncombatant, @agl, and @lgarron, since they've often had feedback on this in the past.

I'm not an expert, but I agree with most of proposed suggestions. Pinging @davidben, who has a lot more experience with TLS compatibility and moving the ecosystem forward at the protocol level.

@jvehent

This comment has been minimized.

Copy link
Contributor Author

commented Dec 30, 2016

Following @jcjones's comment, I agree it's a good idea to recommend monitoring the CT logs.

@mozfreddyb : OCSP Stapling is more of something we say people should do at all times. It's detailed here: https://wiki.mozilla.org/Security/Server_Side_TLS#OCSP_Stapling Maybe we can make it more obvious somehow.

@franziskuskiefer: Should we replace the ECDH parameter size with required bits of security? Or discard it entirely?

Trying to summarize and reply to @ekr's concern:

  1. I assume AES128-SHA is OpenSSL notation for TLS_RSA_AES_128_CBC_WITH_SHA? If so, why not TLS_RSA_WITH_AES_128_GCM_SHA256

The goal of the intermediate level is to be compatible with a large amount of client while remaining reasonably safe. GCM, while safer than CBC, isn't supported by enough clients to fulfill that role entirely. We still need AES128-SHA for a while 😞.

What I object to is the positioning that people shouldn't use RSA or that having an RSA certificate makes your site weaker.

I agree with you on this, and the intend is not to say RSA is broken. It is to say that, all things being equal, ECDSA is faster and should be preferred by operators who care about implementing the modern level. Our recommendations aren't only about security, but also about performance, compatibility, etc. We tried to make the right choices for the operators who don't have time/knowledge to dig through these questions. I think it's important to start pushing ECDSA at the modern level today so early adopters adapt their tooling. A lot of scripts out there only know about RSA.

@ekr:

Generally, these guidelines are represented as being Mozilla's position and for that reason it's best to be conservative about how prescriptive we are.

The intermediate and old level are meant to be conservative. The modern level is not meant to be conservative, but experimental, and will break compatibility with a lot of clients. Removing RSA from the modern level seems like a reasonable way to say we believe the future of TLS will use ECDSA, not RSA. Do we not believe this?

The statement about modern providing higher security should be rephrased to say modern is a balance between security and performance at the cost of compatibility.

This seems clearly targeted at the Web and HTTPS.

It is, and while we may want to increase our coverage in the future, I don't think the compatibility matrix for IoT devices is understood nearly well enough for us to recommend anything here. Let's stick to what we know: browsers and web services.

And no, we're not changing the name :p

@franziskuskiefer

This comment has been minimized.

Copy link
Member

commented Dec 31, 2016

Should we replace the ECDH parameter size with required bits of security? Or discard it entirely?

The only information the group size gives you for ECDH is some indication on the speed of the curve (not a very strong one though). Stating #bits security the curve provides is probably what you want (this might also change over time). We should list that imo.
These numbers are not 100% accurate but good enough for judging security of a curve:

  • P256 and X25519: 128 bit security
  • P384: 192 bit security
  • P521 (if you still want to list it): 256
@zzq1015

This comment has been minimized.

Copy link

commented Jan 6, 2017

My opinion:

  1. Remove 3DES from the intermediate level. By the way, IE8 on WinXP supports AES128-SHA and AES256-SHA with the PosReady Hack.
  2. Disable DHE, keep AES128-GCM-SHA256 (it doesn't hurt) and AES128-SHA as the only two non-FS suite in the intermediate level.
  3. Remove HMAC-SHA2 (256/384) for AES_CBC from the intermediate level only. HMAC-SHA1 is secure enough and twice as fast as HMAC-SHA2. AES_CBC is flawed, and modern clients will use AES_GCM anyways, and there is no HMAC in AES_GCM.
  4. Do not remove RSA from the modern guidelines since very few CAs sign in ECDSA (Letsencrypt accepts EC keys but still signs in RSA).
  5. Encourage the use of dual-certificate (ECDSA and RSA at the same time). Currently Apache and NGINX have support for it.
  6. Add and prioritize X25519 in TLS curves on all levels. However, OpenSSL 1.1.0 only allows X25519 in ECDH but can't sign certificates with X25519 keys.
  7. Do not remove secp521r1. In fact, secp521r1 should be priorized before secp384r1 because the latter is slower in ECDH (in 64-bit CPU). If you want to make things simpler, secp384r1 would be the right thing to remove. By the way, I'm not aware of any specific attack against secp521r1. There are only concerns about NIST curves in general (backdoors and side-channel leaking).
  8. Require the use of certificate authorities that issue CT logs on all levels. Also, require CAs be able to sign "OCSP Must Staple" certificates and strongly recommend users to turn on OCSP stapling.
  9. Maximum lifespan for certificates: 180 days for the modern level and 2 years for intermediate level.
  10. ChaCha20 vs AES issue: the ideal way is to use ChaCha20 on CPUs without hardware support for AES, and use AES on those with hardware support (eg. Intel's AES-NI). However, OpenSSL does not support this configuration. For now, I suggest to put ChaCha20 first in intermediate level.
  11. Require server operators to turn on HSTS and enable preloading if possible.
  12. AES-CCM: Only enable it in the modern level. In OpenSSL 1.1.0, there is ECDHE-ECDSA-AES128-CCM, DHE-RSA-AES128-CCM, AES128-CCM, but no ECDHE-RSA-AES128-CCM, so it is pointless to add it to the intermediate level.
  13. Last but not the least: TLS 1.3

My ideal intermediate config:
ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES128-SHA
My ideal ECDH curve order:
X25519:prime256v1:secp521r1:secp384r1
(secp384r1 is optional)

@jrchamp

This comment has been minimized.

Copy link
Contributor

commented Jan 7, 2017

My votes:

  • Modern with EC only (ECDSA, ECDHE), preferring X25519.
  • Intermediate with TLSv1.2 and newer only, ECDHE PFS only, no SHA1 (most if not all clients with TLSv1.2 support have ECDHE and SHA2). Recommend Dual Certificates. 3072 RSA for 128-bit effective security.
@tomato42

This comment has been minimized.

Copy link
Member

commented Jan 23, 2017

  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.

yes, Sweet32 killed 3DES

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

I'm not sure about it, DHE is more resilient against quantum computer attacks than ECDHE and with RFC7919 the biggest obstacle to deploying big primes is gone.

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

I don't think we gain anything by doing that.

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

I think we should differentiate between stuff that's necessary to be qualified as meeting given security level and things allowed in the security level.

+1 for allowing X25519, -1 to requiring X25519

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

using it for certificates is a recipe for disaster (schannel incompatibility), I don't think the ECDHE use is a problem though (see above for required vs allowed)

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

that's something for Modern, Firefox can't check CSTs, so there's little point in requiring it for Intermediate...

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

RFC 7633 is a thing now, so I'm not sure if unconditional key rotation is a good idea...

@lgarron

This comment has been minimized.

Copy link

commented Jun 14, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Jun 14, 2019

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

@floatingatoll

This comment has been minimized.

Copy link

commented Jun 14, 2019

@april

This comment has been minimized.

Copy link
Contributor

commented Jun 26, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Jun 26, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Jun 26, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Jun 26, 2019

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

This comment has been minimized.

Copy link

commented Jun 26, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Jun 27, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Jun 27, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Jun 27, 2019

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

This comment has been minimized.

Copy link

commented Jun 27, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Jun 27, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Jun 27, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Jun 27, 2019

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

This comment has been minimized.

Copy link
Member

commented Jun 27, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Jun 27, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Jun 27, 2019

Edit: Updated the list above

@martinthomson

This comment has been minimized.

Copy link
Member

commented Jun 27, 2019

Yeah, the shorter list is much better.

I can always send people to Server Side TLS 4.0 if they want even older systems.

I would not do that proactively. It's enough to answer any questions that arise.

@april

This comment has been minimized.

Copy link
Contributor

commented Jun 28, 2019

Awesome, thanks! I’ll get this published tomorrow morning and then will publicize the changes on Monday. I really appreciate your feedback!

@april

This comment has been minimized.

Copy link
Contributor

commented Jun 28, 2019

This has been merged and published. It's been a tough 2.5 year slog, but thanks to everyone's hard work we have finally gotten there. I really appreciate it.

@april april closed this Jun 28, 2019

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