All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
[Checklist] A perfect SSL Labs rating
100% on Certificate
- Use trusted/well known CAs only
- Use SHA256 or above (drop SHA1)
- Setup your cert correctly with a chain in proper order
100% on Protocol
- Use TLSv1.2 only
100% on Key Exchange
- Use 4096 Bit dhparams with 2048 Bit private keys
100% on Ciphers
- Use "AES256+EECDH:AES256+EDH:!aNULL" as your ciphers
- Set ssl_prefer_server_ciphers to on
OCSP Stapling
Setup and activate OCSP stapling on your server to serve client OCSP requests from your web server instead of letting clients sending their OCSP requests to the cert CA. This will protect the privacy of your visitors and the cert CA never gets to know that your visitors connected to your site.
SSL Sessions
- Set ssl_session_cache to atleast "shared:SSL:10m"
- Set ssl_session_timeout to atleast "10m"
HTTP Strict Transport Security (HSTS)
Setup and enable HSTS on your server (code below):
add_header Strict-Transport-Security "max-age=31536000; includeSubdomains; preload"; add_header X-Frame-Options DENY; add_header X-Content-Type-Options nosniff;
HTTP Public Key Pinning (HPKP)
Setup and activate HPKP on your server to prevent MITM attacks with forged certificates (eg: shitty Avast web protect and etc..).
Code:
add_header Public-Key-Pins 'pin-sha256="base64string"; max-age=63072000; includeSubDomains';
(base64string is the actual base64 string of your certificate, you can also add more pins for the CSR and etc..)
Compression
Disable compression for SSL protected sites by setting gzip to off for your SSL server block:
server { listen 443 ssl; ... gzip off; {
Comments
Why gzip off?
Because TLS compression attack. Although I believe in Nginx it is fixed serverside and so you actually can use gzip. Qualys SSL Labs says that my servers a protected against the compression attack although I actually have gzip globally enabled in nginx.conf.
Thanks for the information. The SSL Server Rating Guide by SSLabs explains the rating as well.
I would not recommend to disable gzip completely to defend against the BREACH attack since it would be a huge hit on performance. Check out other ways to mitigate this problem.
Well, I only considered it here due to the BREACH attack. However as in my previous reply I do in fact have gzip enabled globally in my nginx.conf like:
Qualys SSL Labs says my server is protected against BREACH even though above gzip is enabled "SSL/TLS compression No". I might simply remove the part about compression to avoid confusion.
See https://www.ssllabs.com/ssltest/analyze.html?d=diysrv.eu.org&s=2001:470:53c0:517e:0:0:0:5&hideResults=on
I am currently updating my dhparams to 4096 which takes some time so it still has 90% on key exchange.
will result in chrome giving the obsolete crypto warning in some cases. prefacing it with:
solves that.
Oops. Indeed. I missed that. Now if I only could edit the first post :<
It lowers cipher strength to 90% though.
I think you can't use AESGCM and 256bit at the same time, because browsers only support AES GCM 128bit -.-
So basically get 90 cipher score and satisfy Google or get 100 cipher score and have "obsolete" cryptography
oh and TLSv1.2 only locks out quite a few devices (cough android)
correctmeifiamwrong
90% are fine, too. Still a pretty good setup with A+ and the other stuff at 100%. Even with TLSv1.1 Android versions older than 4.4.2 are locked out with those ciphers. But it does not matter. Use a proper browser on Android and it works.
yeh yeh does not affect me at all, just saying use >4096bit private key and TLSv1.2 only and lots of android and (f/cr)apple devices are locked out.. if they don't use Firefox
@mikho
Can you change
to
Please?
Try this for your ciphers:
Getting 100% on Ciphers, no warnings in Chrome 44 at least; only got 95% at protocols, as I don't think I can disable/choose TLS versions in Lighttpd. https://www.ssllabs.com/ssltest/analyze.html?d=romanrm.net&s=2001:bc8:3829:100:0:0:0:1
Also always keep a close look on which clients you are excluding with your settings (in the "Handshake Simulation" section) and think about if you are really okay with that.
is there a point in getting a few extra points on ssl tests when you're not as large as for example amazon, google or some banks?
I'll be testing this and adjust a few things. A new version of this checklist will be on my blog as editing here is disabled after 1 hour (lame shit).
Edit: Chrome 46: ERR_SPDY_INADEQUATE_TRANSPORT_SECURITY with your ciphers.
I don't support SPDY (// nor HTTP2) on my servers, maybe that's why no warning.
I'm using HTTP/2. In addition to HTTP/1.1. So I guess browsers supporting SPDY/H2 will error with browser that preffer SDPY/H2 when those are enabled on the server.
Yes. Anything less than a perfect rating is effectively broken in some way. It's just that OpenSSL and friends are so goddamned hard to configure right, that legacy devices are a real problem, and that the out-of-the-box configuration isn't actually the configuration you want if you care about doing TLS right.
Just be careful when using Strict-Transport-Security because it's a one-way street, you can't go back, ever. And with includeSubdomains it will affect any current and future subdomains as well.
I thought 128 bit AES has no vulnerabilities, while 256 bit AES has quite a few issues
Well you can stop sending the header, then after it expires at everyone's browsers (in a year or whatever lifetime you used to be sending, typically longer ones are recommended), you can. That's not "ever". But generally, as soon as external websites, or even Google, start linking to you with https://, it'd be a bad idea to try to abandon having working HTTPS and go back to HTTP for whatever reason.
Well, this is purely a checklist .
You can remove includeSubdomains to prevent this issues. And then add additional HSTS rules for the subdomain vHosts that have SSL and leave HSTS out of the subdomains that have no SSL.
You can adjust many things as you need them. But these days I think it's better to have SSL on all pages. SEO and stuff.
Ok, so I couldn't really find 100% Cipher Strength ciphers that wouldn't keep breaking the god darn next generation HTTP protocols like SPDY or H2. So now it's 100%, 100%, 100% and 90% on the Qualys SSL Labs server test.
Here is the updated version of the checklist https://hiddenrefuge.eu.org/blog/almost-perfect-qualys-ssl-labs-rating-checklist
Had to wipe Wordpress because it recently failes on me (especially with PHP 5.6 and MariaDB 10.0 when using a installation from a previous system with much older versions of these components). Using MonstraCMS now.
RFC demands that if you've set HSTS and want to remove it, you need to set it to zero (0). So you have to keep the cert there until your earlier HSTS time expires. Otherwise browsers that visited earlier will give an error.
Well, no I don't want to remove it. I just meant that if you are about to setup SSL with HSTS but don't want to include all subdomains by default you can leave that includeSubdomains out. It works as far as I know and I tested it. Didn't read the RFC though.
That is true, you don't need includesubdomains or preload. If you do includesubdomains by accident, you are screwed for the time you set there.
Yes, that would really suck. What do you think about the updated version?
It's a good list. I do doubt the
My TURKTRUST or HONG KONG POST OFFICE, or any other cert signed by a trusted CA should be good enough. Before a party gets a trusted CA signing cert they have to be audited and make sure they do the right thing. Or at least, that should be the case.
You may as well just stop buying SSL at all and stop hosting.
It means that you should get certificates that are a) trusted in all browsers and ca-cert bundles and b) from providers that are known to be good. Although WoSign isn't less secure than any other CA...
Might as well use self signed, eh? But this shit world is so broken. You will get warnings, no green lock or badge.
Once browsers start supporting TLSA/DANE you can setup a self signed cert. Just put the signature in a TLSA record and be done with it. (My https://ssldecoder.org gives you a ready to use TLSA record). That will mean the death of CA's.
Awesome! I hope this will happen soon enough. No more broken SSL world with money sucking companies for security. Does Cloudflare support such records? I use CF for DNS.
And before everyone comes here with "you don't want to pay for SSL and think it's something you should have for free" bla bla talk. Just stop. You don't get it. You use encryption yourself and don't pay a cent for it so just stop.
It's a fundamental part of Internet/computer privacy. And why should I pay shit to get a green block or badge when I can generate a perfectly secure certificate myself? Pointless and obsolete CA system.
That won't realistically happen, right? I mean you'd get all the major certificate sellers opposing that.