-
-
Notifications
You must be signed in to change notification settings - Fork 882
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
secure ssl configuration #859
Comments
👍 on fixing this. The default config produces a B in ssllabs.com. I'd recommend submitting a PR with working tests. |
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. 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. I can start a PR for this, but probably needs some good testing beyond running acceptance tests on a few platforms. |
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). |
I have updated it to the defaults in: |
Thank you. |
@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. |
As long as FreeBSD compatibility has not broken during the transition to voxpupuli, I can likely test an evening this week. |
Now #909 has been merged, can this be closed? |
@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. |
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 |
Love this! Going to close this issue, then. |
Thanks so much for fixing this! I kind of lost my instruction pointer while digging into rspec. |
@wyardley @octomike DES-CBC3-SHA is still being included which fails our PCI scan? Due to SWEET32 checking:
|
@craigcarnell they are included in the Mozilla SSL configuration generator intermediate profile which this module follows. You can easily override this by settings If you wish to change the defaults to something stricter, please open a separate issue or pull request. |
@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. |
@ekohl If someone wants to submit a new PR that reflects stricter defaults, I will try and run it by the Voxpupuli team. |
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. |
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:
And this is the defaults from the module:
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:
Defaults set to This is also defined in the recommendation, but not defined by the module:
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? |
I'll move it out as a separate issue so it will be more visible :-) |
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?
The text was updated successfully, but these errors were encountered: