EFF's Updated SSL Configuration | Hacker News Reader

EFF's Updated SSL Configuration

eff.org

113 pointsel_duderino18 comments

Using 4096-bit RSA for the end-entity certificate is pointless. First, it's unlikely that an attacker will ever be able to break 2048-bit RSA but not 4096-bit RSA, either in the near or distant future. But for the sake of discussion, let's assume that such an attacker exists. Since nearly all clients will use forward secrecy with ECDH when connecting to eff.org, the attacker will need to conduct an active attack, and forge a certificate, to take advantage of their RSA breaking ability. But a 4096-bit end entity certificate will not hinder them, because there are plenty of trusted CAs (including the one that signed eff.org) which use 2048-bit RSA keys. So this hypothetical attacker, instead of factoring EFF's 4096-bit RSA key, will just factor a CA's 2048-bit RSA key, which is what they would do anyways, since factoring a CA key allows impersonation of any website, not just one.

So all that 4096-bit RSA accomplishes here is to slow down the handshake and increase computational load on their web servers.

Not necessarily - HPKP is standardized, here now, and supported by Firefox and Chrome.

http://en.wikipedia.org/wiki/HTTP_Public_Key_Pinning

True, pinning the end-entity cert would require the attacker to factor the end-entity cert. But pinning the end-entity cert is like pointing a loaded gun at your foot (if you lose the key, and all your backups, you are screwed), and EFF isn't even doing it. And it would still boil down to a big performance sacrifice (which gives SSL a bad reputation) for a flawed premise.

From the Mozilla page:

>Note: The current specification requires including a second pin for a backup key which isn't yet used in production. This allows for changing the server's public key without breaking accessibility for clients that have already noted the pins. This is important for example when the former key gets compromised.

You cannot get an A+ on SSL Labs without 4096 bit cert. It is just a vanity thing IMHO.

Not true. My sites have an A+ on SSL Labs with a 2048-bit RSA cert.

Edit: you may be thinking of one of the numeric scores, which probably requires 4096-bit RSA to max out. But you'd be best served ignoring the numeric scores and just focusing on the letter grade. You really do not need a 4096-bit end-entity RSA key to have "A+"-level security.

To expand on agwa's point, I recently received an A+ with a 3072-bit cert. The site config was TLS 1.2-only, with only 256-bit FS ciphers, and HSTS. But I re-enabled TLS 1/1.1 for better browser/crawler support, which dropped the grade down to A.

You need HTTP Strict Transport Security to get an A+, a 2048-bit cert is fine.

From this document: https://www.ssllabs.com/downloads/SSL_Server_Rating_Guide.pd...

Keys below 2048 bits (e.g., 1024) are now considered weak, and the grade capped at B.

New grade A+ is introduced for servers with exceptional configurations. At the moment, this grade is awarded to servers with good configuration, no warnings, and HTTP Strict Transport Security support with a max-age of at least 6 months.

Therefore A+ means key length>=2048 with other good config (TLS 1.2 and so on) and HSTS max-age>=6 month.

This is great, would be made better by linking to Mozilla's excellent Server Side TLS recommendations https://wiki.mozilla.org/Security/Server_Side_TLS which update over time.

>It's useful to have a "locked" version of the key for secure archival.

Why? Sounds like it just adds another point of compromise (but probably minor compared to having it loaded in memory on a web-facing computer). Maybe if you're pinning the exact certificate, but that doesn't seem like a good idea anyways (ideally, every server would have a unique private key stored in secured hardware, right?).

And 4096 bit, does that help at all? If a CA is 2048 then doesn't that max out the trust chain?

>And 4096 bit, does that help at all? If a CA is 2048 then doesn't that max out the trust chain?

Not if you use certificate pinning, but otherwise yes, you'd only have to crack the weakest cert of the chain (or well, of any chain actually, the CA system being what it is..)

you'd only have to crack the weakest cert of the chain (or well, of any chain actually, the CA system being what it is..)

Right... so I don't think anyone's going to bother trying to crack a 2048-bit cipher either when it's much easier to just bribe/blackmail/torture a single employee of one of the hundreds of organizations in ca-certificates.

You don't even have to "bribe/blackmail/torture" them, a subpoena will be sufficient in most countries.

This is not a good guide.

The CA will discard all the information from that openssl.cnf file when signing the certificate which makes it a waste of time.

The first part of the article can be replaced with the following command:

    openssl req -new -newkey rsa:4096 -keyout derp.key -subj '/C=US/CN=example.com'

That will generate the RSA key and CSR in a single step. FWIW I agree with the other commenters here saying 4096 bit RSA is pointless at best, and at worst makes you easier to DDoS. I also don't see much value in keeping a copy of the key around given the ease of getting a reissue.

CA's do not discard the subject alternative name extension. You at least need to add that.

What CA do you use that requires you to include the SANs? Every one that I've used has a form where you list them.

a little tweak for nginx https redirection* , use:

> return 301 https://example.com$request_uri;

instead of the rewrite.

* http://wiki.nginx.org/Pitfalls#Server_Name

Reply on news.ycombinator.com