HOWTO: A+ with all 100%'s on SSL Labs test using apache2.4 (READ WARNINGS)

This is great. But SSLCipherSuite "HIGH:!aNULL:!MD5:!3DES:!CAMELLIA:!AES128" will break with HTTP/2 as some ciphers are Blacklisted.

Blacklisted Ciphers
Good read on HTTP/2 implementation

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! :slight_smile:

Will? Or may? Because the first link you give says “MAY”…

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.

1 Like

Thanks. I’ll take a look and maybe give the cli.ini a try.

Nope, that didn’t work. I put the cli.ini in /letsencrypt. Should it go in /letsencrypt/letsencrypt-apache (given I’m using apache)?

Edit: a quick google seems to suggest it should be in /etc/letsencrypt. Trying that…

Edit #2: I’m using an old version of letsencrypt-auto. I’ll try updating stuff before trying again.

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).

Well, if your Rπ can’t handle the load, you might wanna change your opinion of elliptic curves, especially for the key exchange :wink:

2 Likes

I’m not exactly inundated with traffic, so it’s not really a DoS problem atm!

Anyway, just pointing out that you don’t need ECC gubbins for 4x100% and A+ :wink:

Actually, you don't need key pinning to get A+ SSL Labs, I'm getting A+ without it. However, you will need HSTS :slight_smile:

Quite. That’s my setup too.

well key pinning in the form of HPKP is maybe, just MAYBE, A LITTLE BIT (attention irony) more risky than HSTS.
``#TLSA4ever

I think you’ll be waiting a while, browsers are deprecating DHE suites. Chrome only supports ECDHE suites now.

just a question out if curiosity, what do you have against ECC?

Do you have a source for this?

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.

https://www.penfold.fr/docs/CNSA-Suite-and-Quantum-Computing-FAQ.pdf

It seems a rather odd way of putting it, but basically they're saying longer DH/RSA is better than most ECC while waiting for post-quantum algorithms.

@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.