❦ 25 avril 2014 17:22 CEST, Willy Tarreau w...@1wt.eu :
- ssl: Add standardized DH parameters = 1024 bits
(I still don't understand what this is about, I'm clearly far from
being even an SSL novice). I have no idea whether it can be related
or not, but at least you're using SSL
Hi Vincent,
On Sat, Apr 26, 2014 at 10:11:53AM +0200, Vincent Bernat wrote:
??? 25 avril 2014 17:22 CEST, Willy Tarreau w...@1wt.eu :
- ssl: Add standardized DH parameters = 1024 bits
(I still don't understand what this is about, I'm clearly far from
being even an SSL novice).
❦ 26 avril 2014 10:20 CEST, Willy Tarreau w...@1wt.eu :
- ssl: Add standardized DH parameters = 1024 bits
(I still don't understand what this is about, I'm clearly far from
being even an SSL novice). I have no idea whether it can be related
or not, but at least you're using
Since previously, the DH param was always 1024 bits and usually, key
sizes are 2048, I think that using a 2048 bits DH param adds a
performance impact but I never evaluated it since using a 1024 DHE param
is not unusual (or was not unusual, I am far to be up-to-date on
this). The impact should
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
❦ 26 avril 2014 12:51 CEST, Willy Tarreau w...@1wt.eu :
- 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
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
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
Hi Lukas,
On Sat, Apr 26, 2014 at 01:53:58PM +0200, Lukas Tribus wrote:
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.
(...)
I would rather warn when the crt files doesn't contain
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
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)
[...]
The same test with 1024 bits DH parameters in the cert
Le 26/04/2014 14:47, Remi Gacogne a écrit :
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)
[...]
The same
That's a bit strange, are you using the same 1024 bits DH parameters in
the cert file that the ones that are hardcoded in 1.5-dev22 and
1.5-dev24? Because then I would have expected the same results.
In the same conditions I get the same results, But look a the ciphers.
One test is for ECDHE,
I wonder why mod_ssl users does not seem to complain?
A TLS handshake blocks the event-loop on haproxy or nginx. It also blocks
on Apache, but since there is no event-loop but a lot of threads instead,
the TLS handshake does not impact that much.
Makes sense, thanks.
--
Rémi Gacogne
Aqua
On Sat, Apr 26, 2014 at 01:41:21PM +0200, Cyril Bonté wrote:
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)
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
Hi,
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 acceptable so I thought 'What the heck, let's just use it'
Thats it, with Remi's patch your dhparam was upgraded to 4096bit, we
assumed
On 26.04.2014 16:07, Lukas Tribus wrote:
Hi,
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 acceptable so I thought 'What the heck, let's just use it'
Thats it, with Remi's patch your
Hi,
I noticed a dramatic increase in CPU usage between HAProxy ss-20140329
and ss-20140425. With the first haproxy uses around 20% of CPU and with
the latter it eats up 80-90% of cpu and sites start to become sluggish.
Health checks take much more time to complete 1100ms vs 2ms normal.
Hey Willy,
On 25.04.2014 14:39, Willy Tarreau wrote:
On Fri, Apr 25, 2014 at 02:12:23PM +0200, Sander Klein wrote:
Hi,
I noticed a dramatic increase in CPU usage between HAProxy ss-20140329
and ss-20140425. With the first haproxy uses around 20% of CPU and
with
the latter it eats up 80-90%
On Fri, Apr 25, 2014 at 03:34:14PM +0200, Sander Klein wrote:
I currently don't have compression enabled in my config. I disabled it
some time ago because of CPU usage ;-)
Ah too bad, it would have been an easy solution!
With the current snapshot I do get some warnings:
[WARNING]
On 25.04.2014 15:46, Willy Tarreau wrote:
Just to make sure I didn't give you a bogus report is
upgraded/downgraded a couple of times, but every time I install
20140425
the CPU spikes and sites become sluggish.
OK. Does it happen immediately or does it take some time ?
It happens
On 25.04.2014 15:46, Willy Tarreau wrote:
On Fri, Apr 25, 2014 at 03:34:14PM +0200, Sander Klein wrote:
I currently don't have compression enabled in my config. I disabled it
some time ago because of CPU usage ;-)
Ah too bad, it would have been an easy solution!
With the current snapshot I
Hi,
I've done a search and it breaks between 20140413 and 20140415.
Are you using static DH parameters? If not, could you try using some?
Until 20140415 the default was (1024 bits DH parameters):
-BEGIN DH PARAMETERS-
On Fri, Apr 25, 2014 at 04:56:06PM +0200, Sander Klein wrote:
I've done a search and it breaks between 20140413 and 20140415.
OK, that's already very useful. I'm assuming this covers the period
between commits 01193d6ef and d988f2158. During this period, here's
what changed that could possibly
On 25.04.2014 17:22, Willy Tarreau wrote:
On Fri, Apr 25, 2014 at 04:56:06PM +0200, Sander Klein wrote:
I've done a search and it breaks between 20140413 and 20140415.
OK, that's already very useful. I'm assuming this covers the period
between commits 01193d6ef and d988f2158. During this
On Fri, Apr 25, 2014 at 08:37:39PM +0200, Sander Klein wrote:
Thus given your setup, I'd start with the think I understand the least
which is the SSL change. Could you please revert the attached patch
by applying it with patch -Rp1 ?
Well, I can confirm that reverting that patch fixes my
27 matches
Mail list logo
