
SSL/TLS Deployment Best Practices v1.3 - ivanr
https://www.ssllabs.com/projects/best-practices/
======
dguido
Reproducing an earlier comment I made on Reddit
([http://www.reddit.com/r/netsec/comments/1mn2nk/ssltls_deploy...](http://www.reddit.com/r/netsec/comments/1mn2nk/ssltls_deployment_best_practices/ccarooh)):

If you want the short version for Apache, Nginx and OpenSSL:
[http://blog.ivanristic.com/2013/08/configuring-apache-
nginx-...](http://blog.ivanristic.com/2013/08/configuring-apache-nginx-and-
openssl-for-forward-secrecy.html)

SSLCipherSuite "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384
EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH
EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS"

For those who don't give a shit if Windows XP / IE can establish an SSL
connection with you, here's a cipher string without RC4.

SSLCipherSuite "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384
EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 EECDH
EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS !RC4"

More details, including the configurations for SSL/TLS protocol versions, can
be found at the link above.

~~~
oleganza
Why do you have both "RC4" and "!RC4" in the second string?

~~~
aroch
As far as I understand it, the server will respond RC4 ciphered negotiations
by saying "sorry , what?" instead of "fuck off" if you include it in both the
accepted and refused lists. In doing so, it'll force a renegotiation over an
accepted cipher combo

------
fauigerzigerk
What gives me the most headaches is how to protect my private key. The key has
to be accessible to all web servers at all times, which usually means it is
stored in clear text on the hoster's machines and automatically backed up on
media that is stored who knows where.

I have no control over who can access it there. I'm not running the data
center. I'm not hiring the staff. I'm not deciding on any monitoring. I
basically just throw that key over the fence hoping the hoster will keep it
secured.

And then I turn around and tell my users, trust me, only me and you can see
the data we're exchanging. Isn't that one big lie? How do I handle this in a
less haphazard way?

~~~
ivanr
If you want that level of security, your only solution is to own all your
servers and have very strong physical security. The problem is that most web
sites cannot justify the expense.

If you follow all the recommendations from the guide -- which is not that
hard, in my opinion -- your (TLS) security will be among, say, 0.1% of the
sites out there, or better.

Going back to the key protection: for the rest of us, the best you can do is
always use a password with your key. That won't protect it on the web server,
but it will protect it when you back it up independently.

Then, find a CA that allows unlimited key/certificate regeneration and rotate
your private key (and revoke the previous certificate) every month, and every
time your staff changes.

~~~
taway2012
The TaoBao version of nginx has a patch to send the private key through the
network to the server. IIRC. In that case, it won't be lying around in
plaintext on your server's disk.

I will edit this post with a link if I can find it again.

I run a small number of servers, so I've password-protected my private keys.

~~~
ivanr
That's interesting, but I don't think it raises the bar a lot. Private keys
are still kept in process memory, from where they can be easily extracted by
the attacker who can attach to the process.

A great innovation would be to have web server fork a special process that
will only handle private keys. That other process would be running under a
different username. Bonus points if a separate process can be deployed for
each key. (It's possible to achieve a similar effect by running decryption in
a separate proxy layer.)

~~~
taway2012
My two cents is that requiring the ability to snoop on a running process is a
significant extra hurdle compared to simply reading the filesystem.

Especially for virtual machines which almost everybody is running on these
days. An attacker can simply read the disk from _under_ the OS.

Although I can understand why you might think it's not significant enough. I
do agree that storing private keys in a separate user's process can help with
security.

------
jvehent
This is the ciphersuite that we recommend at Mozilla. We're working on
publishing our work on SSL/TLS recommendations. It's very similar to Qualys's
work.

ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-
AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384: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-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:AES128-GCM-
SHA256:AES256-GCM-SHA384:ECDHE-RSA-RC4-SHA:ECDHE-ECDSA-
RC4-SHA:RC4-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!3DES:!MD5:!PSK

------
erichurkman
Qualys SSL Labs also has a great online tool that allows you to quickly
analyze your configuration changes [1]. Highly recommended and a great
resource if you're just setting up your SSL certificate, too, to make sure you
have it set correctly.

[1]
[https://www.ssllabs.com/ssltest/analyze.html?d=news.ycombina...](https://www.ssllabs.com/ssltest/analyze.html?d=news.ycombinator.com)

~~~
prutschman
Are you aware of any similar tools for testing non-HTTP TLS services, such as
IMAP or SMTP?

~~~
jlgaddis
I've found that some of these will work with, e.g. Dovecot's IMAPS daemon,
just by appending ":993" to the hostname.

Yesterday I found one that would only work on port 443, but it was a simple
matter of creating two iptables rules: one to permit incoming IP packets to
443/TCP and the other to redirect them to 993/TCP.

------
casca
Ivan has consistently provided excellent resources for configuring SSL. The
docs and analyzer have made it so much easier to get people to take the steps
to fix their SSL setup.

He also has a book that is coming out and will presumably be excellent, but
you can get the OpenSSL Cookbook now for free:
[https://www.feistyduck.com/books/bulletproof-ssl-tls-and-
pki...](https://www.feistyduck.com/books/bulletproof-ssl-tls-and-pki/)

(Not affiliated with Ivan or the book, just a fan)

------
buro9
I would love to see a github hosted repository that demonstrated the best
practises as default configs for Apache and Nginx.

Such a config would be heavily commented and include links to the source
advisory notices and explain why.

This way we would have something we could easily implement from a config
perspective, have notifications when the advisory changes, and also be
educated about what various things in the config would do.

Weakening SSL/TLS is surprisingly easy with the wrong options, and instead it
should be really easy to get it right.

~~~
ivanr
Here you go:
[https://github.com/ioerror/duraconf](https://github.com/ioerror/duraconf)

I don't know how good it is because I have not looked.

~~~
buro9
A quick glance at the Nginx config says that it doesn't reflect the level of
consideration in the OP's linked PDF.

This is why I'd like the SSLLabs + Mozilla + other parties to work together to
produce a single set of configs that reflect the combined best practise. To
ensure that this is a complete thing.

------
slashdotaccount
I have a question about HSTS (Strict-Transport-Security).

This quote is from "Mozilla Developer Network" [1]:

"The HTTP Strict Transport Security feature lets a web site inform the browser
that it should never load the site using HTTP, and should automatically
convert all attempts to access the site using HTTP to HTTPS requests instead."

Does this mean that the browser stores somewhere that the site foo.com must be
opened only in HTTPS mode? And what if I don't want the browser to keep any
information about any site - its favicon, its cookies, local storage, indexed
databases or HSTS information, nothing, how can I achieve this? Does the
private mode in Firefox do this?

[1] [https://developer.mozilla.org/en-
US/docs/Security/HTTP_Stric...](https://developer.mozilla.org/en-
US/docs/Security/HTTP_Strict_Transport_Security)

~~~
ivanr
There are two ways in which HSTS is deployed. First, it is activated when the
HSTS response header is sent by the site. Normally, the browser will remember
the HSTS response for a period of time. Clearly, a correctly implemented
private mode breaks this, and thus breaks HSTS.

However, Google and Mozilla are also pre-loading HSTS information. There was a
blog post from Mozilla some months ago, describing how they have a crawler
that detects long-term HSTS configuration in popular sites and then ships that
information with browser releases. In this case, HSTS will work as intended
even in private mode.

------
oleganza
Surprisingly easy and quick read for such topic. Recommend.

------
devicenull
> TLS v1.2 should be your main protocol. This version is superior because it
> offers important features that are unavailable in earlier protocol versions.
> If your server platform (or any intermediary device) does not support TLS
> v1.2, make plans to upgrade at an accelerated pace. If your service
> providers do not support TLS v1.2, require that they upgrade.

Too bad CentOS is still stuck on TLS 1.0 and apparently will be for quite some
time.

~~~
McGlockenshire
Given that Redhat is beginning to backport a larger number of newer platforms
[1], I'd expect them to eventually include newer Apache & mod_ssl editions.
Hopefully the CentOS folks will be able to pick this stuff up, or duplicate
the functionality if RH isn't open-sourcing the bits that make it work.

1: [http://developerblog.redhat.com/2013/09/17/shared-dev-
rhscl/](http://developerblog.redhat.com/2013/09/17/shared-dev-rhscl/)

~~~
jlgaddis
I don't expect we'll expect elliptic curve support until RHEL 7.

