Could it be that the entire 1.6.x series are missing from Javascript?

Due to a bug the ciphersuites were missing from the generated configs from
1:51pm PDT at c46f58c until it was fixed at 4:03pm PDT at 96c3612

It might be useful to add some data about the version/data of the configuration snippet to it as comment to have a clue, whether it's outdated or not when looking at a webserver's config.

Just something like this:

<VirtualHost *:443>
    ...
    # This SSL configuration snippet was generated on 2015-04-10 21:03:15 UTC
    # using `Mozilla SSL Configuration Generator` at git commit ID 9b3e7e0ef0
    # https://mozilla.github.io/server-side-tls/ssl-config-generator/?server=apache-1.6&openssl=0.9.8h&hsts=yes&profile=modern
    SSLEngine on
    SSLCertificateFile      /path/to/signed_certificate
    SSLCertificateChainFile /path/to/intermediate_certificate
    SSLCertificateKeyFile   /path/to/private/key
    SSLCACertificateFile    /path/to/all_ca_certs

    # modern configuration, tweak to your needs
    SSLProtocol             all -SSLv2 -SSLv3 -TLSv1
    SSLCipherSuite          ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK
    SSLHonorCipherOrder     on

    # HSTS (mod_headers is required) (15768000 seconds = 6 months)
    Header always add Strict-Transport-Security "max-age=15768000"
    ...
</VirtualHost>

In my opinion, the very first thing that should show is the "most common" configuration for apache, or maybe the latest stable version. It was quite confusing to me when visiting the site that I needed to click a radio button and back to apache to view my configs.

I think the generated configs need to show by default for whatever is set as the pre-filled elements.

I'd be happy to submit a PR for this if needed.

Steps To Reproduce

1. go to https://mozilla.github.io/server-side-tls/ssl-config-generator/?1
2. configs arent showing using default settings (apache, modern)
3. to make it show, change any field

Animated GIF of the issue

System Info

OS: WIndows 7 x64
Browser: Chrome Version 43.0.2357.2 dev-m (64-bit)

On https://github.com/mozilla/server-side-tls/blob/gh-pages/ssl-config-generator/index.html#L156
you add the ssl_trusted_certificate directive in the Apache directives. The ssl_trusted_certificate directive is for nginx not for Apache. Apache uses the SSLCACertificateFile that you already have included for OCSP Stapling response validation.

Looks like the ssl_trusted_certificate is missing in the nginx option. So probably you just added the line in the wrong block.

modern is great, but since IE10 is still around and only does TLS v1, not that many people can use this setting. The next setting is intermediate, all the way back to IE7.

How about a new setting that

• Still sets minimumTLSVersion to tlsv1 like intermediate
• Start with cipherSuites from modern (cutting out all 128 bit payloads - see #35)

This would be a reasonable step down for people who have to support IE10.

The DH Key size value in (a comment of) the nginx profiles is hardcoded to 2048.

It should, like for HAProxy, use the maxDHKeySize value depending on the selected profile.

Otherwise the "compatible clients" list is wrong

As mobile devices can't mouseover things, the tooltip showing why the modern profile is disabled is not visible.

One idea for a solution : http://stackoverflow.com/a/25362060/168874

The nginx and HAProxy profiles include config statements for custom DH parameters.
Apache also supports custom DH parameters.

Version requirements

• Apache >= 2.4.8
• OpenSSL used for mod_ssl >= 1.0.2

SSLOpenSSLConfCmd DHParameters "/path/to/custom/dhparams.pem"

If this it added it should, similar to the comment in the nginx profile, include a comment with recommended DH key size based on the chosen profile.

Apache documentation: http://httpd.apache.org/docs/trunk/mod/mod_ssl.html#sslopensslconfcmd

Related to /issues/48 and /issues/66

Current:

    # HSTS (mod_headers is required) (15768000 seconds = 6 months)
    Header always add Strict-Transport-Security "max-age=15768000"

Better:

    <IfModule mod_headers.c>
      # HSTS (mod_headers is required) (15768000 seconds = 6 months)
      Header always add Strict-Transport-Security "max-age=15768000"

      # The page can only be displayed in a frame on the same origin as the page itself.
      Header always append X-Frame-Options SAMEORIGIN
    </IfModule>

It wasn't immediately obvious to me that I could change the requested nginx version to, say, 99 and additionally receive OCSP stapling directives.

It would be nice to allow the string "latest" to return the most modern instructions available, and possibly default to that setting.

If the generated Apache VirtualHost is copied directly in Apache 2.4.7, Apache2 will fail to load.

Running which apache2ctl -V or apachectl configtest or trying to restart Apache will fail:

AH00526: Syntax error on line [x] of /etc/apache2/sites-enabled/default-ssl.conf:
Invalid command '...', perhaps misspelled or defined by a module not included in the server configuration

The "..." at the beginning and end of the VirtualHost cause syntax errors on Apache 2.4.7. Even though this is just a "guideline" for setting up the VirtualHost, it seems these lines are unnecessary. I imagine the syntax error would occur on other versions as well, but I have not tested.

Please add

SSLStaplingCache "shmcb:${APACHE_RUN_DIR}/ssl_gcache_data(150000)"

Documented here for Apache 2.4
http://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslsessioncache

Both the nginx and HAProxy configs include a path to a dhparam.pem, but there is no explanation for how to generate it. Googling indicates it's pretty simple (openssl dhparam -out /path/to/dhparam.pem 2048) but it requires an extra search that seems like it shouldn't be needed. I suggest adding a comment above the line that mentions it indicating how to generate it.

Therefore:

    SSLProtocol all -SSLv2

is a NOP. It should probably be removed from the file if the Apache version is >= 2.3.16.

In some setups, mod_headers is not loaded. This helps preventing this problem.

<IfModule mod_headers.c>
    # HSTS
    Header add Strict-Transport-Security "max-age=15768000"
</IfModule>

We've been testing the generator and found that the tune.ssl.default-dh-param setting recommendation is incorrect when trying to support Java 6 (the old config). Java 6 has a maximum acceptable size of 1024.

It seems to me that the weak DHE ciphers should be disabled. E.g. for apache2 on Debian 7 Wheezy with openssl 1.0.1e, all the ciphers starting with DHE must be explicitly disabled by adding this to the line SSLCipherSuite:

!DHE-DSS-AES256-GCM-SHA384:!DHE-RSA-AES256-GCM-SHA384:!DHE-RSA-AES256-SHA256:!DHE-DSS-AES256-SHA256:!DHE-RSA-AES256-SHA:!DHE-DSS-AES256-SHA:!DHE-RSA-CAMELLIA256-SHA:!DHE-DSS-CAMELLIA256-SHA:!DHE-DSS-AES128-GCM-SHA256:!DHE-RSA-AES128-GCM-SHA256:!DHE-RSA-AES128-SHA256:!DHE-DSS-AES128-SHA256:!DHE-RSA-AES128-SHA:!DHE-DSS-AES128-SHA:!DHE-RSA-SEED-SHA:!DHE-DSS-SEED-SHA:!DHE-RSA-CAMELLIA128-SHA:!DHE-DSS-CAMELLIA128-SHA

Only after having all these in, the test on ssllabs.com grants the highest score.

Please someone correct me if I misunderstood it.

Experienced users might already know exactly which client versions they want to support. For everyone else, it's probably useful to see how old the given client versions are in years and/or to have an estimate of the overall percentage of users that will be covered by the compatible versions.

TLSv1 can not be removed on CentOS 5.11 using apache 2.2.3 and OpenSSL 0.9.8e.

See my comment here:
http://unix.stackexchange.com/questions/191302/does-apache-2-2-3-support-tlsv1-1-and-tlsv1-2/195140#195140

Hi - Could you please clarify the license this was released under?

Can openssl version and nginx version be dropdowns? For example, I know I'm on latest stable nginx, but I don't know what exact version number it is. Also it's not obvious that the configuration will change if you update these values.

nginx versions can be pulled from http://nginx.org/en/CHANGES. This does not say which versions are stable or not but it gives a list of code releases.

For OpenSSL, it may be tricker since several branches are maintained. One idea is to use a filtered list of tags as published at https://github.com/openssl/openssl.

For apache2, try https://www.apachelounge.com/Changelog-2.4.html and https://www.apachelounge.com/Changelog.html.

For HAProxy: https://github.com/haproxy/haproxy/blob/master/CHANGELOG

Please consider adding overflow-x: scroll; to the pre element's style.

The mouse over for a modern config with Apache 2.2 says that TLS v1.1 & v1.2 is only supported in Apache 2.4.

The docs for Apache 2.2 reflect this support here: https://httpd.apache.org/docs/2.2/mod/mod_ssl.html#sslprotocol

It would be great to support AWS ELB policies. One challenge would be to automatically generate the policy based on the openssl ciphersuite. But if that's not possible, simply displaying a static policy would work.

Below is a sample for the intermediate level, courtesy of @ckolos

"Policies":[
  {
    "PolicyName":"Mozilla-Opsec-Intermediate-2014-11-06",
    "PolicyType":"SSLNegotiationPolicyType",
    "Attributes":[
      {"Name":"Protocol-TLSv1" ,                "Value":true },
      {"Name":"Protocol-TLSv1.1" ,              "Value":true },
      {"Name":"Protocol-TLSv1.2" ,              "Value":true },
      {"Name":"Server-Defined-Cipher-Order" ,   "Value":true },
      {"Name": "ECDHE-RSA-AES128-GCM-SHA256",   "Value":true },
      {"Name": "ECDHE-ECDSA-AES128-GCM-SHA256", "Value":true },
      {"Name": "ECDHE-RSA-AES256-GCM-SHA384",   "Value":true },
      {"Name": "ECDHE-ECDSA-AES256-GCM-SHA384", "Value":true },
      {"Name": "DHE-RSA-AES128-GCM-SHA256",     "Value":true },
      {"Name": "DHE-DSS-AES128-GCM-SHA256",     "Value":true },
      {"Name": "kEDH+AESGCM",                   "Value":true },
      {"Name": "ECDHE-RSA-AES128-SHA256",       "Value":true },
      {"Name": "ECDHE-ECDSA-AES128-SHA256",     "Value":true },
      {"Name": "ECDHE-RSA-AES128-SHA",          "Value":true },
      {"Name": "ECDHE-ECDSA-AES128-SHA",        "Value":true },
      {"Name": "ECDHE-RSA-AES256-SHA384",       "Value":true },
      {"Name": "ECDHE-ECDSA-AES256-SHA384",     "Value":true },
      {"Name": "ECDHE-RSA-AES256-SHA",          "Value":true },
      {"Name": "ECDHE-ECDSA-AES256-SHA",        "Value":true },
      {"Name": "DHE-RSA-AES128-SHA256",         "Value":true },
      {"Name": "DHE-RSA-AES128-SHA",            "Value":true },
      {"Name": "DHE-DSS-AES128-SHA256",         "Value":true },
      {"Name": "DHE-RSA-AES256-SHA256",         "Value":true },
      {"Name": "DHE-DSS-AES256-SHA",            "Value":true },
      {"Name": "DHE-RSA-AES256-SHA",            "Value":true },
      {"Name": "AES128-GCM-SHA256",             "Value":true },
      {"Name": "AES256-GCM-SHA384",             "Value":true },
      {"Name": "AES128-SHA256",                 "Value":true },
      {"Name": "AES256-SHA256",                 "Value":true },
      {"Name": "AES128-SHA",                    "Value":true },
      {"Name": "AES256-SHA",                    "Value":true },
      {"Name": "AES",                           "Value":true },
      {"Name": "CAMELLIA",                      "Value":true },
      {"Name": "DES-CBC3-SHA",                  "Value":true }
    ]
  }
]

apache 2.2.22 | intermediate profile | OpenSSL 1.0.1e

does not have any cipher that has 256 bit on top. Therefore browsers only establishes a 128bit connection and not a 256bit. Per SSLLabs there are much harder citpher orders.

First of all: I'm not a cryptographer

But my understanding is that AES256 is more secure than AES128 and it should be preferred on the list of ciphers.

Before you point me to http://eprint.iacr.org/2009/374 take into account that such attack is a related-key attack, and therefore requires ""the cryptanalyst to have access to plaintexts encrypted with multiple keys that are related in a specific way"". [Quote from: https://www.schneier.com/blog/archives/2009/07/another_new_aes.html ]

So my understanding is that such attack is not possible in a well designed cryptographic system. Therefore AES256 should provide better security than AES128 in real applications, and it is a saner default for the next years. Read for example this interesting article about the NSA recommending AES256 for top-secret material because of hypothetical future attacks using quantum computers: https://blog.agilebits.com/2013/03/09/guess-why-were-moving-to-256-bit-aes-keys/

So, any reason to recommend AES128 instead of AES256? I think that the ciphers with AES256 should be preferred to the ones with AES128.

Hi

The profile for Apache 2.2.15 with OpenSSL 0.9.8f running on SUSE Linux Enterprise 11 SP 3 is broken. Using some experimentation i managed to establish that the following CipherSuites breaks the config:
KRB5-DES-CBC3-SHA, aECDH, AES and anything using the SHA384 algorithm.

If this is spesific to the apache/openssl package(s) included with the distro it might be wise to include a footnote on the page or pherhaps a drop down distro selector.

Either way thanks for a great little tool ;)

Hi there, I just implemented a node port of these settings and when testing noticed the following:

Since modern is already IE11 / Android 4.4 up, it seems reasonable to get rid of 128 bit payload encryption from the ciphers. The new list would be:

[
    "ECDHE-RSA-AES256-GCM-SHA384",
    "ECDHE-ECDSA-AES256-GCM-SHA384",
    "kEDH+AESGCM",
    "ECDHE-RSA-AES256-SHA384",
    "ECDHE-ECDSA-AES256-SHA384",
    "ECDHE-RSA-AES256-SHA",
    "ECDHE-ECDSA-AES256-SHA",
    "DHE-RSA-AES256-SHA256",
    "DHE-DSS-AES256-SHA",
    "DHE-RSA-AES256-SHA",
    "!aNULL",
    "!eNULL",
    "!EXPORT",
    "!DES",
    "!RC4",
    "!3DES",
    "!MD5",
    "!PSK"
].join(':')

You wouldn't lose any browser support, and you would increase the strength of the encryption.

Please consider adding Public Key Pinning.
Chrome already supports it.

The cipherlists are very hard to read and understand. I have no long discussion thread to back this up, but if there is something to contradict me, please point me that way. It's just from my experience that easier to understand configs are more readily adopted.

I'd also differentiate between 2.2 and 2.4 version of Apache. For 2.4 I'd drop RSA except RSA+3DES for IE8 (XP), as everything else talks (EC)DHE AFAIK.

These practically do the same as the long ones but are easier to understand:

Apache 2.2 intermediate: ALL:+RSA:+RSA+3DES:!MEDIUM:!LOW:!EXPORT:!NULL:!aNULL
Apache 2.2 modern: ALL:+RSA:!MEDIUM:!LOW:!EXPORT:!NULL:!aNULL:!3DES:!CAMELLIA

Apache 2.4 intermediate: ALL:-RSA:RSA+3DES:!MEDIUM:!LOW:!EXPORT:!NULL:!aNULL
Apache 2.4 modern: ALL:!RSA:!MEDIUM:!LOW:!EXPORT:!NULL:!aNULL:!3DES:!CAMELLIA

Apache filters these away automatically: "!SRP:!DSS:!PSK:!kECDH".

While I agree that you can do a lot of fine tuning with explicitely stating all ciphers as you have done, if TLS1.2 connections do not accept cipher outside the TLS 1.2 spec, the intermingled ciphers from below 1.2 should not matter and these short strings should do the same as the long ones (with the difference that AES256 comes before AES128)

Also I don't think there are any browsers that only support TLS 1.1 as the highest protocol and I disabled it on my machines but that is debatable.

The cipherspecs generated are very long. Thanks to the format needed, that also makes them really hard to read. You can generate the lists with much more concise (and readable) cipherspecs. For examples, the settings of "modern" and "intermediate" settings with openssl v1.0.1 are:

Modern: AES+kEECDH:AES+kEDH:!aNULL:@strength
Intermediate: HIGH:-kECDH:-3DES:DES-CBC3-SHA:!PSK:!MD5:!aNULL:@strength

The modern spec adds in two DHE-RSA-AES-SHA ciphers I believe you omitted by accident. I find it odd there would be only one allowed 3DES cipher for the intermediate spec--I would love to hear why. I'm also curious why you don't allow ECDH ciphers?

I hope this helps. The generator is really nifty and it would be great if it was smarter about the cipherspecs!

Could you please add http://mozilla.github.io/server-side-tls/ssl-config-generator/ as the repo lnik:

It is only a mockup, I have no write access to it.

SSLCertificateChainFile became obsolete with version 2.4.8, when SSLCertificateFile was extended to also load intermediate CA certificates from the server certificate file.

Please consider displaying this for Apache >= 2.4.8

Concatenate signed certificate + intermediate certificate(s) and optionally the issuers CA file in this order.

http://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslcertificatechainfile

It would be nice to have a string for use with gnutls since it has a different set of ciphers available.

Hey!

You made great work by giving us access to this!
I wanted to add OCSP, but I saw it is already there!

Do you know when will it be available online here: https://mozilla.github.io/server-side-tls/ssl-config-generator/

Thanks a lot for your work!

I realize configuring a Node.js server is a bit of a different beast than the other servers…but it'd be nice to have some examples of how to configure the built-in HTTPS server in Node.js to your recommendations.

Thanks for the great resource!

Currently the apache config looks something like this:

SSLHonorCipherOrder     on
SSLCipherSuite          ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:...

This makes it more likely that a client use "AES128" instead of "AES256".
Would be nice if the longer key/hash lenghts could be sorted to the first position.

SSLHonorCipherOrder     on
SSLCipherSuite          ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:...

If you're helping people generate server configs, you probably want to make sure that nobody is tampering with the code that generates them. (They're effectively permanent...)

Since github.io support HTTPS, https://mozilla.github.io/server-side-tls/ssl-config-generator/ functions perfectly.

At the very least, I think the link at https://wiki.mozilla.org/Security/Server_Side_TLS#Recommended_Server_Configurations should be updated to HTTPS.

While it appears that there isn't straightforward support for immediate redirects/HSTS yet, it might be good to do a client-side redirect for now. That way, anyone who bookmarks or copies the URL (while on an uncompromised connection) is going to have the secure link.

(I'd also suggest a warning not to use the tool over plain HTTP, but no one will read and heed that. A client-side redirect should hopefully eliminate the need for it.)

Great App!

Is it possible to include the compatibility table on the app?

https://wiki.mozilla.org/Security/Server_Side_TLS#Recommended_configurations

It's a handy reminder of what is or isn't compatable with a given security level. :-)

Hi, thanks for this convenient tool and the associated wiki content, it really helped the novice webmaster I am to make his webserver more secure :-)

I noticed nginx' template uses the ssl on; directive (line 41); notice however that its documentation states:

It is recommended to use the ssl parameter of the listen directive instead of this directive.

Its use is also recommend against on the https servers configuration page:

Prior to 0.7.14 SSL could not be enabled selectively for individual listening sockets, as shown above. SSL could only be enabled for the entire server using the ssl directive, making it impossible to set up a single HTTP/HTTPS server. The ssl parameter of the listen directive was added to solve this issue. The use of the ssl directive in modern versions is thus discouraged.

So I'd recommend replacing it with:

listen 443 ssl;

which is always one line saved ;-)

overflow-x: auto should do the trick for those super long lines.

As can be seen in this screenshot:

Depending on screen resolution the form is partially obscured, making the radios for switching server appear not to work.

If someone links to the Server Side TLS, they are greeted with lots of information. A lot of those visits should probably be guided to https://mozilla.github.io/server-side-tls/ssl-config-generator/ immediately (rather than leaving them at a page with details they usually don't need), but the link is buried deeper down in the page.

Now that the tool is more established, would it make sense to introduce it to the top?

apache 2.2.22 | intermediate profile | OpenSSL 1.0.1e

This is a much better config than above:
´´´
SSLProtocol ALL -SSLv2 -SSLv3
SSLHonorCipherOrder On
SSLCipherSuite ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS
´´´

It uses 256bit ciphers for all modern browsers.

It would be useful to support parameterized queries to link to specific configurations. Something link https://mozilla.github.io/server-side-tls/ssl-config-generator/?server=apache&level=modern&version=2.4&openssl_version=1.0.1 should link to the apache configuration of the modern level for version 2.4 and openssl 1.0.1.

I was looking for OCSP stapling in HAproxy, and it is quiet difficult to achieve.

I added that to the mozilla wiki: https://wiki.mozilla.org/Talk:Security/Server_Side_TLS#OCSP_in_HAProxy

I was wondering how we could add it to this website? It is nice information to have. And even if it is a hacky bach script, I'd love to have feedback from people!

Thanks!

I love this generator however one thing that concerns me about having a cipher list is the what happens when new ones are added/others removed or there are important changes to the recommended setup?

Just wondering if there's something that could be put in place to notify users of important changes? e.g. perhaps just a simple mailchimp/sendgrid subscription for important changes only?

Hi,
openSSL 0.9.8 and 1.0.0 don't support TLSv1.1 or TLSv1.2 (only appear with 1.0.1 cf http://en.wikipedia.org/wiki/OpenSSL#Major_version_releases), so the "Modern" configuration gave by the generator can't be used.
it may be a boog idea to replace the configuration by a warning/error message like "openSSL version does not support the requirement for a modern configuration"