Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


[Checklist] A perfect SSL Labs rating
New on LowEndTalk? Please Register and read our Community Rules.

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;
{
«1

Comments

  • netomxnetomx Moderator, Veteran

    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.

    Thanked by 1netomx
  • 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.

    Thanked by 1geekalot
  • teknolaizteknolaiz Member
    edited October 2015

    @cidero said:
    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:

            gzip on;
            gzip_disable "msie6";
            gzip_vary on;
            gzip_proxied any;
            gzip_comp_level 6;
            gzip_buffers 16 8k;
            gzip_http_version 1.1;
            gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;
    

    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.

  • "AES256+EECDH:AES256+EDH:!aNULL" 
    

    will result in chrome giving the obsolete crypto warning in some cases. prefacing it with:

    EECDH+AESGCM:EDH+AESGCM
    

    solves that.

    Thanked by 3teknolaiz ehab geekalot
  • teknolaizteknolaiz Member
    edited October 2015

    @Raymii said:
    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

  • teknolaizteknolaiz Member
    edited October 2015

    @4n0nx said:
    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)

    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.

    Thanked by 1vimalware
  • Hidden_Refuge said: 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 :D

  • @mikho

    Can you change

    Use "AES256+EECDH:AES256+EDH:!aNULL" as your ciphers

    to

    Use "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH:!aNULL" as your ciphers

    Please?

  • rm_rm_ IPv6 Advocate, Veteran

    Try this for your ciphers:

    ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-DSS-AES256-SHA:ECDH-RSA-AES256-SHA:ECDH-ECDSA-AES256-SHA:AES256-SHA

    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&amp;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.

    Thanked by 2teknolaiz netomx
  • 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?

  • teknolaizteknolaiz Member
    edited October 2015

    @rm_ said:
    Try this for your ciphers:

    ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-DSS-AES256-SHA:ECDH-RSA-AES256-SHA:ECDH-ECDSA-AES256-SHA:AES256-SHA

    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&amp;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.

    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.

  • rm_rm_ IPv6 Advocate, Veteran
    edited October 2015

    Hidden_Refuge said: ERR_SPDY_INADEQUATE_TRANSPORT_SECURITY

    I don't support SPDY (// nor HTTP2) on my servers, maybe that's why no warning.

  • @rm_ said:
    I don't support SPDY 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.

  • joepie91joepie91 Member, Patron Provider
    edited October 2015

    @GM2015 said:
    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?

    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.

    Thanked by 14n0nx
  • 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.

    Thanked by 3netomx doghouch 4n0nx
  • I thought 128 bit AES has no vulnerabilities, while 256 bit AES has quite a few issues

  • rm_rm_ IPv6 Advocate, Veteran
    edited October 2015

    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.

    Thanked by 1netomx
  • @pechspilz said:
    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.

    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.

  • @Hidden_Refuge said:
    You can remove includeSubdomains to prevent this issues.

    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.

  • teknolaizteknolaiz Member
    edited October 2015

    @Raymii said:

    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.

  • @Hidden_Refuge said:
    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 domains by default you can leave that includeSubdomains. 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

    Use trusted/well known CAs only
    

    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.

  • @Raymii said:
    It's a good list. I do doubt the

    Use trusted/well known CAs only
    

    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.

    Thanked by 1perennate
  • teknolaizteknolaiz Member
    edited October 2015

    @Raymii said:
    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.

    Raymii said: Once browsers start supporting TLSA/DANE you can setup a self signed cert

Sign In or Register to comment.