EDIT
In addition, using 4096 RSA keys and DHParams are great. But the longer the key, the more resources are needed to handle it causing performance issues. Might not be noticeable in smaller implementations. That’s why the industry standard is 2048 since its already “enough” according to SSL Labs Best Practice . And that’s why we all can’t wait for letsencrypt to get ECC out!
It doesn’t matter if HTTP/2 blacklisted ciphers are enabled as long as they’re low down in the preferred order. Note the the cipher RFC 5246 requires all TLS 1.2 applications to support (TLS_RSA_WITH_AES_128_CBC_SHA) is on the blacklist.
@Osiris From what I’ve read, Blacklisted ciphers in HTTP/2 are still being negotiated but popular browsers are expected to support the blacklisting soon.
True, the ciphers mentioned here will give you a 100% Cipher Strength score in SSL Labs. I just did the test using the ciphers. SSL Labs did not penalize my score for using the ciphers but showed the warning: Server negotiated HTTP/2 with blacklisted suite. Using the ciphers might work now but might break in near feature releases of popular browsers.
I can confirm that you don’t need key pinning to get 4x100% in SSLLabs (and frankly, it scares me).
My Raspberry Pi I use for testing https://penfold.fr got full scores without needing it. I only got an “A” rather than A+ at Scottt’s https://securityheaders.io due to this omission though.
Note that renewing my certificates worked fine but for some reason it recently reverted to 2048-bit RSA (which shaves 5 or 10% off the key exchange score), so now I guess I’ll have to specify letsencrypt-auto --rsa-key-size 4096 every time.
I can thoroughly recommend Ivan Ristic’s “Bulletproof SSL and TLS” book (he of SSL Labs fame) for a great guide on how all this works.
That shouldn't be necessary, as the RSA key size should be set in the renewal config. You might wanna check that manually. Also, you could put it in cli.ini so that every cert will use tat setting.
I’m now using certbot as suggested by Lets Encrypt. My installation was ancient. I’ve just set it using
./certbot-auto --apache --rsa-key-size 4096
but will leave it at that for now as I’m going to run out of renewals.
I got A+ and 4x100% using DHE and RSA only, with none of that Elliptic Curve nonsense. It hammers the poor Raspberry Pi though (I'm waiting with bated breath for DHE + ChaCha20 + Poly1305 as Firefox doesn't appear to like AES256 with GCM, and uses AES256 CBC).
It's mainly due to the rather clever people at the NSA suggesting those dealing with Top Secret level encryption stick to longer DH/RSA keys rather than going to ECC.
Q: The commercial world appears to be moving to elliptic curves. Why is NSA continuing to support older algorithms?
A: NSA supports the use of NIST P-384 in NSS. In the original CNSSP-15 both RSA and Diffie-Hellman were included as legacy algorithms which were only to be used until replacement elliptic curve cryptography (ECC) equipment was available. Since that time NSA has come to appreciate that some of these legacy systems will be around for much longer than we had planned. Because of these legacy systems and because there is an eventual need to move to quantum resistant public key algorithms, NSA has decided that it may be more cost effective for some NSS to continue to use RSA and Diffie-Hellman with larger key sizes until the new quantum resistant public key algorithms are ready. NSA does not want to force NSS operators to pay for two cryptographic upgrades: first from RSA/Diffie-Hellman to ECC and then from ECC to quantum resistant cryptography.
@davep This does neither answer my question nor is the NSAs opinion related to this thread. Especially not if the Chromium devs are (supposedly) doing to contradictory of what the NSA suggest.