Hi Rémi,
On Sat, Apr 26, 2014 at 12:32:54PM +0200, Remi Gacogne wrote:
> >In fact, I said that the performance impact should have been low, but
> >this is false. g is kept to 2, but the a in g^a mod p (a is the secret
> >number chosen by the server for the DH exchange) is a random number
> >between 0 and p - 1, so there is a big performance impact to use a 2048
> >bit DH parameter vs a 1024.
>
> I agree with your explanation and the significative performance impact,
> though I did not expect that users would be CPU-bound with a 2048 bits DH
> parameter, as most of the requests are typically reusing an existing TLS
> session (via TLS session ID or TLS tickets), therefore skipping a new key
> exchange.
>
> I think that we have two options:
>
> - leave the situation as it is now, and let users concerned with security
> use a static 2048 bits (or larger) static DH parameter in the certificate
> file ;
> - recommit the patch I submitted as it is, and let users concerned with
> the CPU impact use static DH parameter in the certificate file.
What do you mean by "use static DH parameter in the cert file" ? Is this
something the user can decide after the cert is emitted ? Is it something
easy to do ?
> I am in favor of the second option, because I think that the level of
> security expected when using a 2048 bits RSA is a 2048 DH key exchange
> (see rfc3766). Of course this means that users upgrading from a previous
> version may see a significant increase in CPU usage, which I agree is bad.
Wouldn't it be possible to have a global tuning option such as :
tune.ssl.dh-param 2048
?
If so, I'd rather proceed differently :
- keep the default 1024 in order not to break existing setups, which
is always the worst thing to do, because users do not know what is
the cause for their breakage ;
- emit a warning when the value is not set, saying that it defaults
to 1024 which represents short-term/mid-term/long-term risk X or Y,
and that the options are to force the value or maybe change for
another algorithm (I don't know). Also mention that a future version
will change this default to 2048.
- shut up the warning when the value is set
- default to 2048 in 1.6
That way, nobody gets trapped with an upgrade that kills the production
on saturday evening, but all users are warned about the risks and the
ongoing change.
> I should probably send a new patch though, because I am afraid that using
> a DH parameter larger than 2048 bits (which was the case with the previous
> patch for RSA keys larger than 2048) is too much CPU consuming.
It really depends on the sites. Many sites have just a few requests per
connection. Think about the number of tabs you open upon a google search,
then close just after looking at them without reading. Forum sites are
known for having very long sessions for example.
> I wonder why mod_ssl users does not seem to complain?
Maybe most of them are running at low loads or are running sites where
users stay for a long time ?
Regards,
Willy
