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

V4: updated levels, added JSON #97

Merged
merged 2 commits into from Feb 11, 2016

Conversation

Projects
None yet
7 participants
@jvehent
Contributor

jvehent commented Nov 2, 2015

@marumari @gdestuynder : ping to review the new recommended configurations
@gene1wood : ping to review the provided JSON file, with a goal to use it as a source for the conf generator

Not yet ready to merge, fixing the config generator, and deciding on ecdsa for modern certs.

@gdestuynder

This comment has been minimized.

Contributor

gdestuynder commented Nov 2, 2015

r+

@jvehent

This comment has been minimized.

Contributor

jvehent commented Nov 18, 2015

Work in progress, I'm trying to modify the generator to use the json file, and so far failing.

@april

This comment has been minimized.

Contributor

april commented Nov 18, 2015

I think it's wrong that DHE_RSA_WITH_AES_256_GCM_SHA384 is in the intermediate section, particularly since DHE_RSA_WITH_AES_128_GCM_SHA256 is considered modern?

@jvehent

This comment has been minimized.

Contributor

jvehent commented Nov 19, 2015

@marumari : I'm confused. DHE-RSA-AES256-GCM-SHA384 is only present in the old configuration right now. It's not in intermediate or modern. It probably should be in intermediate.

On another note: I'm tempted to remove DHE from modern entirely. Thoughts?

@tomato42

This comment has been minimized.

Member

tomato42 commented Nov 19, 2015

@april

This comment has been minimized.

Contributor

april commented Nov 19, 2015

In the current version of the site, it's present in Modern (@ #8). And I haven't seen any good reason why DHE shouldn't be offered alongside ECDHE, except for performance.

@tomato42

This comment has been minimized.

Member

tomato42 commented Nov 20, 2015

There's one more problem, as discussed in mozilla/cipherscan#106 (comment)

Let's consider a server which can support just one certificate (e.g. nginx). Do we recommend to administrators to stay with a RSA certificate or do we recommend them to migrate to ECDSA certificate and drop RSA support completely?

What about servers that can handle multiple certificates, like Apache. Do we recommend for them to install two certificates, or allow use of just ECDSA cert?

@jvehent

This comment has been minimized.

Contributor

jvehent commented Nov 20, 2015

The intermediate ciphersuite will continue to recommend RSA certificates for backward compatibility purpose.
The modern ciphersuite will recommend ECDSA certificate, and it's up to the administrator to understand that the modern ciphersuite may break some clients.

But to your point, I agre that we should point out support for dual-cert when available. Do you have conf samples we could add to the wiki, or even better, an option to the conf generator?

@tomato42

This comment has been minimized.

Member

tomato42 commented Nov 20, 2015

I was thinking more on the lines of explicit recommendation in the Modern set description that ECDSA certs are preferred (and making the analyze.py warn if it detects just RSA being supported).

I will try to figure out the httpd config for RSA+ECDSA, stay tuned.

@tomato42

This comment has been minimized.

Member

tomato42 commented Nov 20, 2015

So it turns out that configuring mod_ssl with two certificates at the same time is not too complex.

You need to create 3 files:

  1. rsa-cert.pem that contains the private RSA key and the end entity certificate matching that key
  2. ecdsa-cert.pem that contains the private ECDSA key and the end entity certificate matching that key
  3. server-chain.pem that contains all the intermediate CA certificates that are provided by the CA with the end entity certificates

Example: If by getting a cert from the CA you did get server-rsa.key, server-rsa.crt and server-rsa-bundle.pem and a second set of server-ecdsa.key, server-ecdsa.crt and server-ecdsa-bundle.pem for the ECDSA cert you need to run the following commands:

cat server-rsa.crt server-rsa.key > rsa-cert.pem
cat server-ecdsa.crt server-ecdsa.key > ecdsa-cert.pem
cat server-rsa-bundle.pem server-ecdsa-bundle.pem > server-chain.pem

Now, in SSL TLS host configuration you need to set the following entries:

SSLCertificateFile /path/to/cert/files/rsa-cert.pem
SSLCertificateFile /path/to/cert/files/ecdsa-cert.pem
SSLCertificateChainFile /path/to/cert/files/server-chain.pem

then make sure that any present SSLCertificateKeyFile entries are commented out (are on lines starting with a #) and you're done! (if you're already using the Mozilla configuration)

I've verified that it works on RHEL-6 and RHEL-7.

@jvehent

This comment has been minimized.

Contributor

jvehent commented Nov 20, 2015

Awesome. And that doesn't work with SSLCertificateKeyFile I'm guessing because it needs to pair the cert with the right key?

@tomato42

This comment has been minimized.

Member

tomato42 commented Nov 20, 2015

No, it doesn't work because at least on RHEL, it points to the self-signed key which won't have a matching certificate if you modify existing SSLCertificateFile.

using two SSLCertificateFile and two SSLCertificateKeyFile should work too according to documentation, but I haven't tested that

but the "all stuff related to a cert in a single file" is the format used with Apache 2.4 together with OpenSSL 1.0.2, as it can provide separate intermediate certificate sets for different end-entity certificates, so you can say that this style is more modern

@jrchamp

This comment has been minimized.

Contributor

jrchamp commented Nov 20, 2015

Seems to be better to keep them separated.

Quoting https://httpd.apache.org/docs/trunk/mod/mod_ssl.html#sslcertificatekeyfile

The directive can be used multiple times (referencing different filenames) to support multiple algorithms for server authentication. For each SSLCertificateKeyFile directive, there must be a matching SSLCertificateFile directive.

The private key may also be combined with the certificate in the file given by SSLCertificateFile, but this practice is highly discouraged. If it is used, the certificate files using such an embedded key must be configured after the certificates using a separate key file.

@april

This comment has been minimized.

Contributor

april commented Nov 24, 2015

Okay, my remaining feedback:

  • DHE as a handshake option

I'm okay with killing it in the cipher suites. If people always followed our recommendation (custom groups with dhparam), it would be fine, but they don't. Maybe we can add it again someday if servers start generating their own groups automatically.

  • 4096-bit keys for RSA

Is it time to move things up in Modern? If a site can't get an ECDSA cert, perhaps RSA 4096 is the next best option. It's close.

  • ECDSA > RSA for certs

Seems great to me. Does this move up the minimum clients list at all?

  • AES-128 v. AES-256

DJB is casting doubt on AES-128, and Suite B has been updated to use AES-256 only. Should we prefer AES-256 over AES-128? I say yes. The low-end of device computing has improved appreciably, and AES-256 is still really fast. Maybe take it to the mailing list, but I say for Modern that we should recommend AES-256 over AES-128.

  • CHACHA20

Hooray, but I don't see it in your commit. :)

  • ed25519

Should we add it as a supported curve for handshakes? I think it might be a bit too early, given library support.

@tomato42

This comment has been minimized.

Member

tomato42 commented Nov 24, 2015

  • DHE as a handshake option

I'm okay with killing it in the cipher suites. If people always followed our recommendation (custom > groups with dhparam), it would be fine, but they don't. Maybe we can add it again someday if
servers start generating their own groups automatically.

remember that the idea is that the same recommendations are in place no matter if you're running RHEL-5 or Debian sid/Archlinux/Gentoo. For the former DHE is the only option for PFS. If you're running RHEL-6 and you're locked into OpenSSL 1.0.0 because FIPS certification, DHE is also the only option.

+1 for 4096 RSA for Modern

I'm on fence for AES-128 vs AES-256. +1 for mailing list

the lack of CHACHA is because its not part of upstream OpenSSL, but then, it is part of GnuTLS, so we probably should add it

we should probably wait for ed25519/ed448 until there are RFCs for them...

And speaking of Suite B - we probably should require server to support ECDH without using P-256 curve (in practice it means supporting P-384 and P-256 at the same time) for Modern.

@april

This comment has been minimized.

Contributor

april commented Nov 24, 2015

remember that the idea is that the same recommendations are in place no matter if you're running RHEL-5 or Debian sid/Archlinux/Gentoo. For the former DHE is the only option for PFS. If you're running RHEL-6 and you're locked into OpenSSL 1.0.0 because FIPS certification, DHE is also the only option.

Outdated clients like that are what the Intermediate / Old recommendations are for. Modern should be tailored specifically to cutting edge, modern versions of operating systems, TLS clients/servers, and hardware. This is why I feel like we should definitely recommend AES-256 and CHACHA for Modern. RSA 4096 would be great, but it's really slow.

@tomato42

This comment has been minimized.

Member

tomato42 commented Nov 24, 2015

I was talking about servers, not clients.

@april

This comment has been minimized.

Contributor

april commented Nov 24, 2015

Right, but the Modern recommendations are for modern systems on both ends. If you have a very old server, you might not be able to make it work with the Modern cipher suite, and that's okay: fallback to Intermediate.

@jvehent

This comment has been minimized.

Contributor

jvehent commented Nov 24, 2015

I agree with April: we should not hold back on the modern recommendation because people don't upgrade their servers. The old and intermediate recommendations fill that need already.

@tomato42

This comment has been minimized.

Member

tomato42 commented Nov 26, 2015

why did you drop ciphers like ECDHE-RSA-AES256-SHA or ECDHE-ECDSA-AES256-SHA?

MD5 HMAC is far from broken, let alone SHA1 HMAC. And without those ciphers allowing TLSv1.1 is moot.

@jvehent

This comment has been minimized.

Contributor

jvehent commented Nov 26, 2015

To clarify: this is just for the modern guidelines. intermediate and old still allow those ciphers.
You're correct that disabling them makes TLS1.1 unusable. That's fine for most browsers except IE that doesn't have TLS1.2 support until 11. Now given Microsoft's recent take on deprecating IE<11, should we really care that IE<11 can't connect to a modern site? And if not, is there a point to keeping TLS1.1 in the modern guidelines at all?

I'm tempted to just disable TLS1.1 in the modern guidelines altogether.

@jvehent

This comment has been minimized.

Contributor

jvehent commented Nov 26, 2015

$ ./cipherscan jve.linuxwall.info
..........
Target: jve.linuxwall.info:443

prio  ciphersuite                  protocols  pfs                 curves
1     ECDHE-RSA-AES128-GCM-SHA256  TLSv1.2    ECDH,P-384,384bits  secp384r1
2     ECDHE-RSA-AES256-GCM-SHA384  TLSv1.2    ECDH,P-384,384bits  secp384r1
3     ECDHE-RSA-AES128-SHA256      TLSv1.2    ECDH,P-384,384bits  secp384r1
4     ECDHE-RSA-AES256-SHA384      TLSv1.2    ECDH,P-384,384bits  secp384r1

Certificate: trusted, 2048 bits, sha256WithRSAEncryption signature
TLS ticket lifetime hint: 300
OCSP stapling: supported
Cipher ordering: server
Curves ordering: server - fallback: no
Server supports secure renegotiation
Server supported compression methods: NONE
TLS Tolerance: yes

(I need to build HAProxy with chacha20 support)

@tomato42

This comment has been minimized.

Member

tomato42 commented Nov 26, 2015

I'm tempted to just disable TLS1.1 in the modern guidelines altogether.

I'm not attached to it either - I was just pointing out that the suggestions are inconsistent

the reason why we may want to disable TLS1.1 is that the ServerKeyExchange message is signed with SHA-1[1], similarly, CertificateVerify uses SHA-1 to prove possession of private key from client side

(I need to build HAProxy with chacha20 support)

note that the ChaCha20 in the OpenSSL fork (the one we have in cipherscan repo) is not the ChaCha20 ciphersuites that were standardised in RFC 7539 and subsequently used in https://tools.ietf.org/html/draft-ietf-tls-chacha20-poly1305-02 . Our copy of OpenSSL uses the incompatible https://tools.ietf.org/html/draft-agl-tls-chacha20poly1305-04 )

1 - yes, I know that it is MD5+SHA-1, but we now know that attacking such construct is only insignificantly more complex than attacking just SHA-1

@jvehent

This comment has been minimized.

Contributor

jvehent commented Dec 15, 2015

Ah, could the wiki be updated to reflect that?

Yes, through this pull request. I haven't finished it yet, there will be various updates to the mediawiki file coming up.

@april

This comment has been minimized.

Contributor

april commented Dec 21, 2015

@lgarron Is...

For security and interoperability in the face of upcoming browser changes, site operators should ensure that their servers use SHA-2 certificates, support non-RC4 cipher suites, and follow TLS best practices. In particular, we recommend that most sites support TLS 1.2 and prioritize the ECDHE_RSA_WITH_AES_128_GCM cipher suite. We also encourage site operators to use tools like the SSL Labs server test and Mozilla's SSL Configuration Generator.

... Google's subtle way of saying that they think we should stick with AES-128 > AES-256 in the Modern cipher suite recommendation? Just checking. :)

@tomato42

This comment has been minimized.

Member

tomato42 commented Dec 22, 2015

NSS for the longest time didn't support AES_256_GCM_SHA384 ciphers, so effectively the most secure one were AES_182_GCM ones.

First: it's now changing, soon NSS will support AES_256_GCM ciphers in TLS

Second: as long as we put GCM > CBC, irrespective of key size (as we should, IMHO), it won't cause either Chrome or Firefox to select suboptimal ciphers, even if we don't keep the AES-128 > AES-256 order.

Unrelated to the above, I was thinking if we shouldn't underline which ciphers support is most important in any given configuration. Introducing something like a "Mandatory support for:", with TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 in Modern, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 in Intermediate and something like 3DES and TLS_RSA_WITH_AES_128_CBC_SHA1 for Legacy.

@jvehent

This comment has been minimized.

Contributor

jvehent commented Dec 23, 2015

I'm still making progress on this as I implement the evaluation worker in the TLS Observatory. In the last iteration, I change various types to accept multiple values, because prescribing a single signature type is too restrictive.

@lgarron

This comment has been minimized.

lgarron commented Dec 24, 2015

Google's subtle way

More like Chrome's subtle way. ;-)
You're welcome to prioritize AES-256-GCM over it, but we do recommend that you still prioritize it relatively high. ;-)

@jvehent

This comment has been minimized.

Contributor

jvehent commented Jan 12, 2016

@marumari : see latest set of commits for review plz

@april

This comment has been minimized.

Contributor

april commented Jan 12, 2016

My only major piece of feedback is that you should include something in the Modern rationale about DHE being consistently implemented incorrectly.

Slowness and client support for ECDHE are all fine reasons, but I think if that is the only rationale then we will get plenty of complaints about backdoored curves, etc., especially when state-of-the-art cryptanalysis shows that DHE is completely fine (if slow) when implemented correctly.

Otherwise, aside from some grammatical issues, I think it looks great and I agree with all your reasoning. r+

"configurations": {
"modern": {
"openssl_ciphersuites": "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256",
"ciphersuites": [

This comment has been minimized.

@leonklingele

leonklingele Jan 13, 2016

<3 Thanks for renaming this.

cipherSuites: profiles[data.securityProfile]["ciphersuite"],
maxDHKeySize: profiles[data.securityProfile]["dh_param_size"],
clientList: profiles[data.securityProfile]["oldest_clients"].join(),
// we make an elb policy but creating an array with protocol versions, ciphers and parameters

This comment has been minimized.

@jrchamp

jrchamp Jan 13, 2016

Contributor

but -> by

@tomato42

This comment has been minimized.

Member

tomato42 commented Jan 18, 2016

DHE being consistently implemented incorrectly.

could you elaborate?

@jvehent

This comment has been minimized.

Contributor

jvehent commented Jan 18, 2016

Sysadmins rarely regenerate dhparams, so most DHE ciphersuites use the default groups, which are vulnerable.

@jvehent

This comment has been minimized.

Contributor

jvehent commented Jan 23, 2016

jvehent added a commit that referenced this pull request Feb 11, 2016

V4: updated ciphersuites, publish guidelines as JSON
This commit is the result of several months of discussions and
maturation. It represents the state of the art in TLS configurations. It
has been rebased, but the history is shown below and can be read at:
#97

- V4: updated levels, added JSON
- Remove DHE from modern, add ChaCha20
- prefer aes256 in modern, add ecdh size parameter
- Remove TLSv1.1 from modern level
- Prefer AES256-GCM to ChaCha20 in modern configuration
- Recommend ECDSAWithSHA384 as cert signature in modern conf
- Remove unused document signature
- Change recommended curve in Modern to P256
- Convert certificate types, curves and signatures to lists to support multiple acceptable values
- readd EDH-RSA-DES-CBC3-SHA to intermediate and old
- Add DHE-RSA-AES256-GCM-SHA384 to intermediate level
- rename json keys
- Revisit old ciphersuites
- Update wiki document with latest recommendations and rationales
- Add paragraph on certificates switching
- Remove configuration samples & cleanup some stuff
- reset changes to conf generator
V4: updated ciphersuites, publish guidelines as JSON
This commit is the result of several months of discussions and
maturation. It represents the state of the art in TLS configurations. It
has been rebased, but the history is shown below and can be read at:
#97

- V4: updated levels, added JSON
- Remove DHE from modern, add ChaCha20
- prefer aes256 in modern, add ecdh size parameter
- Remove TLSv1.1 from modern level
- Prefer AES256-GCM to ChaCha20 in modern configuration
- Recommend ECDSAWithSHA384 as cert signature in modern conf
- Remove unused document signature
- Change recommended curve in Modern to P256
- Convert certificate types, curves and signatures to lists to support multiple acceptable values
- readd EDH-RSA-DES-CBC3-SHA to intermediate and old
- Add DHE-RSA-AES256-GCM-SHA384 to intermediate level
- rename json keys
- Revisit old ciphersuites
- Update wiki document with latest recommendations and rationales
- Add paragraph on certificates switching
- Remove configuration samples & cleanup some stuff
- reset changes to conf generator
@jvehent

This comment has been minimized.

Contributor

jvehent commented Feb 11, 2016

V4 updated and ready to merge, but I haven't modified the config generator yet. I attempted to use the JSON file directly in the generator, but run into issues and decided to push this before modifying the generator.

jvehent added a commit that referenced this pull request Feb 11, 2016

Merge pull request #97 from mozilla/4.0
V4: updated levels, added JSON

@jvehent jvehent merged commit 7ef0672 into gh-pages Feb 11, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment