Since you use Apache, several curves are supported. Similar for Microsoft IIS.
The last time I tried to use several curves on nginx, it didn’t even start.
SSL Labs dev exposes: https://dev.ssllabs.com/ssltest/analyze.html?d=suche.org
1 Like
does a number on ssl negotiation times though - 837ms to 1021ms for SSL negotiation alone from WPT tests
the SSL negotiation time there is almost what it takes for my sites to visually render above fold completely over HTTPS via HTTP/2 with normal RSA 2048bit SSL certs or ECC 256bit SSL certs !
curl -I https://suche.org -v
* About to connect() to suche.org port 443 (#0)
* Trying 130.117.188.81... connected
* Connected to suche.org (130.117.188.81) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
* NSS error -5938
* Closing connection #0
* SSL connect error
curl: (35) SSL connect error
i fully know that curl is not supported. But the side should be visible for users an google search engine.
Not for each old scripted tool. So for curl, wget, php etc… if they are not supported in an great side effect in my eyes 
ah but some web apps/code i.e. php and monitoring services use such like curl etc
but yeah to each his own 
Thx to eva2000 for tutorial,
i’'m on debian 8, nginx 1.9.7 with http2, chacha20poly1305 added. ISPconfig 3.0.5.4p8
1 site, A+ 100/95/90/90 , LE key RSA 4096,fail: ie6/xp, java 6u45
2 site, A+ 100/95/90/90 , LE key RSA 4096,fail: ie6/xp, java 6u45 + andoid2.3 , IE8/xp
no difference in configuration 
1 Like
actually tutorial in this thread is @lewisgoddard's 
Hi @tlussnig,
I go for 100/95/100/90 for servers with current browser support (TLS 1.0 to TLS 1.2) and 100/100/100/90 for servers with modern browser support (just TLS 1.2). I don’t count the black sheep in the herd (the 90 instead of 4th time 100) because I give GCM more value with current browsers than using just 256 bit ciphers, especially for TLS-1.2-only where I don’t support any CBC cipher at all.
My configuration sections for nginx with LibreSSL follow. First a file called ssl_current_security.conf. Note that I document with a small number of words why I’m enabling a specific key or a pattern.
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
# in addition to highly secure CHACHA20 and GCM ciphers for TLSv1.2,
# supported by most current browsers, we enable
# * ECDHE+AES256+SHA384 for older iOS/OS X and older IE (TLSv1.2)
# * ECDHE+AES256+SHA for older Android and even older IE (requires TLSv1)
ssl_ciphers 'ECDHE+CHACHA20:ECDHE+AESGCM:ECDHE+AES256+SHA384:ECDHE+AES256+SHA';
# note: In case we're still using an old RSA key we could also enable
# DHE+AESGCM right behind ECDHE+AESGCM to upgrade some older IE to use a
# GCM cipher instead of CBC, but will introduce DHE by that. Enabling
# DHE requires us to take care of our DH primes (a.k.a. dhparams) and
# to trust in DHE more than in ECDHE with CBC.
Now that’s my ssl_modern_security.conf:
ssl_protocols TLSv1.2;
# only use highly secure CHACHA20 and GCM ciphers for TLSv1.2
ssl_ciphers 'ECDHE+CHACHA20:ECDHE+AESGCM';
# note: In case we're still using an old RSA key we could also enable
# DHE+AESGCM right behind ECDHE+AESGCM to support some older IE,
# but will introduce DHE by that. Enabling
# DHE requires us to take care of our DH primes (a.k.a. dhparams) and
# to trust in DHE.Hi good decision there is an long discussion on ssllabs what is more secure
- AES-128-GCM := No CBC problem and no known attack that reduce the strength.
- AES-256-CBC := Beast can be circumvented but there are attacks that reduce if to effective size only few above 128 bit
More or less common thinking is that GCM is equal or better and this also should be reflected in some future versions of the test.
You are saying that changing between the following lines increases compatibility while keeping to the 100% rating? I've added that as an alternative.
ssl_ecdh_curve secp521r1;
ssl_ecdh_curve secp384r1;
I’ve just added a new file for people running Nginx with HTTP/2 and PHP 7.0
I’m pretty happy with the compatibility of the intermediate version of the generated configuration from the Mozilla SSL configuration generator. In addition to that I generated a new Diffie-Hellman key exchange parameters file with 4096 bit. (openssl dhparam -out dhparams.pem 4096)
See the results here: https://www.ssllabs.com/ssltest/analyze.html?d=git.black-storm.eu&s=144.76.94.178&hideResults=on&latest
Only Java 6, Android 2 and Internet Explorer on Windows XP are not working with that configuration and 4096 dhparams. Next thing on my agenda is HKPK.
//EDIT: Just realising my OCSP stapling is offline…fixing that…
yup for wider compatibility ssl_ecdh_curve secp384r1
Mozilla generator is bad, and its creators and users should feel bad.
75% of the supported cipher suites are not even used by any client simulated by SSL Labs.
Camellia cipher? Come on! Why would you ever need this?
With a server configured like that, not a single client would negotiate any cipher suite other than one of these:
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
This is a complete list. Even Android 2 and Windows XP would work if you didn’t require SNI.
1 Like
Hm…forgot about the SNI part.
generally agree but there's definitely more clients out there than just ssllabs list
here's my nginx server's ssl cipher usage stats that i log for my own forums running Nginx HTTP/2
1 Like
I’ve finally bothered to craft together a 1.0 release for this bundle of (mostly) configuration files.
It has OSCP Stapling, HSTS, Session Tickets, support for HTTP/2 and/or PHP 7.0, but the improvement over the stock client (not that this replaces that, but supplements it) is that there is no more need to stop or restart Nginx.
1 Like
Here is the basic stuff needed in nginx for A+ 100/100/100/100 in your configuration. You will still need a 4096bit cert for full 4x 100%, but this configuration takes care of the rest: https://www.tls.builders/servers#ng-18
There is a typo on this server ssl_ecdhe_curve should have been ssl_ecdh_curve, don't know who is the webmaster..