Hey All,
Sorry for my late response, but we have a national holiday here...
'Kings day' would be the translation ;-)
On 26.04.2014 13:53, Lukas Tribus wrote:
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?
My cipher config is:
ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS
I've disabled sslv3 and use certificates with 4096bits keys. I know 4096
bits keys are a bit over the top, but while testing the impact seemed to
be acceptible so I thought 'What the heck, let's just use it....'
I'll have a look at the recommended config from [3].
I don't think there are a lot of java clients connecting. We do expose
some api's which might be accessed by java clients, but that wouldn't be
more than 1% of the clients.
Also check if tls-tickets and ssl-session caching works correctly.
ssllabs says ssl resumption (caching) and ssl resumption (tickets) are
working.
Greets,
Sander
