
Mozilla SSL Configuration Generator - mcdoug
https://mozilla.github.io/server-side-tls/ssl-config-generator/?1
======
jvehent
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#Prioritiza...](https://wiki.mozilla.org/Security/Server_Side_TLS#Prioritization_logic)
[3]
[https://wiki.mozilla.org/Talk:Security/Server_Side_TLS](https://wiki.mozilla.org/Talk:Security/Server_Side_TLS)

~~~
IgorPartola
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.

~~~
jvehent
It's a tricky thing to do because of all the possible versions of all the
possible web servers. The dropdown would end up being rather long, and require
maintaining a list in the code. And then there's distribution specific
backports, etc...

So we tabled this problem for now and went with a free field, but please do
open a github issue and we'll add look for ways to do it.

~~~
darklajid
Well, for the GP the 'feature' might be to allow a 'latest' version string
already?

Keeping track of each released version is probably a huge pain in the .. back.
But 'latest' (which isn't selected for openssl for me, for example: It shows
0.9.8.h atm) might already help to get the most fitting configuration for the
current set of software?

I assume you don't care about individual releases _unless_ they change the
configuration syntax/offer different cipher options?

~~~
jvehent
That's a valid point. I'd suggest capturing it in the issue
[https://github.com/mozilla/server-side-
tls/issues/39](https://github.com/mozilla/server-side-tls/issues/39)

There's a number of edge cases but we can probably find a middle ground that
works well enough for the general case.

------
nailer
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
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.or...](http://www.mail-archive.com/dev-tech-
crypto@lists.mozilla.org/msg11247.html)

------
MrRadar
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.

~~~
jvehent
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...

------
grizzles
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...

------
kpcyrd
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.

------
blfr
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{}.

~~~
AlyssaRowan
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 2 _q_ +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-f...](https://datatracker.ietf.org/doc/draft-ietf-tls-negotiated-
ff-dhe/) 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).

~~~
jvehent
This is a fantastic comment! Thank you for posting it.

I'd note that many of us don't have a choice and must still use 1024 bits DHE
parameters because of java 6 clients. It's unfortunate, and we hope they go
away very very soon so we can upgrade to 2048 bits.

------
Pirate-of-SV
Do these configs yield A+ rating in Qualys' SSL Server Test[1]?

[1] [https://www.ssllabs.com/ssltest/](https://www.ssllabs.com/ssltest/)

~~~
dsl
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
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
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...](https://www.ssllabs.com/ssltest/analyze.html?d=jve.linuxwall.info)

~~~
jcoby
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.

~~~
IgorPartola
I think it is impossible to max out the various bars in the bar graph with
these configurations (at least up to intermediate), but you can easily get A+
with latest stable nginx and intermediate config.

------
fmela
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/)

------
TazeTSchnitzel
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.

------
Animats
I see the input fields, but it doesn't do anything:

Error:

    
    
        TypeError: i[1] is undefined   ssl-config-generator:211:28

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

------
ck2
Nginx config is missing stapling.

~~~
blfr
It is included for higher nginx versions.

------
teddyh
It should be named the “ _Mozilla OpenSSL Configuration Generator_ ”, since it
only supports OpenSSL.

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

~~~
nailer
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-
ch...](http://tim.dierks.org/2014/05/security-standards-and-name-changes-
in.html)

~~~
hsivonen
When the IETF renames things, everyone is going to have a bad time. See also
URI and IRI.

~~~
nocman
Wow, I've never even heard of IRI.

Guess that proves your point :-D

------
pygy_
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
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
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
> 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.

