

EFF's Updated SSL Configuration - el_duderino
https://www.eff.org/deeplinks/2015/04/effs-updated-ssl-configuration

======
agwa
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.

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

~~~
agwa
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.

------
nailer
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](https://wiki.mozilla.org/Security/Server_Side_TLS)
which update over time.

------
MichaelGG
>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?

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

~~~
bandrami
_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.

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

------
ryan-c
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.

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

~~~
ryan-c
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.

------
slasaus
a little tweak for nginx https redirection* , use:

> return 301
> [https://example.com$request_uri;](https://example.com$request_uri;)

instead of the rewrite.

* [http://wiki.nginx.org/Pitfalls#Server_Name](http://wiki.nginx.org/Pitfalls#Server_Name)

