Server Side TLS v5.0 #178
Comments
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 |
|
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). |
|
@jcjones Yes, I think that's a reasonable suggestion, though I would put it at a SHOULD level. |
|
@jvehent I'm surprised we neither recommend nor require OCSP Stapling in any of the levels. |
|
@mozfreddyb: I'm not against stapling but unless you have must staple (does anyone do that?) it's primarily a performance enhancement |
|
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.
|
|
@floatingatoll: I'm not really following your reasoning here.
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. |
|
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.)
- R.
…On Tue, Dec 27, 2016 at 13:48 ekr ***@***.***> 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
<#178 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAFqDFDm_BYntB1ZpTi0PdMeWlPPAWE4ks5rMYeUgaJpZM4LWRi1>
.
|
Why? This seems like something we can safely have no opinion on.
Yes, I'm saying that we should take no position on this.
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'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. |
|
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.
|
|
I note that Modern is advertised as |
|
Looking at [1] I'm wondering what I think modern should only have AEADs. |
|
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:
@ekr:
@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. |
|
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:
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:
|
|
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. |
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. |
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. |
|
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? |
|
"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: "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. |
|
If that is the case, perhaps it should be called Server Side HTTPS? |
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. |
|
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 Trying to summarize and reply to @ekr's concern:
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 😞.
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:
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.
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 |
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.
|
|
My opinion:
My ideal intermediate config: |
|
My votes:
|
yes, Sweet32 killed 3DES
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.
I don't think we gain anything by doing that.
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
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)
that's something for Modern, Firefox can't check CSTs, so there's little point in requiring it for Intermediate...
RFC 7633 is a thing now, so I'm not sure if unconditional key rotation is a good idea... |
|
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: GitHub does strip a lot of the formatting away, so don't be alarmed by weird formatting or missing images. |
|
Thanks for everyone who has reviewed the updated guidelines so far, it's been very helpful. Barring any objections, I plan on merging this Friday, as it's mostly a reflection of the decisions already reviewed in this thread. |
|
One question that was brought up was, given the set of cipher suites in Intermediate: Does it make sense to let the client choose which cipher suite gets used? Obviously for the Old configuration, it makes sense to force them onto the most secure cipher suite. But for Intermediate, is it still necessary to allow the server to choose? |
|
I feel like there should have been more audibly public acknowledgement in making modern be TLS 1.3 only. Personally I'm of a preference of 1.3 + 1.2 w/ GCM rollout (over ECDSA works better because as noted earlier you cover Win7 and Win8 also since microsoft in all their brilliance decided to only implement ECDSA GCM and not RSA GCM in those two cryptolib versions). With that said I'm still kind of a fan of server-impressed cipher order if anything due to the community concerns and personal preferences of AES-128 over AES-256 from the much-debated key-weakness concerns (however still topical enough that some client software prioritize 128-bit over 256-bit such as Firefox and Chrome for example). But yeah with all the people that sorta make use of the mozilla ssl-generator tool without really understanding the concepts of everything, making modern TLS 1.3 only isn't a good model yet imo. Also is the actual cipher string supposed to be missing for the modern configuration? The cipher relative directive in the config examples are empty for the modern option and that might lead to errors in config loading.
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; |
FWIW, we prefer AES-128 for performance reasons. primarily. |
Yeah I was gonna mention that too but usually it ends up with "Meh it's negligible" replies so figured I'd just stick with the current security standings lol But yeah the performance concerns (especially on mobile hardware or hardware w/out AES-NI capacity) are definitely notable. At least not counting things like Chrome which default to ChaChaPoly usually in those events. |
|
Modern was always intended to be aspirational, when you have control over both the clients and endpoints. There is literally nothing wrong with using the Intermediate configuration: it’s very close to the old Modern configuration and any loosening of Modern would basically make it into Intermediate anyways. It is exactly what you describe: TLS 1.3 + TLS 1.2/FS/AEADs. And yes, with TLS 1.3 most software chooses not to allow the ordering of cipher suites, which is largely controlled by a global OpenSSL configuration file that almost nobody touches. I had chosen AES-256 over AES-128 since that had been the preferences in this thread. It seems like a good compromise would be letting the client choose in Intermediate, and preferring AES-128 over AES-256 in Old (which is generally done already). I really like the idea of letting the client choosing the most performant algorithm in a world where all the options are secure. |
|
Well yeah no I wasn't arguing against the intermediate necessarily being used, just that the less tech-ept people are gonna probably go "Oh I better be modern in this day and age of scary hackers" and then wonder why they're lacking a lot of traffic or getting complaints lol. Maybe my years of dealing with VPS's setup by people going with no knowledge going by what "Guides instruct them" may be jading my views though. As for TLS 1.3 and cipher order, that was (at least at the time discussed in ##openssl on freenode) a bug with OpenSSL, one that oddly still doesn't seem to be fixed w/ 1.1.1c. I'll see if I can dig up the conversation about it or a bug entry in relation to this. As for AES-256 over 128 as 'security over performance', is there a concern you have with AES 128 I'm not familiar with? Like noted earlier there are actual active security concerns with AES-256, the most I can think of in relation to AES-128 are people worrying about it w/ the evolution of 'quantum computing'. Is that the reason for preference? At the very least I feel like the directive should be left in the config examples w/ commentary perhaps. That said, in relation to Intermediate, you should be able to actually drop DHE completely and still keep the specified browser support in the sub-label (see one of my example setups; just ignore the CBC stuff still floating at the bottom) |
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). |
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 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. |
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/ 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
True, I guess I'm just getting too used to having to stupid-proof documentation for people lately lol. But I wouldn't necessarily say immediately obvious to tech-inept people, but yeah. I guess time will tell, still feel like making TLS 1.3 a default modern model only is speeding things along a little -too- quickly, but then again a lot of historical security issues was because of slow adoption so perhaps this isn't the worst of motivations. |
|
A reposting of the final proposal, given the comments above. If I can get some r+ on this from @ekr, @martinthomson, or @jvehent, I'd be happy to get this shipped. Thanks everyone! ModernCiphersuites: Intermediate:Ciphersuites: OldCiphersuites: |
|
I can say r+, with a suggestion. I think that it might be time to purge the Old ciphers a little more. I speak specifically of suites with DSS, ARIA, CAMELLIA, and SEED. I also see a couple more DES-CBC3 suites than is necessary. To my knowledge, the DES-CBC3-SHA suite (which corresponds to TLS_RSA_WITH_3DES_SHA if I'm right) is the only one you might need to allow very old TLS 1.0 and 1.1 clients to connect. Then there is DHE-RSA-AES256-SHA and it's kin. These are technically PFS suites that work in SSLv3 (which is unnecessary), but they are so poorly supported that it really isn't worth the effort of listing them. I guess if the goal is to include everything we know not to be busted, that's maybe justifiable, but we also should consider whether these things are getting any real attention any more. Offering to negotiate what is effectively abandonware is asking for trouble. |
|
I could certainly see an argument for taking the old Intermediate and making that the new Old cipher list, minus a few, making it basically this: Which I think what you were getting at, right @martinthomson? I don't have any particular problems with this, other than not having a strong idea of who is using the Old cipher suite list. If it's only Java 6 and Windows XP IE6, then it's probably great, but if there are weird old systems or systems in Japan/South Korea using Camellia/ARIA, it could break them. That was the initial rationale for the dizzyingly long list, but it might be worth revisiting that assumption. I can always send people to Server Side TLS 4.0 if they want even older systems. |
|
Edit: Updated the list above |
|
Yeah, the shorter list is much better.
I would not do that proactively. It's enough to answer any questions that arise. |
|
Awesome, thanks! I’ll get this published tomorrow morning and then will publicize the changes on Monday. I really appreciate your feedback! |
|
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 why ecdsa and not ed25519? |
|
It's impossible to do so, that's why. There aren't any CAs that issue Ed25519 certificates. |
Brainstorming issue for changes planned for v5 of the guidelines. A few things should be discussed:
Removing 3DES from the intermediate level. Data shows that TLSv1 DES-CBC3-SHA represents 2.8% of traffic on mozilla.org, a site designed to receive old traffic. I think we can start moving this forward.
Removing DHE from the intermediate level, and keeping only one non-PFS ciphersuite: AES128-SHA.
Removing RSA from the modern guidelines. ECDSA should be the norm and enough clients support it: Firefox 27, Chrome 30, Edge 12, IE 11, Safari 5, Opera 17, Android 4.4.2, OpenSSL 1.0.1h and Java 8b132
Adding
X25519to TLS curves on all levels. Maybe next year we'll have some certificate support 🙏Removing
secp521r1from all TLS curves and certificates. It's never used and there's some concern about its security.Requiring the use of certificate authorities that issue CT logs, on all levels. This is new, the phrasing needs work, as do the testing tools, but it's an important requirement that I think we should add.
I'm wondering if we should require short lived certs and key rotation. 90 days max for modern level, 2 years for intermediate. This is going to annoy people, but the security benefit is there to support it.
Anything else I forgot?
The text was updated successfully, but these errors were encountered: