search

mozilla / server-side-tls

Server side TLS Tools
https://ssl-config.mozilla.org
Mozilla Public License 2.0
1.12k stars 142 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?

ekr commented 7 years ago
  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 commented 7 years ago

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

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

mozfreddyb commented 7 years ago

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

ekr commented 7 years ago

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

floatingatoll commented 7 years ago

To point 3:

Removing RSA from Modern v5 encourages site owners that wish to remain Modern to generate, sign, and serve ECDSA certificates for their site.

The Modern guidelines are meant to describe "encryption for modern browsers only". If all modern browsers support ECDSA, then there is no further need for the guidelines to include RSA at all.

Admins who pursue Modern for their own sites would indeed exclude non-ECDSA browsers when upgrading to an RSA-free Modern v5, but that's a conscious choice accepted when using Modern (strict) rather than Intermediate (compatible).

Note that Mozilla applies Intermediate, not Modern, to the public production sites we operate that need to remain accessible to older clients. We should enhance them with ECDSA alongside RSA certificates, but it is fully expected that we'll continue operating them under Intermediate for the foreseeable future.

A few of our more sensitive sites, however, are set up as Modern, to force the use of current browsers with proper TLS configs. If we upgraded to Modern v5 and one of our users reported they were no longer able to access those sites, we could consider this a successful upgrade.

ekr commented 7 years ago

@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 commented 7 years ago

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

2: Either we should, or we should not, encourage sites to pursue ECDSA rather than RSA for their site certificates. If we should, then there's no reason to include RSA. If we shouldn't, then we should drop ECDSA from Modern. 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. (If there are reasons why ECDSA is an inappropriate replacement for RSA, then that would be a very good reason not to do so.)

On Tue, Dec 27, 2016 at 13:48 ekr notifications@github.com wrote:

@floatingatoll https://github.com/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.

— 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#issuecomment-269387306, or mute the thread https://github.com/notifications/unsubscribe-auth/AAFqDFDm_BYntB1ZpTi0PdMeWlPPAWE4ks5rMYeUgaJpZM4LWRi1 .

ekr commented 7 years ago

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

I support your concerns about messaging around this, whichever way it ends up going.

If we end up removing RSA from Modern - and in general, regardless - we should make sure the guidelines are very clear about Mozilla saying "Modern performs best when compatibility isn't a requirement", and NOT saying e.g. "Modern is the Mozilla way". Modern would break the web for a tremendous number of users today, and it's critical that it is not conveyed as "better" than Intermediate as a blanket statement.

ekr commented 7 years ago

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

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

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:

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

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

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

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

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

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

"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 commented 7 years ago

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

lgarron commented 7 years ago

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

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

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:

zzq1015 commented 7 years ago

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

My votes:

tomato42 commented 7 years ago
  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...

jvehent commented 7 years ago

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.

If and when quantum computers become a threat, I'm happy to reintroduce DHE.

  1. Removing RSA from the modern guidelines.

The consensus in this discussion is to keep RSA in the modern guidelines.

ekr commented 7 years ago

If and when quantum computers become a threat, I'm happy to reintroduce DHE.

I don't generally consider this a particularly strong argument for FFDHE, but this seems to be the wrong threat model: a QC is a threat to the confidentiality of traffic that happened before, so if you want your communications to be protected from a future QC, you need to be using quantum resistant key establishment now.

jvehent commented 7 years ago

Fair point. Still, my experience working from the operational side is misconfiguring DHE is a greater threat to the security of TLS than quantum computers.

tomato42 commented 7 years ago

Fair point. Still, my experience working from the operational side is misconfiguring DHE is a greater threat to the security of TLS than quantum computers.

I agree, but the point of this guideline is to say what is allowed for particular levels. And if your threat model includes QC, you need to use FFDH with large primes.

jvehent commented 7 years ago

The guidelines are meant to help the average sysadmins configure their servers. To do that we need to keep things relatively simple, including the threat model.

My take is that organizations that have QC in their threat model will need more than the baseline we give them here, and trying to address it here adds complexity for the other 99.9%.

ekr commented 7 years ago

I basically agree with @jvehent here, especially as the server would have to select FFDHE, which servers aren't going to. My comment above was merely oriented towards correctness.

tomato42 commented 6 years ago

another counter argument in favour of FFDHE is that it is impossible to misconfigure it in TLS 1.3 - any and all key shares must be part of groups defined in RFC 7919

april commented 5 years ago

Okay, I'd really like to get this out the door so that I can ship our new configuration generator:

https://mozilla.github.io/ssl-config-generator/

In my discussions with @jvehent, I think these were the changes:

All Configurations

• Protocols: Add TLS 1.3 • Curves: Add x25519, remove secp521r1 • HSTS: Update to 63072000 seconds (two years) • OCSP Stapling: Enabled by default • HPKP: Remove

Modern

• Protocols: Remove TLS 1.2

Intermediate

• Protocols: Remove TLS 1.0 and TLS 1.1 • Certificate type: ECDSA or RSA

Old

• Protocols: Remove SSL 3.0

Open questions:

• Can we remove 3DES from intermediate? • Can we remove DHE from intermediate? (the new generator makes this a bit more foolproof) • Can we remove non-PFS cipher suites (e.g. AES128-SHA256) from intermediate? • Can we remove certificate switching (SHA-1) from old?

I'm hoping to get this done by the end of the month, so if @jvehent, @ekr, @franziskuskiefer, @jcjones, @martinthomson or anybody has any opinions then please share them now.

jvehent commented 5 years ago

• Can we remove certificate switching (SHA-1) from old?

Yes. This technique was a hack to help transition to a non-sha1 world, but I haven't seen a strong adoption of it anywhere, so let's remove it from the general public guidelines.

alex commented 5 years ago

I don't think it makes sense to remove TLS 1.2 from Modern, unless the expectation is very few people would ever deploy modern. I think it'd make more sense for Modern to be TLS 1.2/1.3 with exclusively AEAD+FS suites.

jvehent commented 5 years ago

the expectation is very much that few people will ever deploy modern, and those people are willing to support only a subset of clients. modern is meant to break things but pave the way forward. a popular public service should use the intermediate level.

alex commented 5 years ago

TLS 1.3 only would be working as intended then! Cheers

On Mon, May 20, 2019 at 6:50 PM Julien Vehent [:ulfr] < notifications@github.com> wrote:

the expectation is very much that few people will ever deploy modern, and those people are willing to support only a subset of clients. modern is meant to break things but pave the way forward. a popular public service should use the intermediate level.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/mozilla/server-side-tls/issues/178?email_source=notifications&email_token=AAAAGBHKXUION2GHRU4O6M3PWMTNFA5CNFSM4C2ZDC22YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODV2IZYQ#issuecomment-494177506, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAAGBAHAZF2XCBPGRQLXCLPWMTNFANCNFSM4C2ZDC2Q .

-- All that is necessary for evil to succeed is for good people to do nothing.

titanous commented 5 years ago

Can we remove certificate switching (SHA-1) from old?

Definite yes, SHA-1 certificates haven't been available for quite a while now.

eternaltyro commented 5 years ago

the expectation is very much that few people will ever deploy modern, and those people are willing to support only a subset of clients. modern is meant to break things but pave the way forward. a popular public service should use the intermediate level.

Oh, no, no, no. That is not what server admins (like me) or people up top (like my boss's boss's boss) think at all. There's no indication (apart from the list of browser versions supported) that Modern suites will break compatibility. That's a bad assumption to make and the expectation that intermediate cert is what people ought to adopt isn't very ~clear~ obvious from the phrasing.

SSL test sites and countless other server admins would agree with me, I think.

Edit: That reads rude. What I'm trying to say is that it's comforting for engineers to show that they have modern config in place to upper management and that "the expectation" that people need intermediate is not set in an obvious way.

jvehent commented 5 years ago

The guidelines explicitly state that modern level is not for backward compatibility. 4 years ago, when it was added to the guidelines, It only listed TLS1.2 when few clients supported it. It seems natural to me that it would only support TLS1.3 today.

I don't think we can have modern TLS and comfort upper management at the same time. The intermediate level is better suited for this, because it is the default, and it states: For services that don't need compatibility with legacy clients (mostly WinXP), but still need to support a wide range of clients, this configuration is recommended. It is is compatible with Firefox 1, Chrome 1, IE 7, Opera 5 and Safari 1.

tomato42 commented 5 years ago

@eternaltyro

that Modern suites will break compatibility.

every cipherstring that doesn't enable absolutely everything and all protocols down to SSLv2 will break compatibility with some clients

the question is what clients are you ok breaking compatibility with

regarding TLS 1.2 in modern: I'm a bit on a fence; on one hand, TLS 1.2 with modern ciphers and legacy stuff removed (MD5 and SHA1 signatures) is on-par with TLS 1.3; on the other hand, if modern really is supposed to be the "future so bright you gotta wear shades", then TLS 1.2 could be dropped from it without making the server effectively unreachable (as both Firefox and Chrome do support it, as does all of the system tooling on modern distros like RHEL-8)

tomato42 commented 5 years ago

• Can we remove 3DES from intermediate?

I'd say so, the only reason was WinXP, and the last version of it finally reached EOL this year

• Can we remove DHE from intermediate? (the new generator makes this a bit more foolproof) • Can we remove non-PFS cipher suites (e.g. AES128-SHA256) from intermediate?

those two are related, as not all clients can do ECDHE and DHE with good parameters is definitely much better than RSA key exchange

april commented 5 years ago

Okay, on the currently outstanding questions here is what my plan is:

• Remove 3DES from intermediate • Leave DHE in intermediate • Remove non-PFS ciphers from intermediate

@jvehent, what did you use to generate the compatibility lists? Did you write a custom thing to use the SSL Labs client capabilities list?

april commented 5 years ago

I should add that this is a notice for people to speak up. 😄

Should I not get any refutations that is what I will go with starting from when I get back from Memorial Day on the 28th.

martinthomson commented 5 years ago

This general direction is fine.

I would recommend removing DHE from intermediate. DHE is hard to get right, and RFC 7919 is not agreed to be the solution.

Setting modern at TLS 1.3 is good. TLS 1.3 is widely supported in updated client software, so the main risk is for outdated client software and specialized clients that are built to less mainstream TLS stacks. Thus, while there is a compatibility risk with cutting TLS 1.2, that is done with the understanding that there are a (small) subset of clients that would be excluded.

@jvehent, you should probably update that notice about backward compatibility. I don't know what the cutoff would be for TLS 1.3, but WinXP isn't it. Clients will be much more modern than version 1 browsers, but the protocol has been in use for a while.

jvehent commented 5 years ago

@jvehent, you should probably update that notice about backward compatibility. I don't know what the cutoff would be for TLS 1.3, but WinXP isn't it. Clients will be much more modern than version 1 browsers, but the protocol has been in use for a while.

Absolutely, the compatibility list for each level needs to be updated, which ties into @April's question:

@jvehent, what did you use to generate the compatibility lists? Did you write a custom thing to use the SSL Labs client capabilities list?

It's been a while, but I'm pretty sure this was done by hand, before SSLLabs published its compatibility list in JSON. It could probably be automated now.

april commented 5 years ago

Okay, I'll get to writing that code then. It should help me see what the support would be and that might influence whether we end up supporting DHE/RSA-RSA.

That does beg the question of whether we should continue doing things in the current way forever.

I absolutely think we should have a new generator, which is here for those who haven't tried it: https://mozilla.github.io/ssl-config-generator/

But that said, is having this approach the right approach for the future? We do have the JSON file from SSL Labs, so maybe some future generator should ask for minimum client versions and then generate the minimal configuration necessary to support it? Anyways, something to think about and not necessarily important to this.

tomato42 commented 5 years ago

actually I have a script that translates the ssllabs json to tlsfuzzer test cases: https://github.com/tomato42/tlsfuzzer/blob/master/scripts/test-client-compatibility.py is a result so you can run those handshakes against a real server

But that said, is having this approach the right approach for the future? We do have the JSON file from SSL Labs, so maybe some future generator should ask for minimum client versions and then generate the minimal configuration necessary to support it? Anyways, something to think about and not necessarily important to this.

I'd say that yes, we should continue doing that, this is supposed to be the guidance and recommended list

tomato42 commented 5 years ago

the code for the generator is in this branch, but I haven't run it since last year, so it might have bit-rotted a bit: https://github.com/tomato42/tlsfuzzer/tree/ssllabs-generator (its utils/ssllabs-clients-parser.py it takes one argument, the json file from ssllabs)