Hi,
>> - 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 ? Yes, Emeric's hard-coded dhparams or Remi's automated dhparams are only a fallback in case the crt file doesn't contain dhparams. The file needs to look like: crt /path/to/<cert+privkey+intermediate+dhparam> Whereas the dhparam are simply the result of: openssl dhparam 1024/2048/... Also, one important thing to understand here is that this matters only with *_DHE_* cihpers. Its not used with legacy non-PFS RSA cihpers or with ECDHE ciphers. For example not a single browser uses _DHE_ ciphers on demo.1wt.eu [2], so the problem would never show (unless an attackers uses DHE deliberately to saturate the servers CPU). Sander, can you tell us your exact cipher configuration? It may be suboptimal. I would recommend the configuration from [3]. Do you have a lot of Java 6 clients connecting to this service btw? Also check if tls-tickets and ssl-session caching works correctly. > 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. I would rather warn when the crt files doesn't contain dhparams and that we are falling back to a possible suboptimal automation. Or, third possibility, remove all fallbacks, disabling _DHE_ but warn on startup that we don't do _DHE_ ciphers since the crt file doesn't have dhparams. Regards, Lukas [1] https://wiki.mozilla.org/Security/Server_Side_TLS#Haproxy [2] https://www.ssllabs.com/ssltest/analyze.html?d=demo.1wt.eu [3] https://wiki.mozilla.org/Security/Server_Side_TLS#Recommended_Ciphersuite
