Hi Cyril, On Sat, Apr 26, 2014 at 01:41:21PM +0200, Cyril Bonté wrote: > Hi all, > > Le 26/04/2014 12:51, Willy Tarreau a écrit : > >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 you can generate DH parameters with such command : > $ openssl dhparam -outform PEM -out dh2048.pem 2048 > > Those parameters can be appended to the cert file and haproxy uses it to > initialize the DH parameters if they are found. > I think that 1.5-dev24 with static 2048 bits DH parameters would also > increase the CPU usage for Sander. > > Yesterday, I made some tests and couldn't see a huge difference between > 1024 and 2048 bits DH parameters (provided in the cert file or not). > But that's true only for ECDHE ciphers. As soon as DHE ciphers are used, > CPU increases a lot, as the response time do (not really surprise). > > Sander, do you know which ciphers are used by your configuration and > clients ? > > For my test, I used this configuration : > defaults > timeout connect 5s > timeout client 5m > timeout server 5m > > listen https > mode http > option http-server-close > bind :443 ssl crt debug.pem > > Where debug.pem provides a 2048 bits RSA key. > > With haproxy 1.5-dev23 and no DH parameters in the cert file : > $ ab -n1000 -c100 -Z ECDHE-RSA-AES256-GCM-SHA384,2048,256 https://127.0.0.1/ > > Requests per second: 427.94 [#/sec] (mean) > Time per request: 233.679 [ms] (mean) > > $ ab -n1000 -c100 -Z DHE-RSA-AES256-GCM-SHA384,2048,256 https://127.0.0.1/ > > Requests per second: 72.10 [#/sec] (mean) > Time per request: 1386.985 [ms] (mean) > > The same test with 1024 bits DH parameters in the cert file : > $ ab -n1000 -c100 -Z DHE-RSA-AES256-GCM-SHA384,2048,256 https://127.0.0.1/ > > Requests per second: 290.67 [#/sec] (mean) > Time per request: 344.027 [ms] (mean) > > And with 2048 bits DH parameters : > > $ ab -n1000 -c100 -Z DHE-RSA-AES256-GCM-SHA384,2048,256 https://127.0.0.1/ > > Requests per second: 74.01 [#/sec] (mean) > Time per request: 1351.196 [ms] (mean) > > The same performance and CPU usage will occur with 1.5-dev24 in this > conditions.
Thanks for the explanations. I'm realizing that one reason why SSL is *always* a mess is that it's only documented in a cryptic way and the impact of cryptic choices is rarely explained, or only in security terms such as whether or not your key may be broken by the age of the universe. First thing to do if we want to encourage SSL adoption in a safe and successful way would be to document the procedures including building a CSR or a self-signed cert, and showing performance test reports like you did above for certain choices. Would anyone be interested in starting a file "HOWTO-SSL" that we'd put along the README ? We could start with elements from this thread. Or maybe it would be better placed in the configuration.txt file so that users can find it when they need it ? I'm in the interesting place of being really dumb on this subject and often annoyed by the lack of understandable information or excess of useless information. I'm among those who consider that SSL/TLS is a disaster, not in technical terms, but on the process. So whatever can be done to improve the processes which inevitably involves end-users' basic understanding of things and impacts is very welcome. Thanks, Willy
