6 ms·

SSL/TLS Deployment Best Practices v1.3

152 points by ivanr 13y ago

devicenull 13y ago
> 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 13y ago
  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 13y ago
    I don't expect we'll expect elliptic curve support until RHEL 7.
- baudehlo 13y ago
  Also you need to support SSL as well as TLS if you want to support IE6, and surprisingly - Stripe webhooks (see my blog for details).
  - jlgaddis 13y ago
    It's easy to dismiss IE6 -- and even IE6 on XP -- assuming that no one uses them anymore. I work at an ISP and am converting a number of Windows servers to Linux servers and adding SSL/TLS support as I go along. I've done some analysis on our own log files and was amazed at the astounding number of users still running IE6 and/or XP. :/
- regecks 13y ago
  > Too bad CentOS is still stuck on TLS 1.0 and apparently will be for quite some time Perhaps on a vanilla install, but it is not impossible or even difficult to build OpenSSL 1.0.1e+ for RHEL(s). Either build yourself or use Avixo[1]. Granted it's a pain in the ass/maybe not permitted in some environments, but doable. [1] http://rpm.axivo.com/ http://rpm.axivo.com/
- ivanr 13y ago
  The bigger problem with CentOS (Red Hat) is that they do not support Elliptic Curves, which are necessary for Forward Secrecy. If you're using Apache, you can compile your own from source, using static linking against OpenSSL. That way, you can have the latest versions of both. I have a blog post that describes the process: http://blog.ivanristic.com/2013/08/compiling-apache-with-static-openssl.html http://blog.ivanristic.com/2013/08/compiling-apache-with-sta... While you're there, you might also want to patch Apache to support configurable DH parameters: http://blog.ivanristic.com/2013/08/increasing-dhe-strength-on-apache.html http://blog.ivanristic.com/2013/08/increasing-dhe-strength-o...
oleganza 13y ago
Surprisingly easy and quick read for such topic. Recommend.
erichurkman 13y ago
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.ycombinator.com https://www.ssllabs.com/ssltest/analyze.html?d=news.ycombina...
- ajtaylor 13y ago
  Thanks for the link. I've sent an email to our $work hosting provider with some ideas to upgrade our TLS support, among other things.
- prutschman 13y ago
  Are you aware of any similar tools for testing non-HTTP TLS services, such as IMAP or SMTP?
  - erichurkman 13y ago
    Not to my knowledge; a full testing tool for IMAP, SMTP, TLS, DKIM, and DNSSEC would have been amazing a year or so ago when I was still maintaining mail servers!
  - ivanr 13y ago
    Yes, try CheckTLS: http://www.checktls.com/ http://www.checktls.com/ Although, ironically, their web site does not seem to use TLS properly, not enforcing encryption on login and using mixed content.
  - jlgaddis 13y ago
    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.
dguido 13y ago
Reproducing an earlier comment I made on Reddit (http://www.reddit.com/r/netsec/comments/1mn2nk/ssltls_deployment_best_practices/ccarooh http://www.reddit.com/r/netsec/comments/1mn2nk/ssltls_deploy...): If you want the short version for Apache, Nginx and OpenSSL: http://blog.ivanristic.com/2013/08/configuring-apache-nginx-and-openssl-for-forward-secrecy.html http://blog.ivanristic.com/2013/08/configuring-apache-nginx-... 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 13y ago
  Why do you have both "RC4" and "!RC4" in the second string?
  - aroch 13y ago
    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
  - ivanr 13y ago
    It makes sense in the context of (my) blog post. I start by showing one configuration for those who wish to use RC4 to mitigate the BEAST attack (better suites are used for the clients that support TLS 1.2). In the subsequent section, for those who do not care about BEAST and don't like RC4, I show how they can simply add !RC4 to the end. The advantage is that the configuration string remains the same.
- e12e 13y ago
  I was a bit disappointed that the guide didn't include cipher suite strings/openssl config strings for the recommendations given (or did I miss it?). I'd like to see the minimal strings needed for a) only tls 1.2 with RSA keys, b) like a, with DSA -- with only forward secrecy enabled -- and a' and b' with fall back to no forward secrecy. I don't suppose there's any reason to allow eg: EECDH+ECDSA+AESGCM if you only have certificates based on RSA?
casca 13y ago
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)
fauigerzigerk 13y ago
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?
- deleted 13y ago
  [deleted]
- antocv 13y ago
  Thats why you host it on-site and not with a hosting provider. Any company worth its salt will be able to run one or two servers at its location under its supervision. Hosting providers are for those small php sites that depend on AdWords for their income.
  - cmircea 13y ago
    Try telling Netflix that.
    - antocv 13y ago
      How come Google can do it? Why cant Netflix?
      - cmircea 13y ago
        Cause Google has mostly equal traffic levels 24/7/365, while Netflix has huge spikes, which are impossible to efficiently sustain with bare metal hardware. Also, Google's revenue is more than 10 times that of Netflix, and they have highly custom software and hardware.
- 13y ago
jvehent 13y ago
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
buro9 13y ago
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 13y ago
  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 13y ago
    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 13y ago
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_Strict_Transport_Security https://developer.mozilla.org/en-US/docs/Security/HTTP_Stric...
- ivanr 13y ago
  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.

152 points by ivanr 13y ago

> 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 13y ago
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 13y ago
  I don't expect we'll expect elliptic curve support until RHEL 7.
baudehlo 13y ago
Also you need to support SSL as well as TLS if you want to support IE6, and surprisingly - Stripe webhooks (see my blog for details).
- jlgaddis 13y ago
  It's easy to dismiss IE6 -- and even IE6 on XP -- assuming that no one uses them anymore. I work at an ISP and am converting a number of Windows servers to Linux servers and adding SSL/TLS support as I go along. I've done some analysis on our own log files and was amazed at the astounding number of users still running IE6 and/or XP. :/
regecks 13y ago
> Too bad CentOS is still stuck on TLS 1.0 and apparently will be for quite some time Perhaps on a vanilla install, but it is not impossible or even difficult to build OpenSSL 1.0.1e+ for RHEL(s). Either build yourself or use Avixo[1]. Granted it's a pain in the ass/maybe not permitted in some environments, but doable. [1] http://rpm.axivo.com/ http://rpm.axivo.com/
ivanr 13y ago
The bigger problem with CentOS (Red Hat) is that they do not support Elliptic Curves, which are necessary for Forward Secrecy. If you're using Apache, you can compile your own from source, using static linking against OpenSSL. That way, you can have the latest versions of both. I have a blog post that describes the process: http://blog.ivanristic.com/2013/08/compiling-apache-with-static-openssl.html http://blog.ivanristic.com/2013/08/compiling-apache-with-sta... While you're there, you might also want to patch Apache to support configurable DH parameters: http://blog.ivanristic.com/2013/08/increasing-dhe-strength-on-apache.html http://blog.ivanristic.com/2013/08/increasing-dhe-strength-o...

oleganza 13y ago

Surprisingly easy and quick read for such topic. Recommend.

erichurkman 13y ago

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.ycombinator.com https://www.ssllabs.com/ssltest/analyze.html?d=news.ycombina...

ajtaylor 13y ago
Thanks for the link. I've sent an email to our $work hosting provider with some ideas to upgrade our TLS support, among other things.
prutschman 13y ago
Are you aware of any similar tools for testing non-HTTP TLS services, such as IMAP or SMTP?
- erichurkman 13y ago
  Not to my knowledge; a full testing tool for IMAP, SMTP, TLS, DKIM, and DNSSEC would have been amazing a year or so ago when I was still maintaining mail servers!
- ivanr 13y ago
  Yes, try CheckTLS: http://www.checktls.com/ http://www.checktls.com/ Although, ironically, their web site does not seem to use TLS properly, not enforcing encryption on login and using mixed content.
- jlgaddis 13y ago
  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.

dguido 13y ago

Reproducing an earlier comment I made on Reddit (http://www.reddit.com/r/netsec/comments/1mn2nk/ssltls_deployment_best_practices/ccarooh http://www.reddit.com/r/netsec/comments/1mn2nk/ssltls_deploy...): If you want the short version for Apache, Nginx and OpenSSL: http://blog.ivanristic.com/2013/08/configuring-apache-nginx-and-openssl-for-forward-secrecy.html http://blog.ivanristic.com/2013/08/configuring-apache-nginx-... 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 13y ago
Why do you have both "RC4" and "!RC4" in the second string?
- aroch 13y ago
  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
- ivanr 13y ago
  It makes sense in the context of (my) blog post. I start by showing one configuration for those who wish to use RC4 to mitigate the BEAST attack (better suites are used for the clients that support TLS 1.2). In the subsequent section, for those who do not care about BEAST and don't like RC4, I show how they can simply add !RC4 to the end. The advantage is that the configuration string remains the same.
e12e 13y ago
I was a bit disappointed that the guide didn't include cipher suite strings/openssl config strings for the recommendations given (or did I miss it?). I'd like to see the minimal strings needed for a) only tls 1.2 with RSA keys, b) like a, with DSA -- with only forward secrecy enabled -- and a' and b' with fall back to no forward secrecy. I don't suppose there's any reason to allow eg: EECDH+ECDSA+AESGCM if you only have certificates based on RSA?

casca 13y ago

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)

fauigerzigerk 13y ago

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?

deleted 13y ago
[deleted]
antocv 13y ago
Thats why you host it on-site and not with a hosting provider. Any company worth its salt will be able to run one or two servers at its location under its supervision. Hosting providers are for those small php sites that depend on AdWords for their income.
- cmircea 13y ago
  Try telling Netflix that.
  - antocv 13y ago
    How come Google can do it? Why cant Netflix?
    - cmircea 13y ago
      Cause Google has mostly equal traffic levels 24/7/365, while Netflix has huge spikes, which are impossible to efficiently sustain with bare metal hardware. Also, Google's revenue is more than 10 times that of Netflix, and they have highly custom software and hardware.
13y ago

jvehent 13y ago

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

buro9 13y ago

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 13y ago
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 13y ago
  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 13y ago

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_Strict_Transport_Security https://developer.mozilla.org/en-US/docs/Security/HTTP_Stric...

ivanr 13y ago
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.