7 ms·

Mozilla SSL Configuration Generator

333 points by mcdoug 12y ago

MrRadar 12y ago
See also the accompanying Mozilla Wiki page: https://wiki.mozilla.org/Security/Server_Side_TLS https://wiki.mozilla.org/Security/Server_Side_TLS EDIT: Taken care of, thanks jvehent! Original: Interestingly, it looks like someone made three edits to the on March 16th (to make the same change to three different sections) and one of them was reverted but not the others. Can someone with a Mozilla Wiki account contact the maintainer for that page and ask them to verify that was intentional? I'd do it myself but I don't want to request an account (effectively) just to send a PM.
- nerdy 12y ago
  Don't forget about Zach Weinberg's offer to file bugs: https://www.owlfolio.org/htmletc/i-will-file-bugs-for-you/ https://www.owlfolio.org/htmletc/i-will-file-bugs-for-you/ (If it's intentional they could WONTFIX The bug)
- jvehent 12y ago
  Very good catch! Thanks for bringing it up. I had reverted the first one but missed the two others. Unfortunately, mediawiki only support two levels of access control: fully locked or fully open, so I need to manually police changes as they happen...
tootie 12y ago
This should be called HTTPS confuration generator. SSL was deprecated years ago.
- nailer 12y ago
  It should, or 'TLS/SSL'. But so many people - even in tech - still use 'SSL' as a synonym for 'PKI on the web' that it's better to be understood than correct (and yes it's a bit sad). Also: SSLv3 and TLSv1 are very similar: http://tim.dierks.org/2014/05/security-standards-and-name-changes-in.html http://tim.dierks.org/2014/05/security-standards-and-name-ch...
  - hsivonen 12y ago
    When the IETF renames things, everyone is going to have a bad time. See also URI and IRI.
    - nocman 12y ago
      Wow, I've never even heard of IRI. Guess that proves your point :-D
  - tootie 12y ago
    I think HTTPS has more name recognition than SSL.
- e1ven 12y ago
  Each of the tools involved refer to their the overall https configuration as SSL. Even if it's not the protocol which is being used, it's a reasonable choice for the tool name. Apache SSLProtocol all -SSLv2 -SSLv3 -TLSv1 SSLCipherSuite ECDHE-RSA-AES1.... Nginx ssl_protocols TLSv1.1 TLSv1.2; ssl_ciphers 'ECDHE-RSA-AES....' HAProxy ssl-default-bind-ciphers ECDHE-RSA-....
nailer 12y ago
I/CertSimple recently implemented the ciphers and TLS versions from this project as an npm module for node: see https://certsimple.com/blog/node-ssl-config https://certsimple.com/blog/node-ssl-config. The module is https://www.npmjs.com/package/ssl-config https://www.npmjs.com/package/ssl-config FYI the Moz ciphers are slightly better than the iojs ciphers (which are in turn a lot better than node 0.12), by prioritising GCM (which doesn't have any known attacks). Random other fact: since GCM is only available with 128 bit AES in most current browsers, Moz prefer 128 bit AES GCM over 256 bit AES with CBC. SSL Labs don't make the same distinction and require 256 bit crypto to get a perfect 'Cipher strength' score. Moz is right (and you should use their config), but the difference in opinion is interesting.
- jvehent 12y ago
  We've had a long and detailed discussion on the dev-tech-crypto mailing list about the preferred ordering for Firefox and, subsequently, for the server side guidelines. It's worth a read if you're into these sort of things http://www.mail-archive.com/dev-tech-crypto@lists.mozilla.org/msg11247.html http://www.mail-archive.com/dev-tech-crypto@lists.mozilla.or...
jvehent 12y ago
Hello HN, author of Server Side TLS [1] and co-maintainer of the conf generator here. Thanks for pushing this tool to the front page :) We've been improving our guidelines and this generator for the past year and a half, and while it in a pretty good shape, we always welcome comments and pull requests. One comment that we get very often regards the ordering of the recommended ciphersuite. We've made some choices that are documented in [2] such as, for example, preferring AES 128 to 256 or maintaining compatibility with CAMELLIA and DES-CBC3-SHA in the intermediate configuration. The best place to discuss these choices is probably the `talk` section of the wiki page [3]. [1] https://wiki.mozilla.org/Security/Server_Side_TLS https://wiki.mozilla.org/Security/Server_Side_TLS [2] https://wiki.mozilla.org/Security/Server_Side_TLS#Prioritization_logic https://wiki.mozilla.org/Security/Server_Side_TLS#Prioritiza... [3] https://wiki.mozilla.org/Talk:Security/Server_Side_TLS https://wiki.mozilla.org/Talk:Security/Server_Side_TLS
- IgorPartola 12y ago
  Feature request: 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, and it's not obvious that the configuration will change if you update these values.
  - gene_wood 12y ago
    @IgorPartola, sure thing (author of the conf generator here)! Go and and request it here ( https://github.com/mozilla/server-side-tls/issues https://github.com/mozilla/server-side-tls/issues ) and if you've got a lead on a canonical list of versions to work from that would help.
    - qrmn 12y ago
      You can find a list of nginx's versions simply from the download directory: http://nginx.org/download/ http://nginx.org/download/ - I know that much. By the way... DSS? Is anyone anywhere using DSS certificates on the internet anymore? (And would they still be 1024-bit?) Let alone anyone who might actually read configuration advice? I didn't see any hosts presenting one last time I ran a survey, but I wouldn't swear to that being complete (maybe they only present it to certain clients?).
TazeTSchnitzel 12y ago
Note that it's quite important to specify the server version. The output differs significantly. Compare nginx 1.0 and nginx 1.4, for instance.
blfr 12y ago
Is it safe to reuse the same Diffie-Hellman parameter across multiple domains with different certificates/keys? Not that this generator does it but if you host more than one site, it's more convenient to specify ssl_dhparam (also stapling, ssl_ciphers, etc.) in http{}, and only add certificate/key in server{}.
- IgorPartola 12y ago
  From what I read, yes. Your libssl already comes with a built-in one that's reused almost everywhere. If you want to generate your own, you can make it public, but realistically, if you don't trust your libssl to provide a good dhparam, why trust it to do anything else?
- jvehent 12y ago
  You can reuse the same diffie-hellman parameter. It's a public value anyway.
- AlyssaRowan 12y ago
  With TLS, it's not safe not to! Let me explain: Diffie-Hellman requires the group order to have at least one large prime factor: if it has only small prime factors, Silver–Pohlig–Hellman could recover keys, and that'll make you a sad panda. The easiest way to ensure this is to select a Sophie Germain prime q with 2q+1 also being prime (a "safe prime"), of about the right size. Any base g can then be used - almost always 2 - which then generates a subgroup of large prime order q, problem solved. The problem is that testing for safe primality is way too slow (as you may have noticed while running openssl dhparam!) for TLS clients to test DHE parameters presented to them. So… they don't. The risk is (I'm not totally clear if the Finished master-secret might prevent this, but there certainly isn't as much transcript hashing as I'd like!) an attacker could perhaps trick TLS parties into accepting bad parameters: too small; small factors; hell, maybe even composite. The solution is currently in draft, and is to have carefully-selected, standard Diffie-Hellman parameters that are known safe primes, starting from 2048-bit and going up (don't use <2048-bit, just… don't - please don't use 1024-bit!), using essentially the same negotiation as that used with the supported-curves extension. https://datatracker.ietf.org/doc/draft-ietf-tls-negotiated-ff-dhe/ https://datatracker.ietf.org/doc/draft-ietf-tls-negotiated-f... It's the same approach used by many other protocols, including SSH and IKE. I gather TLS 1.3 will remove the ability for server-defined Diffie-Hellman parameters completely for this reason. However, ECDHE is strongly technically superior to DHE: ECDHE using secp256r1 is at around ≈128-bit workfactor, equivalent to broadly ≈3072-bit DHE, but is much faster and smaller and doesn't have these problems (it can have different problems, but not these problems!). And coming up soon (via the CFRG sausage-machine) hopefully TLS will soon have djb's Curve25519 (the curve, and the key agreement function now known as X25519), which is roughly the same ≈128-bit strength but really fast - and much simpler to safely implement, even in constant-time. You probably want to use that or ECDHE, not DHE, which is a little hairier than it sounds. Indeed, quite a few people are using it already (notably OpenSSH).
pygy_ 12y ago
What's the point of the Haproxy entry? It doesn't support SSL by design, and can be coulpled with a dedicated SSL proxy if needed.
- skuhn 12y ago
  haproxy 1.5 supports SSL, and some people do use it as a frontend now. A single core process won't be able to keep up with SSL handshakes though, since one core can only do around 500 RSA 2048-bit sign/s. Session resumption will help a lot, but I would still want to distribute RSA operations over multiple cores.
  - damm 12y ago
    haproxy has had multiple process support for quite some time. ... It does introduce some unique side effects but it's possible also aesni should increase your ssl handshakes (if the cpu supports it)
    - duskwuff 11y ago
      > also aesni should increase your ssl handshakes (if the cpu supports it) SSL handshakes are primarily dependent on asymmetric key negotiation (i.e, RSA), which isn't accelerated by AESNI.
- jvehent 12y ago
  I use haproxy to terminate the TLS of a number of sites, I'd say the support is pretty stellar :) $ ./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 DHE-RSA-AES128-GCM-SHA256 TLSv1.2 DH,2048bits None 4 DHE-RSA-AES256-GCM-SHA384 TLSv1.2 DH,2048bits None 5 ECDHE-RSA-AES128-SHA256 TLSv1.2 ECDH,P-384,384bits secp384r1 6 ECDHE-RSA-AES128-SHA TLSv1,TLSv1.1,TLSv1.2 ECDH,P-384,384bits secp384r1 7 ECDHE-RSA-AES256-SHA384 TLSv1.2 ECDH,P-384,384bits secp384r1 8 ECDHE-RSA-AES256-SHA TLSv1,TLSv1.1,TLSv1.2 ECDH,P-384,384bits secp384r1 9 DHE-RSA-AES128-SHA256 TLSv1.2 DH,2048bits None 10 DHE-RSA-AES128-SHA TLSv1,TLSv1.1,TLSv1.2 DH,2048bits None 11 DHE-RSA-AES256-SHA256 TLSv1.2 DH,2048bits None 12 DHE-RSA-AES256-SHA TLSv1,TLSv1.1,TLSv1.2 DH,2048bits None 13 AES128-GCM-SHA256 TLSv1.2 None None 14 AES256-GCM-SHA384 TLSv1.2 None None 15 AES128-SHA256 TLSv1.2 None None 16 AES256-SHA256 TLSv1.2 None None 17 AES128-SHA TLSv1,TLSv1.1,TLSv1.2 None None 18 AES256-SHA TLSv1,TLSv1.1,TLSv1.2 None None 19 DHE-RSA-CAMELLIA256-SHA TLSv1,TLSv1.1,TLSv1.2 DH,2048bits None 20 CAMELLIA256-SHA TLSv1,TLSv1.1,TLSv1.2 None None 21 DHE-RSA-CAMELLIA128-SHA TLSv1,TLSv1.1,TLSv1.2 DH,2048bits None 22 CAMELLIA128-SHA TLSv1,TLSv1.1,TLSv1.2 None None 23 DES-CBC3-SHA TLSv1,TLSv1.1,TLSv1.2 None None Certificate: trusted, 2048 bit, sha256WithRSAEncryption signature TLS ticket lifetime hint: 300 OCSP stapling: supported Cipher ordering: server
kpcyrd 12y ago
This was my attempt to this problem: https://tls.li/ https://tls.li/. It's only a static page though. I've started it after ioerror stopped merging important PRs to duraconf.
ck2 12y ago
Nginx config is missing stapling.
- blfr 12y ago
  It is included for higher nginx versions.
Pirate-of-SV 12y ago
Do these configs yield A+ rating in Qualys' SSL Server Test[1]? [1] https://www.ssllabs.com/ssltest/ https://www.ssllabs.com/ssltest/
- dsl 12y ago
  These configs are a small part of what you need to get an A+. Much of it depends on server software and support, and certificate attributes. That said, I have used them as a starting point to get A+ on the SSLLabs test.
  - jcoby 12y ago
    AFAIK it's also impossible to get an A+ if you want to support older browsers and OSs (the intermediate and old settings from this site) due to BEAST. Seems like XP, Vista, and IE <= 9 were all affected by using the modern cypher suite from Mozilla (they all got a F). I wasn't able to find a way to do server-side BEAST mitigation that didn't involve re-enabling RC4 ciphers (which is a far worse option). SSLLabs automatically downgrades any site that doesn't do BEAST mitigation to an A-. I also was unable to get forward-secrecy working with all reference browsers using the intermediate setting.
    - jvehent 12y ago
      I'm not sure how you got those results. I am certainly getting an A+ with the intermediate configuration and HAProxy. https://www.ssllabs.com/ssltest/analyze.html?d=jve.linuxwall.info https://www.ssllabs.com/ssltest/analyze.html?d=jve.linuxwall...
      - jcoby 12y ago
        Turns out I was remembering wrong. The A- downgrade was from not supporting forward-secrecy in all reference browsers which is an issue with openssl than the recommended cipher suites.
        12y ago
Animats 12y ago
I see the input fields, but it doesn't do anything: Error: TypeError: i[1] is undefined ssl-config-generator:211:28
fmela 12y ago
There's also the TLS Cipher Suite Generator [1], for when you need fine-grained control over which ciphers you want to support. [1] http://geoff.greer.fm/ciphersuite/ http://geoff.greer.fm/ciphersuite/
teddyh 12y ago
It should be named the “Mozilla OpenSSL Configuration Generator”, since it only supports OpenSSL.
grizzles 12y ago
For Java: I made a little github project that transfers Mozilla's recommended OpenSSL cipher names into JSSE names: https://github.com/ericbets/rec-ciphers https://github.com/ericbets/rec-ciphers Feel free to incorporate it jvehent...
davidgerard 11y ago
This is shockingly useful and convenient, we used it ourselves just this week. Nice one!

333 points by mcdoug 12y ago

See also the accompanying Mozilla Wiki page: https://wiki.mozilla.org/Security/Server_Side_TLS https://wiki.mozilla.org/Security/Server_Side_TLS EDIT: Taken care of, thanks jvehent! Original: Interestingly, it looks like someone made three edits to the on March 16th (to make the same change to three different sections) and one of them was reverted but not the others. Can someone with a Mozilla Wiki account contact the maintainer for that page and ask them to verify that was intentional? I'd do it myself but I don't want to request an account (effectively) just to send a PM.

nerdy 12y ago
Don't forget about Zach Weinberg's offer to file bugs: https://www.owlfolio.org/htmletc/i-will-file-bugs-for-you/ https://www.owlfolio.org/htmletc/i-will-file-bugs-for-you/ (If it's intentional they could WONTFIX The bug)
jvehent 12y ago
Very good catch! Thanks for bringing it up. I had reverted the first one but missed the two others. Unfortunately, mediawiki only support two levels of access control: fully locked or fully open, so I need to manually police changes as they happen...

tootie 12y ago

This should be called HTTPS confuration generator. SSL was deprecated years ago.

nailer 12y ago
It should, or 'TLS/SSL'. But so many people - even in tech - still use 'SSL' as a synonym for 'PKI on the web' that it's better to be understood than correct (and yes it's a bit sad). Also: SSLv3 and TLSv1 are very similar: http://tim.dierks.org/2014/05/security-standards-and-name-changes-in.html http://tim.dierks.org/2014/05/security-standards-and-name-ch...
- hsivonen 12y ago
  When the IETF renames things, everyone is going to have a bad time. See also URI and IRI.
  - nocman 12y ago
    Wow, I've never even heard of IRI. Guess that proves your point :-D
- tootie 12y ago
  I think HTTPS has more name recognition than SSL.
e1ven 12y ago
Each of the tools involved refer to their the overall https configuration as SSL. Even if it's not the protocol which is being used, it's a reasonable choice for the tool name. Apache SSLProtocol all -SSLv2 -SSLv3 -TLSv1 SSLCipherSuite ECDHE-RSA-AES1.... Nginx ssl_protocols TLSv1.1 TLSv1.2; ssl_ciphers 'ECDHE-RSA-AES....' HAProxy ssl-default-bind-ciphers ECDHE-RSA-....

nailer 12y ago

I/CertSimple recently implemented the ciphers and TLS versions from this project as an npm module for node: see https://certsimple.com/blog/node-ssl-config https://certsimple.com/blog/node-ssl-config. The module is https://www.npmjs.com/package/ssl-config https://www.npmjs.com/package/ssl-config FYI the Moz ciphers are slightly better than the iojs ciphers (which are in turn a lot better than node 0.12), by prioritising GCM (which doesn't have any known attacks). Random other fact: since GCM is only available with 128 bit AES in most current browsers, Moz prefer 128 bit AES GCM over 256 bit AES with CBC. SSL Labs don't make the same distinction and require 256 bit crypto to get a perfect 'Cipher strength' score. Moz is right (and you should use their config), but the difference in opinion is interesting.

jvehent 12y ago
We've had a long and detailed discussion on the dev-tech-crypto mailing list about the preferred ordering for Firefox and, subsequently, for the server side guidelines. It's worth a read if you're into these sort of things http://www.mail-archive.com/dev-tech-crypto@lists.mozilla.org/msg11247.html http://www.mail-archive.com/dev-tech-crypto@lists.mozilla.or...

jvehent 12y ago

Hello HN, author of Server Side TLS [1] and co-maintainer of the conf generator here. Thanks for pushing this tool to the front page :) We've been improving our guidelines and this generator for the past year and a half, and while it in a pretty good shape, we always welcome comments and pull requests. One comment that we get very often regards the ordering of the recommended ciphersuite. We've made some choices that are documented in [2] such as, for example, preferring AES 128 to 256 or maintaining compatibility with CAMELLIA and DES-CBC3-SHA in the intermediate configuration. The best place to discuss these choices is probably the `talk` section of the wiki page [3]. [1] https://wiki.mozilla.org/Security/Server_Side_TLS https://wiki.mozilla.org/Security/Server_Side_TLS [2] https://wiki.mozilla.org/Security/Server_Side_TLS#Prioritization_logic https://wiki.mozilla.org/Security/Server_Side_TLS#Prioritiza... [3] https://wiki.mozilla.org/Talk:Security/Server_Side_TLS https://wiki.mozilla.org/Talk:Security/Server_Side_TLS

IgorPartola 12y ago
Feature request: 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, and it's not obvious that the configuration will change if you update these values.
- gene_wood 12y ago
  @IgorPartola, sure thing (author of the conf generator here)! Go and and request it here ( https://github.com/mozilla/server-side-tls/issues https://github.com/mozilla/server-side-tls/issues ) and if you've got a lead on a canonical list of versions to work from that would help.
  - qrmn 12y ago
    You can find a list of nginx's versions simply from the download directory: http://nginx.org/download/ http://nginx.org/download/ - I know that much. By the way... DSS? Is anyone anywhere using DSS certificates on the internet anymore? (And would they still be 1024-bit?) Let alone anyone who might actually read configuration advice? I didn't see any hosts presenting one last time I ran a survey, but I wouldn't swear to that being complete (maybe they only present it to certain clients?).

TazeTSchnitzel 12y ago

Note that it's quite important to specify the server version. The output differs significantly. Compare nginx 1.0 and nginx 1.4, for instance.

blfr 12y ago

Is it safe to reuse the same Diffie-Hellman parameter across multiple domains with different certificates/keys? Not that this generator does it but if you host more than one site, it's more convenient to specify ssl_dhparam (also stapling, ssl_ciphers, etc.) in http{}, and only add certificate/key in server{}.

IgorPartola 12y ago
From what I read, yes. Your libssl already comes with a built-in one that's reused almost everywhere. If you want to generate your own, you can make it public, but realistically, if you don't trust your libssl to provide a good dhparam, why trust it to do anything else?
jvehent 12y ago
You can reuse the same diffie-hellman parameter. It's a public value anyway.
AlyssaRowan 12y ago
With TLS, it's not safe not to! Let me explain: Diffie-Hellman requires the group order to have at least one large prime factor: if it has only small prime factors, Silver–Pohlig–Hellman could recover keys, and that'll make you a sad panda. The easiest way to ensure this is to select a Sophie Germain prime q with 2q+1 also being prime (a "safe prime"), of about the right size. Any base g can then be used - almost always 2 - which then generates a subgroup of large prime order q, problem solved. The problem is that testing for safe primality is way too slow (as you may have noticed while running openssl dhparam!) for TLS clients to test DHE parameters presented to them. So… they don't. The risk is (I'm not totally clear if the Finished master-secret might prevent this, but there certainly isn't as much transcript hashing as I'd like!) an attacker could perhaps trick TLS parties into accepting bad parameters: too small; small factors; hell, maybe even composite. The solution is currently in draft, and is to have carefully-selected, standard Diffie-Hellman parameters that are known safe primes, starting from 2048-bit and going up (don't use <2048-bit, just… don't - please don't use 1024-bit!), using essentially the same negotiation as that used with the supported-curves extension. https://datatracker.ietf.org/doc/draft-ietf-tls-negotiated-ff-dhe/ https://datatracker.ietf.org/doc/draft-ietf-tls-negotiated-f... It's the same approach used by many other protocols, including SSH and IKE. I gather TLS 1.3 will remove the ability for server-defined Diffie-Hellman parameters completely for this reason. However, ECDHE is strongly technically superior to DHE: ECDHE using secp256r1 is at around ≈128-bit workfactor, equivalent to broadly ≈3072-bit DHE, but is much faster and smaller and doesn't have these problems (it can have different problems, but not these problems!). And coming up soon (via the CFRG sausage-machine) hopefully TLS will soon have djb's Curve25519 (the curve, and the key agreement function now known as X25519), which is roughly the same ≈128-bit strength but really fast - and much simpler to safely implement, even in constant-time. You probably want to use that or ECDHE, not DHE, which is a little hairier than it sounds. Indeed, quite a few people are using it already (notably OpenSSH).

pygy_ 12y ago

What's the point of the Haproxy entry? It doesn't support SSL by design, and can be coulpled with a dedicated SSL proxy if needed.

skuhn 12y ago
haproxy 1.5 supports SSL, and some people do use it as a frontend now. A single core process won't be able to keep up with SSL handshakes though, since one core can only do around 500 RSA 2048-bit sign/s. Session resumption will help a lot, but I would still want to distribute RSA operations over multiple cores.
- damm 12y ago
  haproxy has had multiple process support for quite some time. ... It does introduce some unique side effects but it's possible also aesni should increase your ssl handshakes (if the cpu supports it)
  - duskwuff 11y ago
    > also aesni should increase your ssl handshakes (if the cpu supports it) SSL handshakes are primarily dependent on asymmetric key negotiation (i.e, RSA), which isn't accelerated by AESNI.
jvehent 12y ago
I use haproxy to terminate the TLS of a number of sites, I'd say the support is pretty stellar :) $ ./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 DHE-RSA-AES128-GCM-SHA256 TLSv1.2 DH,2048bits None 4 DHE-RSA-AES256-GCM-SHA384 TLSv1.2 DH,2048bits None 5 ECDHE-RSA-AES128-SHA256 TLSv1.2 ECDH,P-384,384bits secp384r1 6 ECDHE-RSA-AES128-SHA TLSv1,TLSv1.1,TLSv1.2 ECDH,P-384,384bits secp384r1 7 ECDHE-RSA-AES256-SHA384 TLSv1.2 ECDH,P-384,384bits secp384r1 8 ECDHE-RSA-AES256-SHA TLSv1,TLSv1.1,TLSv1.2 ECDH,P-384,384bits secp384r1 9 DHE-RSA-AES128-SHA256 TLSv1.2 DH,2048bits None 10 DHE-RSA-AES128-SHA TLSv1,TLSv1.1,TLSv1.2 DH,2048bits None 11 DHE-RSA-AES256-SHA256 TLSv1.2 DH,2048bits None 12 DHE-RSA-AES256-SHA TLSv1,TLSv1.1,TLSv1.2 DH,2048bits None 13 AES128-GCM-SHA256 TLSv1.2 None None 14 AES256-GCM-SHA384 TLSv1.2 None None 15 AES128-SHA256 TLSv1.2 None None 16 AES256-SHA256 TLSv1.2 None None 17 AES128-SHA TLSv1,TLSv1.1,TLSv1.2 None None 18 AES256-SHA TLSv1,TLSv1.1,TLSv1.2 None None 19 DHE-RSA-CAMELLIA256-SHA TLSv1,TLSv1.1,TLSv1.2 DH,2048bits None 20 CAMELLIA256-SHA TLSv1,TLSv1.1,TLSv1.2 None None 21 DHE-RSA-CAMELLIA128-SHA TLSv1,TLSv1.1,TLSv1.2 DH,2048bits None 22 CAMELLIA128-SHA TLSv1,TLSv1.1,TLSv1.2 None None 23 DES-CBC3-SHA TLSv1,TLSv1.1,TLSv1.2 None None Certificate: trusted, 2048 bit, sha256WithRSAEncryption signature TLS ticket lifetime hint: 300 OCSP stapling: supported Cipher ordering: server

kpcyrd 12y ago

This was my attempt to this problem: https://tls.li/ https://tls.li/. It's only a static page though. I've started it after ioerror stopped merging important PRs to duraconf.

ck2 12y ago

Nginx config is missing stapling.

blfr 12y ago
It is included for higher nginx versions.

Pirate-of-SV 12y ago

Do these configs yield A+ rating in Qualys' SSL Server Test[1]? [1] https://www.ssllabs.com/ssltest/ https://www.ssllabs.com/ssltest/

dsl 12y ago
These configs are a small part of what you need to get an A+. Much of it depends on server software and support, and certificate attributes. That said, I have used them as a starting point to get A+ on the SSLLabs test.
- jcoby 12y ago
  AFAIK it's also impossible to get an A+ if you want to support older browsers and OSs (the intermediate and old settings from this site) due to BEAST. Seems like XP, Vista, and IE <= 9 were all affected by using the modern cypher suite from Mozilla (they all got a F). I wasn't able to find a way to do server-side BEAST mitigation that didn't involve re-enabling RC4 ciphers (which is a far worse option). SSLLabs automatically downgrades any site that doesn't do BEAST mitigation to an A-. I also was unable to get forward-secrecy working with all reference browsers using the intermediate setting.
  - jvehent 12y ago
    I'm not sure how you got those results. I am certainly getting an A+ with the intermediate configuration and HAProxy. https://www.ssllabs.com/ssltest/analyze.html?d=jve.linuxwall.info https://www.ssllabs.com/ssltest/analyze.html?d=jve.linuxwall...
    - jcoby 12y ago
      Turns out I was remembering wrong. The A- downgrade was from not supporting forward-secrecy in all reference browsers which is an issue with openssl than the recommended cipher suites.
      - 12y ago

Animats 12y ago

I see the input fields, but it doesn't do anything: Error: TypeError: i[1] is undefined ssl-config-generator:211:28

fmela 12y ago

There's also the TLS Cipher Suite Generator [1], for when you need fine-grained control over which ciphers you want to support. [1] http://geoff.greer.fm/ciphersuite/ http://geoff.greer.fm/ciphersuite/

teddyh 12y ago

It should be named the “Mozilla OpenSSL Configuration Generator”, since it only supports OpenSSL.

grizzles 12y ago

For Java: I made a little github project that transfers Mozilla's recommended OpenSSL cipher names into JSSE names: https://github.com/ericbets/rec-ciphers https://github.com/ericbets/rec-ciphers Feel free to incorporate it jvehent...

davidgerard 11y ago

This is shockingly useful and convenient, we used it ourselves just this week. Nice one!