How To: Get an A+ rating on Qualys SSL Labs with Nginx without breaking loads of browsers

[lewisgoddard]

Since I use Nginx over Apache, I don’t have the same native things available with the current demo, and as I work to demonstrate its capabilities for our next-generation servers, I developed a few things I have open-sourced to smooth out the process.

1st, I have a cli.ini for letsencrypt that uses a larger key size. 2048 is the standard, and quite common, but I try to keep ahead of the curve unless that’s detrimental in some way.

2nd, there is Generate.sh. Running this makes a session ticket key, as well as a 4096 bit DHParam. This takes quite a while, and does break older Java and IE implementations, but works fine from IE 9 and above.

A .bash_aliases file contains the function definition for renew-ssl which can be run as renew-ssl example.com or renew-ssl example.com -d www.example.com

Finally there is the nginx.conf file, which contains basic setup, extensionless PHP, SSL definitions for auto-updated keys, session tickets, DH Parameters, Protocols, and various cipher lists for various degrees of balance between security and compatibility. It also includes SSL Stapling, OSCP, HSTS, and SPDY, although I hope to replace that with HTTP/2 soon.

It is possible to get 100% throughout with this script, but it breaks so many browsers the default setting is 90% minimum (shown above), which only fails on IE 6 and below (urgh) and Java 6 (which is now two versions behind, but still very popular).

Ultimately the final configuration is up to you, and it relies on the rest of your system being secure too, but this is where I will be starting from from here on in.

[lewisgoddard]

This is my personal site test, which comes in at 100/95/100/100, but doesn’t work on Android 2 or XP, or any version of Java.

My todo list:

• HTTP/2 [DONE]
• Renewal without taking down Nginx [DONE]
• Public Key Pinning (Difficult)

[tlussnig]

Hi i also have 4*100 but does not use nginx and personal i decided that i can live with the blocked android and xp browser.
Xp only with IE. And on the other hand who use java without unlimited policy ? So java works with the side.

[eva2000]

scoring 100% doesn’t mean much if you’re sacrificing potential web site performance by jumping from 2048bit to 4096bit

just look what happens to your SSL negotiation overhead - almost 1 second penalty at 916ms

from UK

from NY

1635ms overhead

[lewisgoddard]

It also breaks several phone browsers, most Windows that isn’t the absolute latest version. That’s a bit of an issue.

[lewisgoddard]

I’m going to start off by saying that I hate webpagetest.org. I’m sure they mean well, but their service is under-developed and consistently report massive load times. I have had dozens of clients reference them despite in-house data showing real users connecting in far less time. 4 seconds on a dozen tiny images? Is it doing 2 at a time still?

I assume this is due to underpowered servers, but my entire page loads in less than that negotiation time, on my old Android phone circa 2011. Pingdom report SSL negotiations lasting 45ms and 38ms, which is only on the first pageload. DNS took way longer.

CertSimple have a wonderful chart for some test times, even though they point out that since they provide free re-issue of certificates they don’t actually recommend 4096 bit yet.

Finally:

• Debian’s guide to key creation currently recommends 4096 bit keys (although it doesn’t explicitly mandate their use)
• Fedora’s archive keys are all 4096 bit keys.
• The CACert.org project has developed a 4096 bit root

[eva2000]

@lewisgoddard

I'm going to start off by saying that I hate webpagetest.org. I'm sure they mean well, but their service is under-developed and consistently report massive load times. I have had dozens of clients reference them despite in-house data showing real users connecting in far less time. 4 seconds on a dozen tiny images? Is it doing 2 at a time still?

yes webpagetest.org can also be off if their test location server isn't working right.. but remember it also is geographically relative too for both wpt and pingdom and remember wpt can use newer browser versions while pingdom stuck on older browsers too i.e. chrome 39 vs chrome 46

[lewisgoddard]

I find that browser versions after IE 9 and especially IE 10 or 11 matter less and less, they are neither significantly faster nor more improved over time, only gradually altering features.

Also, I expanded on my previous post a little, since I found the graph I was looking for.

[eva2000]

well big one would be web browser’s support for HTTP/2 and brotli compression in terms of performance so browser versions do matter

[lewisgoddard]

HTTP/2 is a big thing I’ve been pushing but none of my web-servers have it yet, although most have the older SPDY spec, as for Brotli I’m unsure but I doubt it unless it is included in a normal Ubuntu/Nginx stack.

[eva2000]

http://caniuse.com/#feat=brotli it’s offered as nginx module https://github.com/google/ngx_brotli/ so needs compiling. My nginx server 1.9.7 supports ngx_brotli and looks promising on Firefox 44+ 20-40% better compression that gzip/deflate encoding

oh and have you tested mobile client/browser and mobile 3G/4G speed differences for 4096bit ?

[lewisgoddard]

So based on current usage it basically isn’t supported, and I don’t compile for production environments. That sounds like an exciting improvement, that works in parallel with HTTP/2?

I test over 3G, and throttled WiFi when I don’t have it.

[eva2000]

yeah brotli only activates over HTTPS so works with HTTP/2

on non-HTTPS connections falls back to gzip encoding

[tlussnig]

@eva2000 i also tested my site with webpagetest.org and it was really interesting that each selected browser equal if it was Android 5/7 or other always take around 1,2sec for SSL-Handshake that is an time that i can in no way confirm
from my own experience. I Own an N5 and it take less then 1sec to show the page. And also Chrome on Windows does not need 1sec. At least the sslHandhsake signature matches the named browsers.

[tlussnig]

@lewisgoddard i know that it break several phone browsers. But since all my hardware is supported, and you can always install alternative browser i see no reason for my homepage to support unsafe setup. Since i am not forced by some company rule to support less secure browsers i decided to go with the best security as long as up to date browsers support them.

[eva2000]

yeah probably needs more testing though, i know for my own sites with 2048bit SSL WPT reports between 70-130ms SSL negotiation times and never seen anything as high as the above ones and majority of my servers are low end VPS servers

[selecadm]

[quote=“lewisgoddard, post:1, topic:4582”]
2nd, there is Generate.sh. Running this makes a session ticket key, as well as a 4096 bit DHParam. This takes quite a while, and does break older Java and IE implementations, but works fine from IE 9 and above.
[/quote]IE on Windows Phone 8.0 and 8.1 (without update) doesn’t fail because of 4096-bit DH, but does because of 521-bit ECDH server-side and no DHE_RSA support client-side.

Notice the clients below negotiating DHE_RSA despite supporting ECDHE_RSA + GCM:
— Chrome
— IE and Edge on Windows 10
— Yahoo Slurp

It’s because they support secp256r1 and secp384r1, but you force secp521r1.
384-bit ECDH is enough for 100% key exchange.

[eva2000]

@selecadm

It's because they support secp256r1 and secp384r1, but you force secp521r1.384-bit ECDH is enough for 100% key exchange.

nice eye and info there

[tlussnig]

@eva2000 you can see that https://www.ssllabs.com/ssltest/analyze.html?d=suche.org support chrome and slurp.
With 4*100 Maybe you also want to add CHACHA20_POLY1305

[eva2000]

@tlussnig

Maybe you also want to add CHACHA20_POLY1305

already have CHACHA20 as I use LibreSSL 2.2.4