Hi Rémi,
On Fri, Oct 10, 2014 at 06:57:33PM +0200, Remi Gacogne wrote:
I finally found the time to test with a proper boringssl build. This
minor patch cleans the way haproxy checks for enabled DHE ciphers at
configuration time, replacing a direct access to the cipher_list member
by a call to
Hi everyone,
Be that as it may, BoringSSL changed the internal structure because
of a specific feature, so whether we use the API or access directly
is irrelevant because the structure is different:
https://boringssl.googlesource.com/boringssl/+/858a88daf27975f67d9f63e18f95645be2886bfb%5E!/
Hi Lukas,
in src/ssl_sock.c:1582:11:
ciphers = ctx-cipher_list;
can we use the API instead of accessing cipher_list directly?
With [1] perhaps?
Yes, you are right, we could replace this line with something like:
SSL * ssl = NULL;
...
ssl = SSL_new(ctx);
if (ssl) {
ciphers =
Hi Remi!
Well, I really hope you're right. This patch looks in the cipher's
description instead of its name. Sorry about the mess.
in src/ssl_sock.c:1582:11:
ciphers = ctx-cipher_list;
can we use the API instead of accessing cipher_list directly?
With [1] perhaps?
Background: I'm
Hi everyone,
After good remarks from Willy and Emeric, here is a new version of the
previous patch, including the following changes:
- tune.ssl.default-dh-param does not accept a value of less than 1024
anymore ;
- a comment explaining why we use the certificate key size and not the
keylen
Hi Rémi!
On Thu, Jun 12, 2014 at 03:24:13PM +0200, Remi Gacogne wrote:
Hi everyone,
After good remarks from Willy and Emeric, here is a new version of the
previous patch, including the following changes:
- tune.ssl.default-dh-param does not accept a value of less than 1024
anymore ;
-
That's really nice, I've just applied it with Emeric's approval.
Thanks Willy, but I just remembered that my patch walks directly into
what I spotted earlier, that in OpenSSL the name of ciphers using
ephemeral diffie-hellman for key exchange can start with EDH, but also
DHE, EXP-EDH or
On Thu, Jun 12, 2014 at 04:54:42PM +0200, Remi Gacogne wrote:
That's really nice, I've just applied it with Emeric's approval.
Thanks Willy, but I just remembered that my patch walks directly into
what I spotted earlier, that in OpenSSL the name of ciphers using
ephemeral diffie-hellman
I don't understand, that was precisely the intent of using
SSL_cipher_description() which always returns Kx=DH in all circumstances.
Is there any case you're aware where this does not work ? From what I saw
in the code, it was a direct mapping of your test of the bit mask, so I'm
a bit
Yes I think it's better exactly for the reason you reported (inconsistent
naming over time). I'm having a hard time believing that Kx=DH has any
reason to change as often as the internal bitfields or cipher names given
that the output is even documented in the man page.
Well, I really hope
On Thu, Jun 12, 2014 at 06:29:33PM +0200, Remi Gacogne wrote:
Yes I think it's better exactly for the reason you reported (inconsistent
naming over time). I'm having a hard time believing that Kx=DH has any
reason to change as often as the internal bitfields or cipher names given
that
Hi Rémi,
On Mon, Jun 02, 2014 at 02:43:37PM +0200, Remi Gacogne wrote:
Hi,
Well, maybe your latest patch is still the best way to go then. After all,
it's very simple to see what can happen : if ciphers allow DHE and the
admin has not configured its param, then there's a risk that some
Hi,
Well, maybe your latest patch is still the best way to go then. After all,
it's very simple to see what can happen : if ciphers allow DHE and the
admin has not configured its param, then there's a risk that some users
will run it with too low a parameter and we'd rather warn them. So if
Hi Willy, Bryan,
On Mon, May 19, 2014 at 12:49:21PM -0700, Bryan Talbot wrote:
It seems like the warning would be emitted in cases when DH exchange is
disabled. ECDH is supported by nearly all new browsers and devices (that we
care about anyway) and so have DH disabled and only ECDH enabled
Hi Rémi,
On Tue, May 20, 2014 at 10:55:55AM +0200, Remi Gacogne wrote:
Is it possible to only generate the dh-param and warnings if a cipher that
needs it is enabled?
I thought it was the case where the code was placed, but maybe I was
wrong. Rémi, what do you think ?
Well, the
On 19.05.2014 06:51, Willy Tarreau wrote:
Hi Rémi,
On Mon, May 12, 2014 at 06:34:01PM +0200, Remi Gacogne wrote:
Hi,
On 05/05/2014 12:06 PM, Sander Klein wrote:
I've added a 2048bit dhparam to my most used certificates and I don't
see a big jump in resource usage.
This was not a big
Hi,
What happens if you also have DH appended to your certificates? You set
global.tune.ssl_max_dh_param to 1024 but you have a 4096bit DH in your
certificate file, which one is used then? An answer could be 'Don't do
that' :-) but I was curious.
The certificate's dh_param is used. To avoid
Hi Willy,
I'd have applied a very simple change to your patch : I'd have initialized
global.tune.ssl_max_dh_param to zero by default, and emitted a warning here :
+ if (global.tune.ssl_max_dh_param = 1024) {
+ /* we are limited to DH parameter of 1024
Hi,
What happens if you also have DH appended to your certificates? You set
global.tune.ssl_max_dh_param to 1024 but you have a 4096bit DH in your
certificate file, which one is used then? An answer could be 'Don't do
that' :-) but I was curious.
The certificate's dh_param is used. To avoid
On Mon, May 19, 2014 at 09:47:45AM +0200, Remi Gacogne wrote:
Hi Willy,
I'd have applied a very simple change to your patch : I'd have initialized
global.tune.ssl_max_dh_param to zero by default, and emitted a warning here
:
+ if (global.tune.ssl_max_dh_param = 1024) {
Ah yes, you're right. But anyway the purpose was to explain the principle.
Do you want to update your patch and resubmit then ?
Yes, of course, thank you. What do you think about Lukas idea to change
the name of the setting, in order to clarify the fact that it only
applies as a fallback when
On Mon, May 19, 2014 at 10:43:22AM +0200, Remi Gacogne wrote:
Ah yes, you're right. But anyway the purpose was to explain the principle.
Do you want to update your patch and resubmit then ?
Yes, of course, thank you. What do you think about Lukas idea to change
the name of the setting,
Yes, of course, thank you. What do you think about Lukas idea to change
the name of the setting, in order to clarify the fact that it only
applies as a fallback when there is no DH parameters in the certificate
file?
I think it's a good idea, it could avoid some confusion in the future.
It seems like the warning would be emitted in cases when DH exchange is
disabled. ECDH is supported by nearly all new browsers and devices (that we
care about anyway) and so have DH disabled and only ECDH enabled when PFS
can be used -- specifically to avoid the large DH overhead especially for
Hi Bryan,
On Mon, May 19, 2014 at 12:49:21PM -0700, Bryan Talbot wrote:
It seems like the warning would be emitted in cases when DH exchange is
disabled. ECDH is supported by nearly all new browsers and devices (that we
care about anyway) and so have DH disabled and only ECDH enabled when PFS
Hi Rémi,
On Mon, May 12, 2014 at 06:34:01PM +0200, Remi Gacogne wrote:
Hi,
On 05/05/2014 12:06 PM, Sander Klein wrote:
I've added a 2048bit dhparam to my most used certificates and I don't
see a big jump in resource usage.
This was not a big scientific test, I just added the DH
Hi,
On 05/05/2014 12:06 PM, Sander Klein wrote:
I've added a 2048bit dhparam to my most used certificates and I don't
see a big jump in resource usage.
This was not a big scientific test, I just added the DH params in my
production and looked if the haproxy process started eating more CPU.
On 02.05.2014 16:52, Lukas Tribus wrote:
Hi Remi,
The default value for max-dh-param-size is set to 1024, thus keeping
the current behavior by default. Setting a higher value (for example
2048 with a 2048 bits RSA/DSA server key) allows an easy upgrade
to stronger ephemeral DH keys (and back
Hi
On 02/05/2014 16:29, Remi Gacogne wrote:
Hi Lukas,
The default value for max-dh-param-size is set to 1024, thus keeping
the current behavior by default. Setting a higher value (for example
2048 with a 2048 bits RSA/DSA server key) allows an easy upgrade
to stronger ephemeral DH keys (and
Hi Remi,
The default value for max-dh-param-size is set to 1024, thus keeping
the current behavior by default. Setting a higher value (for example
2048 with a 2048 bits RSA/DSA server key) allows an easy upgrade
to stronger ephemeral DH keys (and back if needed).
Please note that Sander
Hi
My 2 cents re high cpu and large key sizes. I loaded a package on my
HAproxy servers called haveged and I saw significant faster response
times. Reason for this is it doubled the entropy on my servers. As a
test I created a 4096 GPG key on a system without haveged and it took
nearly 2
Hi Lukas,
The default value for max-dh-param-size is set to 1024, thus keeping
the current behavior by default. Setting a higher value (for example
2048 with a 2048 bits RSA/DSA server key) allows an easy upgrade
to stronger ephemeral DH keys (and back if needed).
Please note that Sander
On 02.05.2014 16:52, Lukas Tribus wrote:
Hi Remi,
The default value for max-dh-param-size is set to 1024, thus keeping
the current behavior by default. Setting a higher value (for example
2048 with a 2048 bits RSA/DSA server key) allows an easy upgrade
to stronger ephemeral DH keys (and back
33 matches
Mail list logo
