On Saturday 25 October 2014 14:26:59 Julien Vehent wrote: > Thank you Hubert from starting this discussion. I think this can be the > base for version 4 of the document. > > On 2014-10-20 08:10, Hubert Kario wrote: > > The items that probably should be changed or added: > > * curves weaker than secp256r1 - I think they shouldn't be > > > > enabled at all - while browsers do enable only the two or three > > NIST curves, clients that use OpenSSL enable also the rather weak > > 163 bit curve, making it possible to negotiate them (and as such > > limit the level of security to about 80 bit) > > I agree. The document currently recommends secp256r1, secp384r1 and > secp521r1. It would be good to have a more comprehensive list of curves, > and have another list of discarded curves in the "Mandatory discards" > section. The problem is being able to specify these curves in > configurations, which isn't widely supported in servers.
AFAIK, new versions of nginx do allow to set multiple curves. New apache can also be configured to use any curves supported by openssl automatically, but AFAIK, you can't disable use of specific ones, you can force it to use one specific curve though. For a high profile server, disabling all curves but P-256 (secp256r1) may be a better solution than leaving all curves available. But if you're running your server on Fedora or RHEL, where the only curves enabled are at least 256 bit long, the automatic mode is completely fine to leave on. (it's similar to using !ADH in cipher sting, if you're running 0.9.8, it's completely fine and safe, but if you're running 1.0.1 with ECC compiled in then you may leave AECDH ciphers enabled by mistake) > > * negotiation of curves in ECDHE - servers in general should > > > > be able to negotiate the used curve for this KEX - it's a RFC MUST > > Could you clarify what you mean by 'negotiate' ? Do you mean that > servers should implement configurable lists of supported curves? those are two related but different issues first is that server can support just one or a set of curves secondly, client does advertise in ClientHello a list of curves it supports, it's the elliptic_curves extension. Client there can say that it supports given curves, but not others (e.g. only the P-256, P-384 and P-521 NIST curves). Then the server knows that it can only select a curve from this set for ECDHE and can't select, e.g. P-224 even though it is faster. But what if a server assumes that all clients that support ECDHE also support NIST P-256 curve? Then it may also decide to support only P-256. That's not a problem, but only as long as it will detect clients that don't support P-256 and downgrade to a non-ECDHE connection in such case. Some servers can't do this downgrade and just abort connection. Some will just force the P-256 on client in such a situation. Both are bugs. > > * lack of secp256r1 intolerance - servers that hardcode this > > > > curve may ignore the tls extension completely, causing the > > > > connection > > > > to fail if the client doesn't support this curve (the server > > > > should > > > > choose a cipher that doesn't require ECC in such case) > > This is the same problem we have with 2048 DHE parameters and Java 6, > where the client fails the handshake instead of falling back to a > non-DHE cipher. In this situation, I believe that the role of the guide > is to inform operators on the issue and what configuration they should > pick. > > Servers should patch their TLS stacks, but that's hardly something we > can address in the wiki... > but unlike with DHE, this time the client *does* inform the server that it won't be able to process KEX that uses curves other than what it advertises. If the server still selects such a curve, it's a bug in server. And in such a case, the server (temporarily) should be configured to support curve(s) that give the biggest client coverage but, at the same time, it should be reported, fixed and later deployed. If a server administrator doesn't know that his servers are broken, he won't fix them. Sure, the process is more complex that fixing the cipher sting, but it still is doable. > > * SHA1 signing of (EC)DHE in TLSv1.2 - there's a bug in OpenSSL that > > > > causes the SNI certificate selection to not copy acceptable > > > > signature > > > > algs properly, this causes it to sign the key exchange using SHA1. > > Some servers may just hardcode the sig alg, which would be just as > > > > bad > > That is also a server problem. What do you propose we add to the > document to address this? The guide should be extended to information on how to detect that, and note that it requires a patch from the vendor to fix (and that you need to test every SNI host separately, not for just that bug but in general). > > * SHA-384 and SHA-512 signatures in certs - in current version > > > > they are not acceptable - as they are stronger, I think they > > > > should > > > > be added as acceptable (but maybe marked as not recommended). > > SHA-224 should probably be explicitly marked as non recommended as > > it is not supported in some libraries that do support SHA-256 and > > greater (very old NSS had this issue) > > I'm not against, modulo verification that these signatures work with > all the intended clients described in "Oldest compatible client" of each > level. We should also list the clients that are not compatible. (the intermediate CA certificates deployed in Universal SSL by Cloudflare are signed with SHA-384) I haven't heard of any client that can process SHA-256 but can't manage SHA-384 or SHA-512 in signatures... > I wonder if this is really useful though. Server Side TLS is a > pragmatic guide, and pragmatism dictates that operators should use > SHA-256 certs, not SHA-384 or SHA-512. When asked to review a production > site that runs a SHA-512 cert, I would recommend the admins to downgrade > to SHA-256 to prevent unknown behavior with unknown clients. Yes, I think it should advise against, but I don't think it should deny them. Problem is that some intermediate CAs are signed with SHA-384 or SHA-512. That is not really fixable, short of changing the CA you're using... Moreover, some roots use P-384 curve, I'd say that using *anything but* SHA-384 with this curve is bad practice... > > * ECDSA certs (and prioritisation of ECDSA above RSA) - there's no > > > > mention of those, and since we suggest PFS over non-PFS and > > ECDHE-ECDSA is over twice as fast as ECDHE-RSA[1], I think we > > definitely should allow (if not recommend) its use > > Same comment as above: we first need to evaluate compatibility of > clients. > Having ECDSA in the recommended ciphersuites has no site effect on > server compatibility. But recommending ECDSA certificates does have > strong side effects. There is a bug in older Safari (around OSX10.8, I think) which makes it not interoperable with all other implementations of ECDSA. > Do you know of certificate authorities that issue ECDSA certs? As Rob mentioned, Comodo and Symantec do. In this month's scan I found over 20 thousand chains that had their certificates signed using ECDSA. > > * intolerance of TLS1.3 ClientHello - new version is incoming > > > > while a significant percentage of servers can't do TLS version > > negotiation properly > > Let's leave this aside for now. TLS1.3 will not be implemented for many > more months, and we don't know much about its structure yet. I don't > want to confuse operators with recommendations that don't map to > anything yet. It's a bug in software/hardware they're using, even if it isn't urgent it still should be fixed. > > While most of those items may become issues only in future, I think > > it's better to point to them now, so that the number of > > servers that have bad configurations/bugs is limited. As such, > > it will also limit the need for clients to do the TLS downgrade > > dance. > > I never envisioned Server Side TLS as an implementation guide. I always > thought of it as an operation guide. Many of your comments imply that we > need a modern and reliable TLS implementation guide for servers, which I > agree with, but maybe that should be a separate document that can dive > into sample code and coding guidelines? A user needs to have a tool to be able to properly assess the correctness of the software/hardware it is running. While I mentioned some of bugs specific to OpenSSL, similar issues may exist in other libraries or appliances. Looking at scan statistics, it looks like a significant number of servers are configured, deployed and then forgotten (with the exception of occasional certificate update). If we cause the buggy servers to not be deployed in the first place, that will make the web better (see also: TLS_FALLBACK_SCSV). > Even better, something similar to the Configuration Generator, but for > code: http://mozilla.github.io/server-side-tls/ssl-config-generator/ In Fedora we're working on Defensive Coding guideline that includes some of this: http://docs.fedoraproject.org/en-US/Fedora_Security_Team/html/Defensive_Coding/chap-Defensive_Coding-TLS.html But it's one thing to detect and verify it was fixed, other is actually fixing bugs in code. > I agree that we need to cover more of TLS, but we also must keep the > guidelines focused on what operators need to know and can use quickly. I'd say that informing the operator that the stack they're running is buggy is in focus of the guide. Deploying TLS1.2 or AES-GCM may as well require software or hardware upgrade. Just like the above issues. Any RFC compliant implementation will have no problem passing those tests. -- Regards, Hubert Kario -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
