Re: [PATCH] BUILD: ssl: fix SSL_OP_NO_SSLv3 with LibreSSL >= 2.3.0

2017-05-23 Thread Cyril Bonté

Hi Emmanuel,

Sorry for the delay and for the lack of details in my previous mail. 
During this week-end I was in a world without computer :)


Le 22/05/2017 à 14:31, Emmanuel Hocdet a écrit :

Hi Cyril,

This patch should fix the build issue



Can you check it’s your case?


It didn't but now I understand why. The issue was on my test box under 
Debian testing.
There was a mismatch between the libssl packages. I had both 
libssl1.0.0, libssl1.0.2 and libssl1.1 but the dev package was 
libssl1.0-dev.


Once libssl-dev has been installed (1.1.0e-2), everything worked as 
expected. Sorry for the noise ;-)


--
Cyril Bonté



HAProxy won't shut down

2017-05-23 Thread Patrick Hemmer
We've been running across a fair amount of haproxy processes lately that
won't shut down. We're currently using 1.7.5, but have also experienced
the issue with earlier versions, 1.7.2 for sure, but likely back even
further.
The processes are getting signaled to shut down by the
haproxy-systemd-wrapper after sending it a SIGHUP.
The last thing logged by the process was all the "Stopping frontend"
"Stopping backend" and "Proxy XXX stopped" messages.

When I do an `lsof -p XXX` I get:

# lsof -p 28856
COMMAND   PID USER   FD  TYPE DEVICE SIZE/OFF   NODE
NAME
haproxy 28856 root  cwd   DIR  253,0 4096128 /
haproxy 28856 root  rtd   DIR  253,0 4096128 /
haproxy 28856 root  txt   REG  253,0  1562240   25168059
/usr/sbin/haproxy
haproxy 28856 root  DEL   REG0,4   420037375
/dev/zero
haproxy 28856 root  mem   REG  253,062184   26659777
/usr/lib64/libnss_files-2.17.so
haproxy 28856 root  mem   REG  253,0   155744   25213445
/usr/lib64/libselinux.so.1
haproxy 28856 root  mem   REG  253,0   111080   26659787
/usr/lib64/libresolv-2.17.so
haproxy 28856 root  mem   REG  253,015688   25315637
/usr/lib64/libkeyutils.so.1.5
haproxy 28856 root  mem   REG  253,062744   25394528
/usr/lib64/libkrb5support.so.0.1
haproxy 28856 root  mem   REG  253,0   143944   26659785
/usr/lib64/libpthread-2.17.so
haproxy 28856 root  mem   REG  253,0   202568   25300495
/usr/lib64/libk5crypto.so.3.1
haproxy 28856 root  mem   REG  253,015848   25213462
/usr/lib64/libcom_err.so.2.1
haproxy 28856 root  mem   REG  253,0   959008   25394526
/usr/lib64/libkrb5.so.3.3
haproxy 28856 root  mem   REG  253,0   324888   25300491
/usr/lib64/libgssapi_krb5.so.2.2
haproxy 28856 root  mem   REG  253,011384   25167850
/usr/lib64/libfreebl3.so
haproxy 28856 root  mem   REG  253,0  2118128   25167885
/usr/lib64/libc-2.17.so
haproxy 28856 root  mem   REG  253,0   398264   25195400
/usr/lib64/libpcre.so.1.2.0
haproxy 28856 root  mem   REG  253,02   25195408
/usr/lib64/libpcreposix.so.0.0.1
haproxy 28856 root  mem   REG  253,0  1141928   26148751
/usr/lib64/libm-2.17.so
haproxy 28856 root  mem   REG  253,0  2025472   25300659
/usr/lib64/libcrypto.so.1.0.1e
haproxy 28856 root  mem   REG  253,0   454024   25300661
/usr/lib64/libssl.so.1.0.1e
haproxy 28856 root  mem   REG  253,019776   26148750
/usr/lib64/libdl-2.17.so
haproxy 28856 root  mem   REG  253,090664   25213451
/usr/lib64/libz.so.1.2.7
haproxy 28856 root  mem   REG  253,041080   25167891
/usr/lib64/libcrypt-2.17.so
haproxy 28856 root  mem   REG  253,0   155464   26148745
/usr/lib64/ld-2.17.so
haproxy 28856 root0u  a_inode0,90   5823
[eventpoll]
haproxy 28856 root1u IPv4  420797940  0t0TCP
10.0.33.145:35754->10.0.33.147:1029 (CLOSE_WAIT)
haproxy 28856 root2u IPv4  420266351  0t0TCP
10.0.33.145:52898->10.0.33.147:1029 (CLOSE_WAIT)
haproxy 28856 root3r  REG0,30 4026531956 net
haproxy 28856 root4u IPv4  422150834  0t0TCP
10.0.33.145:38874->10.0.33.147:1029 (CLOSE_WAIT)
haproxy 28856 root5r  REG0,30 4026532437 net
haproxy 28856 root6r  REG0,30 4026531956 net
haproxy 28856 root   13u unix 0x88009af6e800  0t0  420037384
socket

All those sockets have been sitting there like that for a long time.
The :1029 sockets are "peer" sync connections.
File descriptor 13 is likely one of:
* The syslog connection to /dev/log
* A dead connection from an SSL worker process. We use nbproc>1 with
dedicated processes handling SSL termination, and then unix domain
sockets to forward to the main haproxy process. PID 28856 is the main
process, not an SSL terminator. The SSL terminator processes are already
shut down, so there's nothing on the other end of that socket.
I'm not sure what the other "net" sockets are.



When I `strace -p XXX` I get:

# strace -p 28856
Process 28856 attached
epoll_wait(0, {}, 200, 319) = 0
epoll_wait(0, {}, 200, 0)   = 0
epoll_wait(0, {}, 200, 362) = 0
epoll_wait(0, {}, 200, 0)   = 0
epoll_wait(0, {}, 200, 114) = 0
epoll_wait(0, {}, 200, 0)   = 0
epoll_wait(0, {}, 200, 203) = 0
epoll_wait(0, {}, 200, 0)   = 0
epoll_wait(0, {}, 200, 331) = 0
epoll_wait(0, {}, 200, 0)   = 0



When I do `bt full` in gdb I get:

(gdb) bt full
#0  0x7f5f3efdacf3 in __epoll_wait_nocancel () from /lib

New feature proposal: Add support for decompressing proxyed gziped requests

2017-05-23 Thread Vasileios Kyrillidis

Hello,

We would like to add support for decompressing proxyed gziped requests 
(i.e. those with "Content-Encoding: gzip") to HAProxy. Would there be 
interest in such a feature? i.e. is it likely it could be accepted into 
the main repo? Is anyone else already working on such a feature?


Currently HAProxy supports compressing outgoing responses where the 
client has indicated it supports receiving them. It does not yet support 
receiving requests that are compressed and decompressing them before 
sending them to a backend. This is not something commonly seen with 
browsers but is not uncommon when dealing with web service calls, which 
is our use case.


It is envisioned that this feature would be off by default and require 
explicit enabling.


Regards,
Vasilis

--
*Vasileios Kyrillidis*  | Software Developer  | Sociomantic Labs 
www.sociomantic.com 
  | 

Twitter  + Facebook 
 + Resources 
  | 
*Subscribe* to our Newsletter 
. 


Sociomantic Labs Logo
Sociomantic Labs GmbH, Location: Berlin, Commercial Register - AG 
Charlottenburg: HRB 121302 B, VAT No. - USt-ID: DE 266262100, Managing 
Directors: Thomas Nicolai, Sarah McCarthy, Mark Anthony Hinds. This 
message and any attachments are confidential and intended solely for the 
use of the individual to whom it is addressed.




[PATCH] MEDIUM: ssl: disable SSLv3 per default for bind

2017-05-23 Thread Emmanuel Hocdet
Hi,I think it’s time to disable SSLv3 on bind line per default.All configurations should have no-sslv3 (or used a ssllib without sslv3).SSLv3 can be enable with "ssl-min-ver SSLv3.What do you think?Manu* This patch depend of "MINOR: ssl: support ssl-min-ver and ssl-max-ver with crt-list"

0001-MEDIUM-ssl-disable-SSLv3-per-default-for-bind.patch
Description: Binary data


Re: haproxy does not capture the complete request header host sometimes

2017-05-23 Thread Aleksandar Lazic
Hi siclesang.

siclesang have written on Mon, 22 May 2017 11:11:31 +0800 (CST):

> hi
>  i have a problem:haproxy does not capture the complete  request
> header host sometimes

Which header do you miss?
How long is the header?
 
> i run haroxpy with -d  for some time
> 
> haproxy -vv
> HA-Proxy version 1.6.10 2016/11/20
> Copyright 2000-2016 Willy Tarreau 
> 
> 
> Build options :
>   TARGET  = linux2628
>   CPU = generic
>   CC  = gcc
>   CFLAGS  = -m64 -march=x86-64 -O2 -g -fno-strict-aliasing
> -Wdeclaration-after-statement OPTIONS = USE_ZLIB=1 USE_DLMALLOC=1
> USE_OPENSSL=1 USE_LUA=1 USE_PCRE=1
> 
> 
> Default settings :
>   maxconn = 2000, bufsize = 16384, maxrewrite = 1024, maxpollevents =
> 200
> 
> 
> Encrypted password support via crypt(3): yes
> Built with zlib version : 1.2.11
> Running on zlib version : 1.2.11
> Compression algorithms supported : identity("identity"),
> deflate("deflate"), raw-deflate("deflate"), gzip("gzip") Built with
> OpenSSL version : OpenSSL 1.0.2k  26 Jan 2017 Running on OpenSSL
> version : OpenSSL 1.0.2k  26 Jan 2017 OpenSSL library supports TLS
> extensions : yes OpenSSL library supports SNI : yes
> OpenSSL library supports prefer-server-ciphers : yes
> Built with PCRE version : 7.8 2008-09-05
> Running on PCRE version : 7.8 2008-09-05
> PCRE library supports JIT : no (USE_PCRE_JIT not set)
> Built with Lua version : Lua 5.3.3
> Built with transparent proxy support using: IP_TRANSPARENT
> IPV6_TRANSPARENT IP_FREEBIND
> 
> 
> Available polling systems :
>   epoll : pref=300,  test result OK
>poll : pref=200,  test result OK
>  select : pref=150,  test result OK
> Total: 3 (3 usable), will use epoll.