secure ssl configuration

[octomike]

I was reading about sweet32 and wondered how this module keeps track of bad and good openssl cipher settings. Turns out the last update for this was in June 2015. What's the policy here? Can I just pull request a current list, e.g. according to Mozilla's SSL Configuration Generator?

[ekohl]

👍 on fixing this. The default config produces a B in ssllabs.com. I'd recommend submitting a PR with working tests.

[wyardley]

Agree that this should be a priority. I was just looking through the module for something else and noticed that the cipher list looked out of date, and that TLSv1 was supported still.
(https://github.com/ssllabs/research/wiki/SSL-and-TLS-Deployment-Best-Practices has some examples).

the nginx default seems simple: "HIGH:!aNULL:!MD5;". Have not tested this one, what do folks think about that option?

https://cipherli.st/ seems probably a bit too strict.
https://support.cloudflare.com/hc/en-us/articles/200933580-What-cipher-suites-does-CloudFlare-use-for-SSL-
doesn't seem like a bad place to start.

I can start a PR for this, but probably needs some good testing beyond running acceptance tests on a few platforms.

[wyardley]

Opened #909 for this, but would love for people to do some functional testing on this if at all possible. If someone can stand this up somewhere public and run the Qualys labs tests or similar against it, that would also be helpful.

This does seem to past existing acceptance tests on Ubuntu 12 and CentOS 6 (wanted to try against somewhat older stuff; couldn't get the CentOS 5 beaker test to work, though).

[wyardley]

I have updated it to the defaults in:
https://mozilla.github.io/server-side-tls/ssl-config-generator/
specifying default (1.0.1e) as baseline OpenSSL version.

[zachfi]

Thank you.

[wyardley]

@xaque208 Just a heads up that the PR is still not merged. If anyone has a system they can test this config (or the PR) against that's publicly reachable and has a commercial cert, that would be great.

[zachfi]

As long as FreeBSD compatibility has not broken during the transition to voxpupuli, I can likely test an evening this week.

[ekohl]

Now #909 has been merged, can this be closed?

[wyardley]

@ekohl: I don't think anyone's actually ran the tester against this in the wild (with a real cert) yet, so let's keep it open until we get some feedback on that. Would be nice to verify that the default will give an 'A' rating.

[octomike]

I just pulled master in an environment on one of our machines and ran ssllabs.com against it:

https://www.ssllabs.com/ssltest/analyze.html?d=lip-webexperiments.mpib-berlin.mpg.de&hideResults=on

Looking good. 👍

The only hiera options we set are ssl, ssl_cert, ssl_key, and ssl_dhparam.

[wyardley]

Love this! Going to close this issue, then.
I'm guessing we may still run into some issues if folks have old OpenSSL versions that barf on some of those ciphers, but we can deal with those separately.

[octomike]

Thanks so much for fixing this! I kind of lost my instruction pointer while digging into rspec.

[csdougliss]

@wyardley @octomike DES-CBC3-SHA is still being included which fails our PCI scan? Due to SWEET32 checking:

Port 443
Protocol TCP
Service www
Title SSL 64-bit Block Size Cipher Suites Supported (SWEET32)
close
Synopsis:

The remote service supports the use of 64-bit block ciphers.
Impact:

The remote host supports the use of a block cipher with 64-bit blocks in one or more cipher suites. It is, therefore, affected by a vulnerability, known as SWEET32, due to the use of weak 64-bit block ciphers. A man-in-the-middle attacker who has sufficient resources can exploit this vulnerability, via a 'birthday' attack, to detect a collision that leaks the XOR between the fixed secret and a known plaintext, allowing the disclosure of the secret text, such as secure HTTPS cookies, and possibly resulting in the hijacking of an authenticated session. Proof-of-concepts have shown that attackers can recover authentication cookies from an HTTPS session in as little as 30 hours. Note that the ability to send a large number of requests over the same TLS connection between the client and server is an important requirement for carrying out this attack. If the number of requests allowed for a single connection were limited, this would mitigate the vulnerability. However, SecurityMetrics has not checked for such a mitigation. See also : https://sweet32.info https://www.openssl.org/blog/blog/2016/08/24/sweet32/
Resolution:

Reconfigure the affected application, if possible, to avoid use of all 64-bit block ciphers. Alternatively, place limitations on the number of requests that are allowed to be processed over the same TLS connection to mitigate this vulnerability.
Data Received:

List of 64-bit block cipher suites supported by the remote server : Medium Strength Ciphers (> 64-bit and < 112-bit key) TLSv1 EDH-RSA-DES-CBC3-SHA Kx=DH Au=RSA Enc=3DES-CBC(168) Mac=SHA1 ECDHE-RSA-DES-CBC3-SHA Kx=ECDH Au=RSA Enc=3DES-CBC(168) Mac=SHA1 DES-CBC3-SHA Kx=RSA Au=RSA Enc=3DES-CBC(168) Mac=SHA1 The fields above are : {OpenSSL ciphername} Kx={key exchange} Au={authentication} Enc={symmetric encryption method} Mac={message authentication code} {export flag}
CVE
Score
Vector
Expand/Collapse
CVE-2016-2183
5.0
(AV:N/AC:L/Au:N/C:P/I:N/A:N)

Port 443
Protocol TCP
Service www
Title SSL Medium Strength Cipher Suites Supported
close
Synopsis:

The remote service supports the use of medium strength SSL ciphers.
Impact:

The remote host supports the use of SSL ciphers that offer medium strength encryption. SecurityMetrics regards medium strength as any encryption that uses key lengths at least 56 bits and less than 112 bits, or else that uses the 3DES encryption suite. Note that it is considerably easier to circumvent medium strength encryption if the attacker is on the same physical network. See also : https://www.openssl.org/blog/blog/2016/08/24/sweet32/
Resolution:

Reconfigure the affected application if possible to avoid use of medium strength ciphers.
Data Received:

Here is the list of medium strength SSL ciphers supported by the remote server : Medium Strength Ciphers (> 64-bit and < 112-bit key) TLSv1 EDH-RSA-DES-CBC3-SHA Kx=DH Au=RSA Enc=3DES-CBC(168) Mac=SHA1 ECDHE-RSA-DES-CBC3-SHA Kx=ECDH Au=RSA Enc=3DES-CBC(168) Mac=SHA1 DES-CBC3-SHA Kx=RSA Au=RSA Enc=3DES-CBC(168) Mac=SHA1 The fields above are : {OpenSSL ciphername} Kx={key exchange} Au={authentication} Enc={symmetric encryption method} Mac={message authentication code} {export flag}

[ekohl]

@craigcarnell they are included in the Mozilla SSL configuration generator intermediate profile which this module follows. You can easily override this by settings ssl_ciphers on the main nginx class. Other resources like vhosts will inherit this. You can also override it on the resource level.

If you wish to change the defaults to something stricter, please open a separate issue or pull request.

[wyardley]

@craigcarnell @ekohl: I think the intermediate profile probably makes sense for the default still, though open to other opinions. It is overridable as @ekohl mentions if you have specific compliance requirements.

[ekohl]

@wyardley for now I mostly agree, though it looks like versions older than IE11 are dropping below 1% usage so it may become time to move to the modern profile.

[wyardley]

@ekohl If someone wants to submit a new PR that reflects stricter defaults, I will try and run it by the Voxpupuli team.

[ekohl]

I know the last time we tried it we did discover that many email clients (IIRC old Outlook versions) can't handle the modern set, so I won't be pushing for it just yet.

[tobixen]

The mozilla recommendations now is a bit out of sync with what this module provides. (disclaimer: I haven't done much research into this, haven't check

Here is from the config generator:

    # intermediate configuration
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305;
    ssl_prefer_server_ciphers off;

And this is the defaults from the module:

  ssl_protocols             TLSv1 TLSv1.1 TLSv1.2;
  ssl_ciphers               ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS;
  ssl_prefer_server_ciphers on;

I have no clue (I'm not an expert in these things) on the ssl_prefer_ciphers, but I think it's quite obvious that the ssl_protocols ought to be adjusted. If I get it right, a lot of those ciphers are considered "obscure". Even if there are no known weaknesses, they may be less reviewed than the more common ciphers. I don't have any strong opinions on this, I just ran a script that reported that some of those ciphers ought to be removed ... but I suppose it's safest to default on the mozilla recommendations.

Other differences observed ... recommended from mozilla:

ssl_session_timeout 1d;
ssl_session_cache shared:MozSSL:10m;  # about 40000 sessions

Defaults set to 5m and shared:SSL:10m by the module. I have no idea about those things to be honest.

This is also defined in the recommendation, but not defined by the module:

ssl_session_tickets off;

# curl https://ssl-config.mozilla.org/ffdhe2048.txt > /path/to/dhparam
ssl_dhparam /path/to/dhparam;

# HSTS (ngx_http_headers_module is required) (63072000 seconds)
add_header Strict-Transport-Security "max-age=63072000" always;

The latter requires a module and if added it may possibly break backward compatibility for some few users.

OCSP stapling is recommended, but set to off as the default in the module configuration. Are there any drawbacks in OCSP stapling?

Path for the trusted cert store and IP-address for resolver is also hardcoded in the recommendation from Mozilla. I suppose trusting the OS defaults is good enough.

Should I look more into this and raise a pull request? Maybe raise a new issue rather than just adding a comment on an old abandoned issue?

[tobixen]

I'll move it out as a separate issue so it will be more visible :-)