Re: [PATCH] use SSL_CTX_set_ecdh_auto() for ecdh curve selection

[David Martin]

On Mon, Apr 18, 2016 at 3:02 PM, Janusz Dziemidowicz
 wrote:
> 2016-04-15 16:50 GMT+02:00 David Martin :
>> I have tested the current patch with the HAProxy default, a list of curves,
>> a single curve and also an incorrect curve.  All seem to behave correctly.
>> The conditional should only skip calling ecdh_auto() if curves_list()
>> returns 0 in which case HAProxy exits anyway.
>>
>> Maybe I'm missing something obvious, this has been a learning experience for
>> me.
>
> You are correct. I guess I shouldn't have been looking at patches
> during a break at a day work;)
> Seems ok for me now. Apart from the missing documentation changes;)
>
> --
> Janusz Dziemidowicz

Added doc changes :)
From f54632ab99e526ddb6d6acc26f6c1cb74b3c647d Mon Sep 17 00:00:00 2001
From: David Martin 
Date: Mon, 18 Apr 2016 16:10:13 -0500
Subject: [PATCH] use SSL_CTX_set_ecdh_auto() for ecdh curve selection

Use SSL_CTX_set_ecdh_auto if the OpenSSL version supports it, this
allows the server to negotiate ECDH curves much like it does ciphers.
Prefered curves can be specified using the existing ecdhe bind options
(ecdhe secp384r1:prime256v1)
---
 doc/configuration.txt |  6 --
 src/ssl_sock.c| 16 +++-
 2 files changed, 19 insertions(+), 3 deletions(-)

diff --git a/doc/configuration.txt b/doc/configuration.txt
index 6b80158..be1f06f 100644
--- a/doc/configuration.txt
+++ b/doc/configuration.txt
@@ -9625,8 +9625,10 @@ backlog 
 
 ecdhe 
   This setting is only available when support for OpenSSL was built in. It sets
-  the named curve (RFC 4492) used to generate ECDH ephemeral keys. By default,
-  used named curve is prime256v1.
+  the named curve (RFC 4492) used to generate ECDH ephemeral keys. OpenSSL
+  1.0.2 and newer support a list of curves that are negotiated during SSL/TLS
+  handshake such as  "prime256v1:secp384r1" (without quotes). By default, used
+  named curve is prime256v1.
 
 ca-file 
   This setting is only available when support for OpenSSL was built in. It
diff --git a/src/ssl_sock.c b/src/ssl_sock.c
index 0d35c29..a5d9408 100644
--- a/src/ssl_sock.c
+++ b/src/ssl_sock.c
@@ -2756,7 +2756,20 @@ int ssl_sock_prepare_ctx(struct bind_conf *bind_conf, SSL_CTX *ctx, struct proxy
 	SSL_CTX_set_tlsext_servername_callback(ctx, ssl_sock_switchctx_cbk);
 	SSL_CTX_set_tlsext_servername_arg(ctx, bind_conf);
 #endif
-#if defined(SSL_CTX_set_tmp_ecdh) && !defined(OPENSSL_NO_ECDH)
+#if !defined(OPENSSL_NO_ECDH)
+#if defined(SSL_CTX_set_ecdh_auto)
+	{
+		const char *ecdhe = (bind_conf->ecdhe ? bind_conf->ecdhe : ECDHE_DEFAULT_CURVE);
+		if (!SSL_CTX_set1_curves_list(ctx, ecdhe)) {
+			Alert("Proxy '%s': unable to set elliptic curve list to '%s' for bind '%s' at [%s:%d].\n",
+curproxy->id, ecdhe, bind_conf->arg, bind_conf->file, bind_conf->line);
+			cfgerr++;
+		}
+		else {
+			SSL_CTX_set_ecdh_auto(ctx, 1);
+		}
+	}
+#elif defined(SSL_CTX_set_tmp_ecdh)
 	{
 		int i;
 		EC_KEY  *ecdh;
@@ -2774,6 +2787,7 @@ int ssl_sock_prepare_ctx(struct bind_conf *bind_conf, SSL_CTX *ctx, struct proxy
 		}
 	}
 #endif
+#endif
 
 	return cfgerr;
 }
-- 
1.9.1

Re: HAProxy rejecting requests w/ extended characters in their URLs as bad

[PiBa-NL]

Op 18-4-2016 om 22:47 schreef CJ Ess:
This is using HAProxy 1.5.12 - I've noticed an issue where HAProxy is 
sometimes rejecting requests with a 400 code when the URL string 
contains extended characters. Nginx is fronting HAProxy and has passed 
them through as as valid requests and just eyeballing them they look 
ok to me.


An example is a german URL with 0xc3 0x95 contained in the URL

A second example is a latin URL with 0xc3 0xa7 contained in the URL

A third example is an asian URL with 0xe6 0xac 0xa1 0xe3 contained in 
the URL (and many more so I may or may not have complete characters in 
the example)


I don't know the encoding these characters are part of, there are no 
hints in the other headers.


Any idea what I can do to have haproxy accept these?

Have you tried?: 
http://cbonte.github.io/haproxy-dconv/snapshot/configuration-1.6.html#4.2-option%20accept-invalid-http-request
Though technically the requests are invalid, and should be fixed/avoided 
if possible

HAProxy rejecting requests w/ extended characters in their URLs as bad

[CJ Ess]

This is using HAProxy 1.5.12 - I've noticed an issue where HAProxy is
sometimes rejecting requests with a 400 code when the URL string contains
extended characters. Nginx is fronting HAProxy and has passed them through
as as valid requests and just eyeballing them they look ok to me.

An example is a german URL with 0xc3 0x95 contained in the URL

A second example is a latin URL with 0xc3 0xa7 contained in the URL

A third example is an asian URL with 0xe6 0xac 0xa1 0xe3 contained in the
URL (and many more so I may or may not have complete characters in the
example)

I don't know the encoding these characters are part of, there are no hints
in the other headers.

Any idea what I can do to have haproxy accept these?

Re: [PATCH] use SSL_CTX_set_ecdh_auto() for ecdh curve selection

[Janusz Dziemidowicz]

2016-04-15 16:50 GMT+02:00 David Martin :
> I have tested the current patch with the HAProxy default, a list of curves,
> a single curve and also an incorrect curve.  All seem to behave correctly.
> The conditional should only skip calling ecdh_auto() if curves_list()
> returns 0 in which case HAProxy exits anyway.
>
> Maybe I'm missing something obvious, this has been a learning experience for
> me.

You are correct. I guess I shouldn't have been looking at patches
during a break at a day work;)
Seems ok for me now. Apart from the missing documentation changes;)

-- 
Janusz Dziemidowicz

Immunologists List

[jennifer.seaton]

Hi,

Recently I reviewed your website and come across your services. Would you be
interested in acquiring Immunologists list with email information?

We have also database for Hospitals and Labs, Pharmaceuticals List,
Diagnostics Labs, Pharmacists, Registered Nurses, Surgeons, Physicians,
Cardiologists, Healthcare Professionals, Medical Directors and more.

If you are interested, please let me know your requirements. In turn I'll
get back to you available counts, cost, few samples for your review. 

 

Please do let me know your thoughts. 

Regards, 

Jennifer Seaton

Research Analyst

 

 

subscribe

[Hugues CHARBONNIER]

[SPAM] 8% par an net d'impôt c'est possible!

[Placement en diamant]

*|MC:SUBJECT|*
INVESTIR DANS LE DIAMANT
8% par an
Net d'impôt c'est possible!
Alternative d'épargne au livret A, PEL ou Assurance vie
EN SAVOIR PLUS
" Placer son cash aujourd’hui est devenu un véritable casse-tête. Les produits 
court terme et sans risque rapportent de moins en moins. Quelles sont les 
alternatives ?"
EN SAVOIR PLUS
La presse en parle
une valeur refuge aujourd'hui et investissement financier d'avenir.
Voir le reportage.
EN SAVOIR PLUS

Re: Haproxy running on 100% CPU and slow downloads

[Sachin Shetty]

Hi Lukas,

We upgraded to 1.6, went back to nbproc 1 from 12 and the problem showed
up again. Haproxy hitting 90-100% and monitors reported download speed
drop from 100MBPS to 10MBPS immediately.

I ran strace as you said, output it huge, have attached a small subset of
it in the email. Please let me know if you need more of strace output.

Thanks
Sachin



On 4/7/16, 5:51 PM, "Lukas Tribus"  wrote:

>Hi,
>
>Am 05.04.2016 um 09:38 schrieb Sachin Shetty:
>> Hi Lukas, Pavlos,
>>
>> Thanks for your response, more info as requested.
>>
>> 1. Attached conf with some obfuscation
>> 2. Haproxy -vv
>> HA-Proxy version 1.5.4 2014/09/02
>> Copyright 2000-2014 Willy Tarreau 
>>
>
>I would upgrade to something more recent, the number of bugfixes
>since 1.5.4 amount to more than 100!
>
>That said, I've not stumbled upon a particular bug explaining what
>you are seeing.
>
>My suggestion would be to go back to nbproc 1 (its easier to
>troubleshoot), and run the 100% spinning process through
>strace -tt -p and post the output.
>
>
>
>
>Thanks,
>
>Lukas

23:30:41.257757 sendto(120, "...", 16384, MSG_DONTWAIT|MSG_NOSIGNAL|MSG_MORE, 
NULL, 0) = 16384
23:30:41.258001 sendto(87, "...", 919, MSG_DONTWAIT|MSG_NOSIGNAL, NULL, 0) = 919
23:30:41.258077 read(33, "\27\3\3\0020", 5) = 5
23:30:41.258134 read(33, "...", 560) = 560
23:30:41.258201 read(3, "\26\3\3\0F", 5) = 5
23:30:41.258244 read(3, "...", 70) = 70
23:30:41.259294 read(3, "\24\3\3\0\1", 5) = 5
23:30:41.259347 read(3, "\1", 1)= 1
23:30:41.259514 read(3, "\26\3\3\0@", 5) = 5
23:30:41.259559 read(3, "...", 64) = 64
23:30:41.259668 write(3, "...", 75) = 75
23:30:41.259748 read(3, 0x7feeaed21343, 5) = -1 EAGAIN (Resource temporarily 
unavailable)
23:30:41.259818 read(71, "\26\3\1\2\6", 5) = 5
23:30:41.259863 read(71, "...", 518) = 518
23:30:41.280711 read(71, "\24\3\1\0\1", 5) = 5
23:30:41.280790 read(71, "\1", 1)   = 1
23:30:41.280967 read(71, "\26\3\1\", 5) = 5
23:30:41.281012 read(71, "...", 48) = 48
23:30:41.281121 write(71, "...", 59) = 59
23:30:41.281199 read(71, 0x7feeaed21343, 5) = -1 EAGAIN (Resource temporarily 
unavailable)
23:30:41.281246 read(51, "...", 14977) = 14977
23:30:41.281405 sendto(56, "...", 16384, MSG_DONTWAIT|MSG_NOSIGNAL|MSG_MORE, 
NULL, 0) = 16384
23:30:41.281472 read(38, 0x7feeaeb15183, 5) = -1 EAGAIN (Resource temporarily 
unavailable)
23:30:41.281517 read(140, "...", 7677) = 5840
23:30:41.281562 read(140, 0x7feeaec87a2b, 1837) = -1 EAGAIN (Resource 
temporarily unavailable)
23:30:41.281605 read(45, "\27\3\3\2\240", 5) = 5
23:30:41.281647 read(45, "...", 672) = 672
23:30:41.281699 read(31, "...", 48) = 48
23:30:41.281811 sendto(272, "...", 16384, MSG_DONTWAIT|MSG_NOSIGNAL|MSG_MORE, 
NULL, 0) = 16384
23:30:41.281948 write(167, "...", 15525) = 15525
23:30:41.282025 read(72, "...", 15923) = 8184
23:30:41.282076 read(72, "...", 7739) = 1364
23:30:41.282119 read(72, 0x7feeaebf89c1, 6375) = -1 EAGAIN (Resource 
temporarily unavailable)
23:30:41.282162 read(24, "...", 1837) = 1837
23:30:41.282278 sendto(107, "...", 16384, MSG_DONTWAIT|MSG_NOSIGNAL|MSG_MORE, 
NULL, 0) = 16384
23:30:41.282328 recvfrom(41, "...", 16384, 0, NULL, NULL) = 16384
23:30:41.282382 recvfrom(81, "...", 15360, 0, NULL, NULL) = 214
23:30:41.282438 write(21, "...", 389) = 389
23:30:41.282497 write(25, "...", 389) = 389
23:30:41.282563 write(25, "...", 53) = 53
23:30:41.282613 shutdown(25, SHUT_WR)   = 0
23:30:41.282660 read(18, 0x7feeae813be3, 5) = -1 EAGAIN (Resource temporarily 
unavailable)
23:30:41.282704 sendto(92, "...", 818, MSG_DONTWAIT|MSG_NOSIGNAL, NULL, 0) = 818
23:30:41.282753 read(39, 0x7feeae813be3, 5) = -1 EAGAIN (Resource temporarily 
unavailable)
23:30:41.282796 sendto(88, "...", 2062, MSG_DONTWAIT|MSG_NOSIGNAL, NULL, 0) = 
2062
23:30:41.282944 getsockname(33, {sa_family=AF_INET, sin_port=htons(443), 
sin_addr=inet_addr("Some-IP")}, [16]) = 0
23:30:41.283008 getsockopt(33, SOL_IP, 0x50 /* IP_??? */, 
"\2\0\1\273\n\31\220\17\0\0\0\0\0\0\0\0", [16]) = 0
23:30:41.283082 socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 77
23:30:41.283132 fcntl(77, F_SETFL, O_RDONLY|O_NONBLOCK) = 0
23:30:41.283188 setsockopt(77, SOL_TCP, TCP_NODELAY, [1], 4) = 0
23:30:41.283233 connect(77, {sa_family=AF_INET, sin_port=htons(7300), 
sin_addr=inet_addr("Some-IP")}, 16) = -1 EINPROGRESS (Operation now in progress)
23:30:41.283415 getsockname(45, {sa_family=AF_INET, sin_port=htons(443), 
sin_addr=inet_addr("Some-IP")}, [16]) = 0
23:30:41.283467 getsockopt(45, SOL_IP, 0x50 /* IP_??? */, 
"\2\0\1\273\n\31\220\17\0\0\0\0\0\0\0\0", [16]) = 0
23:30:41.283521 socket(PF_INET, SOCK_STREAM, IPPROTO_TCP) = 79
23:30:41.283565 fcntl(79, F_SETFL, O_RDONLY|O_NONBLOCK) = 0
23:30:41.283605 setsockopt(79, SOL_TCP, TCP_NODELAY, [1], 4) = 0
23:30:41.283647 connect(79, {sa_family=AF_INET, sin_port=htons(9930), 
sin_addr=inet_addr("Some-IP")}, 16) = -1 EINPROGRESS (Operation now in progress)
23:30:41.283723 setsockopt(81, SOL_SOCKET, SO_LINGER, {onoff=1, linger=0}, 8) = 0