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
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.
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?
I understand your point, but I am trying very hard to keep the guide as short as possible. The problem is that, if you start to be inclusive, the size balloons. I've written hundreds of pages on this topic so far (for my forthcoming book) and I don't yet feel I've covered everything sufficiently.
Further, people often want to deploy something that's just slightly different -- like your request to use only RSA keys, then DSA, and so on. I've come to realise that the only way to make everyone happy is to teach them to write configuration strings for themselves. That's how OpenSSL Cookbook (my free ebook) came about.
In addition, my blog (referenced above) has many specialist posts; I write them as I research stuff for my book.
To your last question: no, there's no reason to use ECDSA anywhere if you only have RSA keys... but I prefer to use the same configuration string everywhere. It makes maintenance much easier.
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?
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.
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.
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.)
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.
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.
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.
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.
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.
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.
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!
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.
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.
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.
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?
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.
> 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.
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.
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.
> 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.
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. :/
If you want the short version for Apache, Nginx and OpenSSL: 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.