Re: Passing SNI value ( ssl_fc_sni ) to backend's verifyhost.

[Willy Tarreau]

On Wed, Jul 26, 2017 at 02:19:19PM -0700, Kevin McArthur wrote:
> TL;DR; The point is the haproxy needs to be able to properly pass on the SNI
> value if its going to verifyhost/verifypeer (even on the check's)... in this
> case the checks dont pass along a sni value, and dont validate a verifyhost
> coming back from the default. Thats probably ok as the purpose of the check
> is just to make sure the host is up, but my concern here would be changing
> behavior going forward.

We try hard never to change behaviours without requiring a config change.
This is important because load balancing is never easy and you don't want
stuff to change below your feet at a moment you don't remember anymore what
needed to be addressed. That's also why wee keep a lot of stuff that some
people think are useless but they are used by a few people. For this reason
we try to limit addition of possibly useless features (less forward
compatiblity to take care of).

> If a check is going to validate its sni/hostname
> going forward I'll have to figure out some sort of self-signed setup for the
> internal.* domains that cant easily be letsenc'd. Alternatively you guys can
> add check-ssl-verifypeer none option or similar, or change the behavior of
> verifyhost to match a default rather than be an override.

After a night on it, I now think I'll try to go down that route. But probably
not today.

Willy

RE: HAProxy 1.7.8 compile problem with new OpenSSL

[Norman Branitsky]

cd /usr/local/src

wget https://www.openssl.org/source/openssl-1.0.2-latest.tar.gz

tar xvf openssl-1.0.2-latest.tar.gz
cd openssl-1.0.2l/



First I tried:

./config

make

make test

make install



Then I tried

./config --prefix=/usr

make INSTALL_PREFIX=/usr

make test

make INSTALL_PREFIX=/usr install



Then I tried

./config --prefix=/usr

make

make test

make INSTALL_PREFIX=/ install



-Original Message-
From: Gibson, Brian (IMS) [mailto:gibs...@imsweb.com]
Sent: July-26-17 5:47 PM
To: haproxy@formilux.org; Norman Branitsky 
Subject: RE: HAProxy 1.7.8 compile problem with new OpenSSL



That would likely break more things. Can you post your build commands for 
openssl?



-Original Message-

From: Norman Branitsky [norman.branit...@micropact.com]

Received: Wednesday, 26 Jul 2017, 5:20PM

To: Gibson, Brian (IMS) [gibs...@imsweb.com]; 
haproxy@formilux.org [haproxy@formilux.org]

Subject: RE: HAProxy 1.7.8 compile problem with new OpenSSL



I found the following folders:

/usr/lib64/openssl

/usr/include/openssl



In /usr/include/openssl/ssl.h, I find the following:

# grep SSL_get0_alpn_selected *

ssl.h:void SSL_get0_alpn_selected(const SSL *ssl, const unsigned char **data,



I modified my make command thus:



make TARGET=linux2628 USE_PCRE=1 USE_SLZ=1 USE_OPENSSL=1 
SSL_INC=/usr/include/openssl SSL_LIB=/usr/lib64/openssl



Compile still fails:



LZ  -DENABLE_POLL -DENABLE_EPOLL -DUSE_CPU_AFFINITY -DASSUME_SPLICE_WORKS 
-DUSE_ACCEPT4 -DNETFILTER -DUSE_GETSOCKNAME -DUSE_OPENSSL 
-I/usr/include/openssl -DUSE_SYSCALL_FUTEX -DUSE_PCRE -I/usr/include  
-DCONFIG_HAPROXY_VERSION=\"1.7.8\" -DCONFIG_HAPROXY_DATE=\"2017/07/07\" -c -o 
ebtree/ebistree.o ebtree/ebistree.c



gcc  -g -o haproxy src/haproxy.o src/base64.o src/protocol.o src/uri_auth.o 
src/standard.o src/buffer.o src/log.o src/task.o src/chunk.o src/channel.o 
src/listener.o src/lru.o src/xxhash.o src/time.o src/fd.o src/pipe.o 
src/regex.o src/cfgparse.o src/server.o src/checks.o src/queue.o src/frontend.o 
src/proxy.o src/peers.o src/arg.o src/stick_table.o src/proto_uxst.o 
src/connection.o src/proto_http.o src/raw_sock.o src/backend.o src/tcp_rules.o 
src/lb_chash.o src/lb_fwlc.o src/lb_fwrr.o src/lb_map.o src/lb_fas.o 
src/stream_interface.o src/stats.o src/proto_tcp.o src/applet.o src/session.o 
src/stream.o src/hdr_idx.o src/ev_select.o src/signal.o src/acl.o src/sample.o 
src/memory.o src/freq_ctr.o src/auth.o src/proto_udp.o src/compression.o 
src/payload.o src/hash.o src/pattern.o src/map.o src/namespace.o src/mailers.o 
src/dns.o src/vars.o src/filters.o src/flt_http_comp.o src/flt_trace.o 
src/flt_spoe.o src/cli.o src/ev_poll.o src/ev_epoll.o src/ssl_sock.o 
src/shctx.o ebtree/ebtree.o ebtree/eb32tree.o ebtree/eb64tree.o 
ebtree/ebmbtree.o ebtree/ebsttree.o ebtree/ebimtree.o ebtree/ebistree.o   
-lcrypt  -lslz -ldl -L/usr/lib64/openssl -lssl -lcrypto -ldl -L/usr/lib 
-lpcreposix -lpcre



src/ssl_sock.o: In function `smp_fetch_ssl_fc_alpn':

/tmp/haproxy-1.7.8/src/ssl_sock.c:4927: undefined reference to 
`SSL_get0_alpn_selected'

src/ssl_sock.o: In function `ssl_sock_load_sctl':

/tmp/haproxy-1.7.8/src/ssl_sock.c:1006: undefined reference to 
`SSL_CTX_add_server_custom_ext'

src/ssl_sock.o: In function `ssl_sock_prepare_ctx':

/tmp/haproxy-1.7.8/src/ssl_sock.c:2879: undefined reference to 
`SSL_CTX_set_alpn_select_cb'

collect2: error: ld returned 1 exit status

make: *** [haproxy] Error 1



The original ssl was installed in /usr/lib64 - should I force the new one to 
install in the same directories overwriting the old?

From: Gibson, Brian (IMS) [mailto:gibs...@imsweb.com]

Sent: July-26-17 3:12 PM

To: Norman Branitsky 
>; 
haproxy@formilux.org

Subject: RE: HAProxy 1.7.8 compile problem with new OpenSSL



I would try this

USE_OPENSSL=1 SSL_INC=/path/to/include SSL_LIB=/path/to/lib



I had to do this myself when using openssl 1.1.0x branch on centos 7, but I 
thought it was because I use a non-default location.



From: Norman Branitsky [mailto:norman.branit...@micropact.com]

Sent: Wednesday, July 26, 2017 2:41 PM

To: 
haproxy@formilux.org>

Subject: HAProxy 1.7.8 compile problem with new OpenSSL



I have no problem compiling HAProxy 1.7.8 on a CentOS 7 box with the default 
distribution of OpenSSL:



uname -a

Linux ip-10-241-7-240 3.10.0-123.20.1.el7.centos.plus.x86_64 #1 SMP Thu Jan 29 
22:05:39 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

openssl version

OpenSSL 1.0.1e-fips 11 Feb 2013



On another server, I upgraded OpenSSL:

# openssl version

OpenSSL 1.0.2l  25 May 2017



This is my make statement:

# make TARGET=linux2628 USE_OPENSSL=1 USE_PCRE=1 USE_SLZ=1



This is the end of the compile output:



gcc  -g -o haproxy src/haproxy.o src/base64.o 

RE: HAProxy 1.7.8 compile problem with new OpenSSL

[Gibson, Brian (IMS)]

That would likely break more things. Can you post your build commands for 
openssl?

-Original Message-
From: Norman Branitsky [norman.branit...@micropact.com]
Received: Wednesday, 26 Jul 2017, 5:20PM
To: Gibson, Brian (IMS) [gibs...@imsweb.com]; haproxy@formilux.org 
[haproxy@formilux.org]
Subject: RE: HAProxy 1.7.8 compile problem with new OpenSSL

I found the following folders:

/usr/lib64/openssl

/usr/include/openssl

In /usr/include/openssl/ssl.h, I find the following:
# grep SSL_get0_alpn_selected *
ssl.h:void SSL_get0_alpn_selected(const SSL *ssl, const unsigned char **data,

I modified my make command thus:

make TARGET=linux2628 USE_PCRE=1 USE_SLZ=1 USE_OPENSSL=1 
SSL_INC=/usr/include/openssl SSL_LIB=/usr/lib64/openssl

Compile still fails:

LZ  -DENABLE_POLL -DENABLE_EPOLL -DUSE_CPU_AFFINITY -DASSUME_SPLICE_WORKS 
-DUSE_ACCEPT4 -DNETFILTER -DUSE_GETSOCKNAME -DUSE_OPENSSL 
-I/usr/include/openssl -DUSE_SYSCALL_FUTEX -DUSE_PCRE -I/usr/include  
-DCONFIG_HAPROXY_VERSION=\"1.7.8\" -DCONFIG_HAPROXY_DATE=\"2017/07/07\" -c -o 
ebtree/ebistree.o ebtree/ebistree.c

gcc  -g -o haproxy src/haproxy.o src/base64.o src/protocol.o src/uri_auth.o 
src/standard.o src/buffer.o src/log.o src/task.o src/chunk.o src/channel.o 
src/listener.o src/lru.o src/xxhash.o src/time.o src/fd.o src/pipe.o 
src/regex.o src/cfgparse.o src/server.o src/checks.o src/queue.o src/frontend.o 
src/proxy.o src/peers.o src/arg.o src/stick_table.o src/proto_uxst.o 
src/connection.o src/proto_http.o src/raw_sock.o src/backend.o src/tcp_rules.o 
src/lb_chash.o src/lb_fwlc.o src/lb_fwrr.o src/lb_map.o src/lb_fas.o 
src/stream_interface.o src/stats.o src/proto_tcp.o src/applet.o src/session.o 
src/stream.o src/hdr_idx.o src/ev_select.o src/signal.o src/acl.o src/sample.o 
src/memory.o src/freq_ctr.o src/auth.o src/proto_udp.o src/compression.o 
src/payload.o src/hash.o src/pattern.o src/map.o src/namespace.o src/mailers.o 
src/dns.o src/vars.o src/filters.o src/flt_http_comp.o src/flt_trace.o 
src/flt_spoe.o src/cli.o src/ev_poll.o src/ev_epoll.o src/ssl_sock.o 
src/shctx.o ebtree/ebtree.o ebtree/eb32tree.o ebtree/eb64tree.o 
ebtree/ebmbtree.o ebtree/ebsttree.o ebtree/ebimtree.o ebtree/ebistree.o   
-lcrypt  -lslz -ldl -L/usr/lib64/openssl -lssl -lcrypto -ldl -L/usr/lib 
-lpcreposix -lpcre

src/ssl_sock.o: In function `smp_fetch_ssl_fc_alpn':

/tmp/haproxy-1.7.8/src/ssl_sock.c:4927: undefined reference to 
`SSL_get0_alpn_selected'

src/ssl_sock.o: In function `ssl_sock_load_sctl':

/tmp/haproxy-1.7.8/src/ssl_sock.c:1006: undefined reference to 
`SSL_CTX_add_server_custom_ext'

src/ssl_sock.o: In function `ssl_sock_prepare_ctx':

/tmp/haproxy-1.7.8/src/ssl_sock.c:2879: undefined reference to 
`SSL_CTX_set_alpn_select_cb'

collect2: error: ld returned 1 exit status

make: *** [haproxy] Error 1

The original ssl was installed in /usr/lib64 –
should I force the new one to install in the same directories overwriting the 
old?
From: Gibson, Brian (IMS) [mailto:gibs...@imsweb.com]
Sent: July-26-17 3:12 PM
To: Norman Branitsky ; haproxy@formilux.org
Subject: RE: HAProxy 1.7.8 compile problem with new OpenSSL

I would try this
USE_OPENSSL=1 SSL_INC=/path/to/include SSL_LIB=/path/to/lib

I had to do this myself when using openssl 1.1.0x branch on centos 7, but I 
thought it was because I use a non-default location.


From: Norman Branitsky [mailto:norman.branit...@micropact.com]
Sent: Wednesday, July 26, 2017 2:41 PM
To: haproxy@formilux.org
Subject: HAProxy 1.7.8 compile problem with new OpenSSL

I have no problem compiling HAProxy 1.7.8 on a CentOS 7 box with the default 
distribution of OpenSSL:

uname -a

Linux ip-10-241-7-240 3.10.0-123.20.1.el7.centos.plus.x86_64 #1 SMP Thu Jan 29 
22:05:39 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

openssl version

OpenSSL 1.0.1e-fips 11 Feb 2013

On another server, I upgraded OpenSSL:

# openssl version

OpenSSL 1.0.2l  25 May 2017

This is my make statement:

# make TARGET=linux2628 USE_OPENSSL=1 USE_PCRE=1 USE_SLZ=1

This is the end of the compile output:

gcc  -g -o haproxy src/haproxy.o src/base64.o src/protocol.o src/uri_auth.o 
src/standard.o src/buffer.o src/log.o src/task.o src/chunk.o src/channel.o 
src/listener.o src/lru.o src/xxhash.o src/time.o src/fd.o src/pipe.o 
src/regex.o src/cfgparse.o src/server.o src/checks.o src/queue.o src/frontend.o 
src/proxy.o src/peers.o src/arg.o src/stick_table.o src/proto_uxst.o 
src/connection.o src/proto_http.o src/raw_sock.o src/backend.o src/tcp_rules.o 
src/lb_chash.o src/lb_fwlc.o src/lb_fwrr.o src/lb_map.o src/lb_fas.o 
src/stream_interface.o src/stats.o src/proto_tcp.o src/applet.o src/session.o 
src/stream.o src/hdr_idx.o src/ev_select.o src/signal.o src/acl.o src/sample.o 
src/memory.o src/freq_ctr.o src/auth.o src/proto_udp.o src/compression.o 
src/payload.o src/hash.o src/pattern.o src/map.o src/namespace.o src/mailers.o 
src/dns.o src/vars.o src/filters.o src/flt_http_comp.o 

RE: HAProxy 1.7.8 compile problem with new OpenSSL

[Norman Branitsky]

I found the following folders:

/usr/lib64/openssl

/usr/include/openssl

In /usr/include/openssl/ssl.h, I find the following:
# grep SSL_get0_alpn_selected *
ssl.h:void SSL_get0_alpn_selected(const SSL *ssl, const unsigned char **data,

I modified my make command thus:

make TARGET=linux2628 USE_PCRE=1 USE_SLZ=1 USE_OPENSSL=1 
SSL_INC=/usr/include/openssl SSL_LIB=/usr/lib64/openssl

Compile still fails:

LZ  -DENABLE_POLL -DENABLE_EPOLL -DUSE_CPU_AFFINITY -DASSUME_SPLICE_WORKS 
-DUSE_ACCEPT4 -DNETFILTER -DUSE_GETSOCKNAME -DUSE_OPENSSL 
-I/usr/include/openssl -DUSE_SYSCALL_FUTEX -DUSE_PCRE -I/usr/include  
-DCONFIG_HAPROXY_VERSION=\"1.7.8\" -DCONFIG_HAPROXY_DATE=\"2017/07/07\" -c -o 
ebtree/ebistree.o ebtree/ebistree.c

gcc  -g -o haproxy src/haproxy.o src/base64.o src/protocol.o src/uri_auth.o 
src/standard.o src/buffer.o src/log.o src/task.o src/chunk.o src/channel.o 
src/listener.o src/lru.o src/xxhash.o src/time.o src/fd.o src/pipe.o 
src/regex.o src/cfgparse.o src/server.o src/checks.o src/queue.o src/frontend.o 
src/proxy.o src/peers.o src/arg.o src/stick_table.o src/proto_uxst.o 
src/connection.o src/proto_http.o src/raw_sock.o src/backend.o src/tcp_rules.o 
src/lb_chash.o src/lb_fwlc.o src/lb_fwrr.o src/lb_map.o src/lb_fas.o 
src/stream_interface.o src/stats.o src/proto_tcp.o src/applet.o src/session.o 
src/stream.o src/hdr_idx.o src/ev_select.o src/signal.o src/acl.o src/sample.o 
src/memory.o src/freq_ctr.o src/auth.o src/proto_udp.o src/compression.o 
src/payload.o src/hash.o src/pattern.o src/map.o src/namespace.o src/mailers.o 
src/dns.o src/vars.o src/filters.o src/flt_http_comp.o src/flt_trace.o 
src/flt_spoe.o src/cli.o src/ev_poll.o src/ev_epoll.o src/ssl_sock.o 
src/shctx.o ebtree/ebtree.o ebtree/eb32tree.o ebtree/eb64tree.o 
ebtree/ebmbtree.o ebtree/ebsttree.o ebtree/ebimtree.o ebtree/ebistree.o   
-lcrypt  -lslz -ldl -L/usr/lib64/openssl -lssl -lcrypto -ldl -L/usr/lib 
-lpcreposix -lpcre

src/ssl_sock.o: In function `smp_fetch_ssl_fc_alpn':

/tmp/haproxy-1.7.8/src/ssl_sock.c:4927: undefined reference to 
`SSL_get0_alpn_selected'

src/ssl_sock.o: In function `ssl_sock_load_sctl':

/tmp/haproxy-1.7.8/src/ssl_sock.c:1006: undefined reference to 
`SSL_CTX_add_server_custom_ext'

src/ssl_sock.o: In function `ssl_sock_prepare_ctx':

/tmp/haproxy-1.7.8/src/ssl_sock.c:2879: undefined reference to 
`SSL_CTX_set_alpn_select_cb'

collect2: error: ld returned 1 exit status

make: *** [haproxy] Error 1

The original ssl was installed in /usr/lib64 -
should I force the new one to install in the same directories overwriting the 
old?
From: Gibson, Brian (IMS) [mailto:gibs...@imsweb.com]
Sent: July-26-17 3:12 PM
To: Norman Branitsky ; haproxy@formilux.org
Subject: RE: HAProxy 1.7.8 compile problem with new OpenSSL

I would try this
USE_OPENSSL=1 SSL_INC=/path/to/include SSL_LIB=/path/to/lib

I had to do this myself when using openssl 1.1.0x branch on centos 7, but I 
thought it was because I use a non-default location.


From: Norman Branitsky [mailto:norman.branit...@micropact.com]
Sent: Wednesday, July 26, 2017 2:41 PM
To: haproxy@formilux.org
Subject: HAProxy 1.7.8 compile problem with new OpenSSL

I have no problem compiling HAProxy 1.7.8 on a CentOS 7 box with the default 
distribution of OpenSSL:

uname -a

Linux ip-10-241-7-240 3.10.0-123.20.1.el7.centos.plus.x86_64 #1 SMP Thu Jan 29 
22:05:39 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

openssl version

OpenSSL 1.0.1e-fips 11 Feb 2013

On another server, I upgraded OpenSSL:

# openssl version

OpenSSL 1.0.2l  25 May 2017

This is my make statement:

# make TARGET=linux2628 USE_OPENSSL=1 USE_PCRE=1 USE_SLZ=1

This is the end of the compile output:

gcc  -g -o haproxy src/haproxy.o src/base64.o src/protocol.o src/uri_auth.o 
src/standard.o src/buffer.o src/log.o src/task.o src/chunk.o src/channel.o 
src/listener.o src/lru.o src/xxhash.o src/time.o src/fd.o src/pipe.o 
src/regex.o src/cfgparse.o src/server.o src/checks.o src/queue.o src/frontend.o 
src/proxy.o src/peers.o src/arg.o src/stick_table.o src/proto_uxst.o 
src/connection.o src/proto_http.o src/raw_sock.o src/backend.o src/tcp_rules.o 
src/lb_chash.o src/lb_fwlc.o src/lb_fwrr.o src/lb_map.o src/lb_fas.o 
src/stream_interface.o src/stats.o src/proto_tcp.o src/applet.o src/session.o 
src/stream.o src/hdr_idx.o src/ev_select.o src/signal.o src/acl.o src/sample.o 
src/memory.o src/freq_ctr.o src/auth.o src/proto_udp.o src/compression.o 
src/payload.o src/hash.o src/pattern.o src/map.o src/namespace.o src/mailers.o 
src/dns.o src/vars.o src/filters.o src/flt_http_comp.o src/flt_trace.o 
src/flt_spoe.o src/cli.o src/ev_poll.o src/ev_epoll.o src/ssl_sock.o 
src/shctx.o ebtree/ebtree.o ebtree/eb32tree.o ebtree/eb64tree.o 
ebtree/ebmbtree.o ebtree/ebsttree.o ebtree/ebimtree.o ebtree/ebistree.o   
-lcrypt  -lslz -ldl  -lssl -lcrypto -ldl -L/usr/lib -lpcreposix -lpcre

src/ssl_sock.o: In function `smp_fetch_ssl_fc_alpn':

Re: Passing SNI value ( ssl_fc_sni ) to backend's verifyhost.

[Kevin McArthur]

The log files would capture whats going on at the HTTP level one would 
presume. I dont actually have a client that speaks HTTP enough to 
mismatch a host/sni and read the responses properly. S-client isnt 
helpful here.


TL;DR; The point is the haproxy needs to be able to properly pass on the 
SNI value if its going to verifyhost/verifypeer (even on the check's)... 
in this case the checks dont pass along a sni value, and dont validate a 
verifyhost coming back from the default. Thats probably ok as the 
purpose of the check is just to make sure the host is up, but my concern 
here would be changing behavior going forward. If a check is going to 
validate its sni/hostname going forward I'll have to figure out some 
sort of self-signed setup for the internal.* domains that cant easily be 
letsenc'd. Alternatively you guys can add check-ssl-verifypeer none 
option or similar, or change the behavior of verifyhost to match a 
default rather than be an override.


--

Kevin


On 2017-07-26 2:15 PM, Willy Tarreau wrote:

On Wed, Jul 26, 2017 at 01:04:05PM -0700, Kevin McArthur wrote:

Here:

In the first example, a valid host, valid sni. Second is valid sni broken
host. Third is totally made up sni with broken host. Fourth is a valid Host
with a made up sni. The apache vhosts have separate log files. The
ssltest.example.ca sni with ssltest-broken.example.ca properly logs to the
ssltest log. The valid host ssltest.example.ca made-up-sni, logs to the app2
vhost (default) logfile. So pretty sure the Host header is being totally
ignored here.

That's very strange. However the test captures only show what is negociated
at the cert level. What matters is what is done at the HTTP layer. But as
long as you're happy with your setup... :-)

Willy

Re: Passing SNI value ( ssl_fc_sni ) to backend's verifyhost.

[Willy Tarreau]

On Wed, Jul 26, 2017 at 01:04:05PM -0700, Kevin McArthur wrote:
> Here:
> 
> In the first example, a valid host, valid sni. Second is valid sni broken
> host. Third is totally made up sni with broken host. Fourth is a valid Host
> with a made up sni. The apache vhosts have separate log files. The
> ssltest.example.ca sni with ssltest-broken.example.ca properly logs to the
> ssltest log. The valid host ssltest.example.ca made-up-sni, logs to the app2
> vhost (default) logfile. So pretty sure the Host header is being totally
> ignored here.

That's very strange. However the test captures only show what is negociated
at the cert level. What matters is what is done at the HTTP layer. But as
long as you're happy with your setup... :-)

Willy

stickiness with cookies or url_param

[ngaugler]

Hello,
  
 I currently configure haproxy to insert and use cookies to determine the 
stickiness of the backend servers.  Unfortunately not every user has cookies 
enabled and some portions of the website would be much more efficient if the 
user was forced to use the server that initiated the process by selecting it 
via the server name defined in a URL parameter.  Since many of the requests to 
the website come from third party sites, I cannot control stickiness completely 
with url parameters.  For other various reasons, I would prefer not to use a 
stick-table and would prefer to use the server name or cookie match to select 
the server.  I would also prefer to not have to setup a backend for every 
single server, due to the scale of the deployment.  Is there any way to tell 
haproxy to leverage a url parameter to select the backend server by name or 
cookie match if the URL parameter exists without using a stick-table?

  


 Here is an example of the isolated configurations:
  
 cookie hlb insert indirect maxidle 600 domain .sub.example.com


server s10153 10.10.10.153:80 cookie s10153
server s10154 10.10.10.154:80 cookie s10154




Thank you,


Nick

Re: Passing SNI value ( ssl_fc_sni ) to backend's verifyhost.

[Kevin McArthur]

Here:

In the first example, a valid host, valid sni. Second is valid sni 
broken host. Third is totally made up sni with broken host. Fourth is a 
valid Host with a made up sni. The apache vhosts have separate log 
files. The ssltest.example.ca sni with ssltest-broken.example.ca 
properly logs to the ssltest log. The valid host ssltest.example.ca 
made-up-sni, logs to the app2 vhost (default) logfile. So pretty sure 
the Host header is being totally ignored here.


printf "GET / HTTP/1.1\r\nHost: ssltest.example.ca\r\n\r\n" | openssl 
s_client -connect internal.app2.example.ca:443 -servername 
ssltest.example.ca CONNECTED(0003) depth=2 O = Digital Signature 
Trust Co., CN = DST Root CA X3 verify return:1 depth=1 C = US, O = Let's 
Encrypt, CN = Let's Encrypt Authority X3 verify return:1 depth=0 CN = 
*ssltest*.example.ca verify return:1 printf "GET / HTTP/1.1\r\nHost: 
ssltest-broken.example.ca\r\n\r\n" | openssl s_client -connect 
internal.app2.example.ca:443 -servername ssltest.example.ca 
CONNECTED(0003) depth=2 O = Digital Signature Trust Co., CN = DST 
Root CA X3 verify return:1 depth=1 C = US, O = Let's Encrypt, CN = Let's 
Encrypt Authority X3 verify return:1 depth=0 CN = *ssltest*.example.ca 
verify return:1 printf "GET / HTTP/1.1\r\nHost: 
ssltest-broken.example.ca\r\n\r\n" | openssl s_client -connect 
internal.app2.example.ca:443 -servername made-up-sni.example.ca 
CONNECTED(0003) depth=2 O = Digital Signature Trust Co., CN = DST 
Root CA X3 verify return:1 depth=1 C = US, O = Let's Encrypt, CN = Let's 
Encrypt Authority X3 verify return:1 depth=0 CN = *app2*.example.ca 
verify return:1 printf "GET / HTTP/1.1\r\nHost: 
ssltest.example.ca\r\n\r\n" | openssl s_client -connect 
internal.app2.example.ca:443 -servername made-up-sni.example.ca 
CONNECTED(0003) depth=2 O = Digital Signature Trust Co., CN = DST 
Root CA X3 verify return:1 depth=1 C = US, O = Let's Encrypt, CN = Let's 
Encrypt Authority X3 verify return:1 depth=0 CN = *app2*.example.ca 
verify return:1



On 2017-07-26 12:49 PM, Willy Tarreau wrote:

On Wed, Jul 26, 2017 at 12:28:55PM -0700, Kevin McArthur wrote:

No, it needs it to select the certificate to present. Then it should match
it against the Host header field, and use the Host header field to select
the vhost. The difference is subtle but it's important to keep each protocol
element one in its role. In the end for HTTP it's always the Host which
decides, regardless of the transport.

Perhaps how it should work but this isn't actually how apache matches vhosts
in a ssl context. They use the SNI, which selects the vhost in use. The host
header can be gibberish and it will still select the vhost via sni when
configured with ServerName directive.

Well it's the first time I hear about this and find this a bit shocking,
as Apache tends to try to follow standards and ignoring Host clearly
doesn't fall into that category and would even cause some security issues
when used as a reverse-proxy by routing the requests to the wrong places.
Also the doc here tends to disagree as well :

https://httpd.apache.org/docs/2.4/vhosts/name-based.html

 "With name-based virtual hosting, the server relies on the client
 to report the hostname as part of the HTTP headers."

So maybe you want to double-check what happens when you do this :

   $ printf "GET / HTTP/1.1\r\nHost: domain1\r\n\r\n | openssl s_client 
-connect host:port -servername domain2
   $ printf "GET / HTTP/1.1\r\nHost: domain2\r\n\r\n | openssl s_client 
-connect host:port -servername domain1

My guess is that either you'll get a 4xx error because there's a mismatch
or you'll get the domain referenced in the Host header delivered.

And by the way I'm seeing this in their changelog for v2.2.26 and v2.2.27 :

   *) mod_ssl: Check SNI hostname against Host header case-insensitively.

   *) mod_ssl: Do not perform SNI / Host header comparison in case of a
 forward proxy request

This tends to confirm that by default the comparison is performed.

Willy

Re: Passing SNI value ( ssl_fc_sni ) to backend's verifyhost.

[Willy Tarreau]

On Wed, Jul 26, 2017 at 12:28:55PM -0700, Kevin McArthur wrote:
> > No, it needs it to select the certificate to present. Then it should match
> > it against the Host header field, and use the Host header field to select
> > the vhost. The difference is subtle but it's important to keep each protocol
> > element one in its role. In the end for HTTP it's always the Host which
> > decides, regardless of the transport.
> Perhaps how it should work but this isn't actually how apache matches vhosts
> in a ssl context. They use the SNI, which selects the vhost in use. The host
> header can be gibberish and it will still select the vhost via sni when
> configured with ServerName directive.

Well it's the first time I hear about this and find this a bit shocking,
as Apache tends to try to follow standards and ignoring Host clearly
doesn't fall into that category and would even cause some security issues
when used as a reverse-proxy by routing the requests to the wrong places.
Also the doc here tends to disagree as well :

   https://httpd.apache.org/docs/2.4/vhosts/name-based.html

"With name-based virtual hosting, the server relies on the client
to report the hostname as part of the HTTP headers."

So maybe you want to double-check what happens when you do this :

  $ printf "GET / HTTP/1.1\r\nHost: domain1\r\n\r\n | openssl s_client -connect 
host:port -servername domain2
  $ printf "GET / HTTP/1.1\r\nHost: domain2\r\n\r\n | openssl s_client -connect 
host:port -servername domain1

My guess is that either you'll get a 4xx error because there's a mismatch
or you'll get the domain referenced in the Host header delivered.

And by the way I'm seeing this in their changelog for v2.2.26 and v2.2.27 :

  *) mod_ssl: Check SNI hostname against Host header case-insensitively.

  *) mod_ssl: Do not perform SNI / Host header comparison in case of a
forward proxy request

This tends to confirm that by default the comparison is performed.

Willy

RE: X-Forwarded-For Balancing

[Trenton Dyck]

Thanks for the help and clarifications.  I will give it a try.

Thanks,
Trent

-Original Message-
From: Aaron West [mailto:aa...@loadbalancer.org] 
Sent: Wednesday, July 26, 2017 3:11 PM
To: Andrew Smalley
Cc: Trenton Dyck; HAproxy Mailing Lists
Subject: Re: X-Forwarded-For Balancing

Trenton,

To clarify I believe it will stick on XFF header if present but if not present 
fall back to stick on source.IP. Basically, it will use the first working 
"stick on" declaration, source IP will always work as there will always be one 
so that goes in as a last resort.

Aaron West

Loadbalancer.org

www.loadbalancer.org
+1 888 867 9504 / +44 (0)330 380 1064
aa...@loadbalancer.org

LEAVE A REVIEW | DEPLOYMENT GUIDES | BLOG


On 26 July 2017 at 19:36, Andrew Smalley  wrote:
> Hi Trenton
>
> Here we use the stick on src ( Source IP ) and X-Forward-For method so 
> we can stick on both criteria
>
> Also the -1 to move the XFF IP back, Imagine there are 2 or 3 proxy's 
> all inserting X-Forward-For the -1 could also be -2 or -3 etc to move 
> the ip forward in the list
>
> 192.168.100.12 172.16.21.20 172.31.31.2
>
> -1 would put the red address like this
>
> 172.16.21.20 172.31.31.2
>
> I hope that all makes sense
>
>
> Andruw Smalley
>
> Loadbalancer.org Ltd.
>
> www.loadbalancer.org
> +1 888 867 9504 / +44 (0)330 380 1064
> asmal...@loadbalancer.org
>
> Leave a Review | Deployment Guides | Blog
>
>
> On 25 July 2017 at 19:42, Trenton Dyck  wrote:
>>
>> Andrew,
>>
>>
>>
>> Thanks for this suggestion!  When you say ‘move the XFF header back’ 
>> and you have a second stick on parameter what is the behavior you 
>> expect? Will it use src ip if no X-Forwarded-For header is present 
>> (our desired behavior)?
>>
>>
>>
>> Thanks,
>>
>> Trent
>>
>>
>>
>> From: Andrew Smalley [mailto:asmal...@loadbalancer.org]
>> Sent: Tuesday, July 25, 2017 12:54 PM
>> To: Trenton Dyck
>> Cc: Aleksandar Lazic; haproxy@formilux.org
>> Subject: Re: X-Forwarded-For Balancing
>>
>>
>>
>> Hi Trenton
>>
>> I hope the below example will help you with X-Forward-For + Stick 
>> table + replication
>>
>> listen VIP_Name
>>
>> bind 192.168.100.50:65435 transparent
>>
>> mode http
>>
>> balance roundrobin
>>
>> option forwardfor if-none
>>
>> stick on hdr(X-Forwarded-For,-1)  # Note the ,-1 is to move the XFF 
>> header back one place in the list.
>>
>> stick on src
>>
>> stick-table type string len 64 size 10240k expire 30m peers 
>> loadbalancer_replication
>>
>> server backup 127.0.0.1:9081 backup  non-stick
>>
>> option http-keep-alive
>>
>> timeout http-request 5s
>>
>> option redispatch
>>
>> option abortonclose
>>
>> maxconn 4
>>
>> server RIP_Name 192.168.100.200:80  weight 100  check  inter 500  
>> rise
>> 1  fall 1  minconn 0  maxconn 0  on-marked-down shutdown-sessions
>>
>> server RIP_Name-1 192.168.100.255:80  weight 100  check  inter 500 
>> rise 1  fall 1  minconn 0  maxconn 0  on-marked-down 
>> shutdown-sessions
>>
>>
>> Andruw Smalley
>>
>> Loadbalancer.org Ltd.
>>
>> www.loadbalancer.org
>>
>> +1 888 867 9504 / +44 (0)330 380 1064
>>
>> asmal...@loadbalancer.org
>>
>> Leave a Review | Deployment Guides | Blog
>>
>>
>>
>> On 25 July 2017 at 17:36, Trenton Dyck 
>> wrote:
>>
>> Hi Alek,
>>
>> I want to balance via round-robin, but I want stick-tables to use the 
>> X-Forwarded-For header instead of src ip.  It makes sense in our use 
>> case because a vast majority of our clients are behind a NAT and have 
>> the same source IP, but the X-Forwarded-For header is unique to them.
>>
>> Thanks,
>> Trent
>>
>>
>> -Original Message-
>> From: Aleksandar Lazic [mailto:al-hapr...@none.at]
>> Sent: Tuesday, July 25, 2017 11:20 AM
>> To: Trenton Dyck
>> Cc: haproxy@formilux.org
>> Subject: Re: X-Forwarded-For Balancing
>>
>> Hi Trenton,
>>
>> Trenton Dyck wrote on 25.07.2017:
>>
>> > Hi,
>> >
>> > Is it possible to balance, via X-Forwarded-For header?  We have 
>> > come across an issue with sticky-sessions and server weight that I 
>> > can't seem to find the answer to online (Unbalanced traffic).  I 
>> > think stick-tables with this acl option  would be nice to have for 
>> > a future version.
>>
>> http://cbonte.github.io/haproxy-dconv/1.7/configuration.html#4-balanc
>> e
>>
>> Something like this
>>
>> balance hdr(X-Forwarded-For)
>>
>> Does it make sense to balance based on this header?!
>> What's the issue you want to solve?
>>
>> What do you mean with "stick-tables with this acl option"?
>>
>> > Please keep met CCed for responses since I'm not subscribed.
>> >
>> > Thanks,
>> >
>> > Trent
>>
>> --
>> Best Regards
>> Aleks
>>
>>
>
>

Re: Passing SNI value ( ssl_fc_sni ) to backend's verifyhost.

[Kevin McArthur]

No, it needs it to select the certificate to present. Then it should match
it against the Host header field, and use the Host header field to select
the vhost. The difference is subtle but it's important to keep each protocol
element one in its role. In the end for HTTP it's always the Host which
decides, regardless of the transport.
Perhaps how it should work but this isn't actually how apache matches 
vhosts in a ssl context. They use the SNI, which selects the vhost in 
use. The host header can be gibberish and it will still select the vhost 
via sni when configured with ServerName directive.


--

Kevin


On 2017-07-26 12:26 PM, Willy Tarreau wrote:

On Wed, Jul 26, 2017 at 11:49:22AM -0700, Kevin McArthur wrote:

I'm still thinking about something like this. What bothers me is that we
already have a ton of "check-something" which are specific to checks, and
if at all I'd rather avoid to add one more.

I was actually wondering if instead we should not consider that verifyhost
presents the *default* value to check against when there's no SNI. From the
perspective of the connection sequence it makes sense : forcing the name
check against an expectedly wrong certificate doesn't make much sense. But
by changing the logic so that SNI overrides verifyhost we could get rid of
this and ensure that health checks continue to work with the name presented
in the default cert.

Technically speaking it would cause a small additional complexity to report
the wrong cert name, but we could have two error codes, one for cert not
matching the SNI and another one for cert not maching verifyhost and I guess
that would solve it.

This would make sense to me. I cant think of a use-case where I'd want to
override the SNI name presented by the client, but a bunch where I'd want to
match the default presented by the backend.

In my case our server naming looks something like

internal.app2.example.ca which is a 10.something address that we cant easily
sign with letsenc (i have to do a dns01 challenge and its all manual
nonsense)...  so for the checks I wouldnt mind telling it to expect the
app2.example.ca hostname in the cert (and configure it to return by
default).

But when its a normal client-requested domain name, I need it to verify
properly against the client's SNI all the way through. If the client asks
for x.example.ca it needs to be secured to the haproxy and the haproxy to
the backend needs full security too.

I totally agree on all of these points. It would also ensure that a lack
of SNI from a client properly lands on the default and expected server
name.


The backend needs the SNI value to select the vhost to serve.

No, it needs it to select the certificate to present. Then it should match
it against the Host header field, and use the Host header field to select
the vhost. The difference is subtle but it's important to keep each protocol
element one in its role. In the end for HTTP it's always the Host which
decides, regardless of the transport.

Willy

Re: Passing SNI value ( ssl_fc_sni ) to backend's verifyhost.

[Willy Tarreau]

On Wed, Jul 26, 2017 at 11:49:22AM -0700, Kevin McArthur wrote:
> > I'm still thinking about something like this. What bothers me is that we
> > already have a ton of "check-something" which are specific to checks, and
> > if at all I'd rather avoid to add one more.
> > 
> > I was actually wondering if instead we should not consider that verifyhost
> > presents the *default* value to check against when there's no SNI. From the
> > perspective of the connection sequence it makes sense : forcing the name
> > check against an expectedly wrong certificate doesn't make much sense. But
> > by changing the logic so that SNI overrides verifyhost we could get rid of
> > this and ensure that health checks continue to work with the name presented
> > in the default cert.
> > 
> > Technically speaking it would cause a small additional complexity to report
> > the wrong cert name, but we could have two error codes, one for cert not
> > matching the SNI and another one for cert not maching verifyhost and I guess
> > that would solve it.
> This would make sense to me. I cant think of a use-case where I'd want to
> override the SNI name presented by the client, but a bunch where I'd want to
> match the default presented by the backend.
> 
> In my case our server naming looks something like
> 
> internal.app2.example.ca which is a 10.something address that we cant easily
> sign with letsenc (i have to do a dns01 challenge and its all manual
> nonsense)...  so for the checks I wouldnt mind telling it to expect the
> app2.example.ca hostname in the cert (and configure it to return by
> default).
> 
> But when its a normal client-requested domain name, I need it to verify
> properly against the client's SNI all the way through. If the client asks
> for x.example.ca it needs to be secured to the haproxy and the haproxy to
> the backend needs full security too.

I totally agree on all of these points. It would also ensure that a lack
of SNI from a client properly lands on the default and expected server
name.

> The backend needs the SNI value to select the vhost to serve.

No, it needs it to select the certificate to present. Then it should match
it against the Host header field, and use the Host header field to select
the vhost. The difference is subtle but it's important to keep each protocol
element one in its role. In the end for HTTP it's always the Host which
decides, regardless of the transport.

Willy

RE: HAProxy 1.7.8 compile problem with new OpenSSL

[Gibson, Brian (IMS)]

I would try this
USE_OPENSSL=1 SSL_INC=/path/to/include SSL_LIB=/path/to/lib

I had to do this myself when using openssl 1.1.0x branch on centos 7, but I 
thought it was because I use a non-default location.


From: Norman Branitsky [mailto:norman.branit...@micropact.com]
Sent: Wednesday, July 26, 2017 2:41 PM
To: haproxy@formilux.org
Subject: HAProxy 1.7.8 compile problem with new OpenSSL

I have no problem compiling HAProxy 1.7.8 on a CentOS 7 box with the default 
distribution of OpenSSL:

uname -a

Linux ip-10-241-7-240 3.10.0-123.20.1.el7.centos.plus.x86_64 #1 SMP Thu Jan 29 
22:05:39 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

openssl version

OpenSSL 1.0.1e-fips 11 Feb 2013

On another server, I upgraded OpenSSL:

# openssl version

OpenSSL 1.0.2l  25 May 2017

This is my make statement:

# make TARGET=linux2628 USE_OPENSSL=1 USE_PCRE=1 USE_SLZ=1

This is the end of the compile output:

gcc  -g -o haproxy src/haproxy.o src/base64.o src/protocol.o src/uri_auth.o 
src/standard.o src/buffer.o src/log.o src/task.o src/chunk.o src/channel.o 
src/listener.o src/lru.o src/xxhash.o src/time.o src/fd.o src/pipe.o 
src/regex.o src/cfgparse.o src/server.o src/checks.o src/queue.o src/frontend.o 
src/proxy.o src/peers.o src/arg.o src/stick_table.o src/proto_uxst.o 
src/connection.o src/proto_http.o src/raw_sock.o src/backend.o src/tcp_rules.o 
src/lb_chash.o src/lb_fwlc.o src/lb_fwrr.o src/lb_map.o src/lb_fas.o 
src/stream_interface.o src/stats.o src/proto_tcp.o src/applet.o src/session.o 
src/stream.o src/hdr_idx.o src/ev_select.o src/signal.o src/acl.o src/sample.o 
src/memory.o src/freq_ctr.o src/auth.o src/proto_udp.o src/compression.o 
src/payload.o src/hash.o src/pattern.o src/map.o src/namespace.o src/mailers.o 
src/dns.o src/vars.o src/filters.o src/flt_http_comp.o src/flt_trace.o 
src/flt_spoe.o src/cli.o src/ev_poll.o src/ev_epoll.o src/ssl_sock.o 
src/shctx.o ebtree/ebtree.o ebtree/eb32tree.o ebtree/eb64tree.o 
ebtree/ebmbtree.o ebtree/ebsttree.o ebtree/ebimtree.o ebtree/ebistree.o   
-lcrypt  -lslz -ldl  -lssl -lcrypto -ldl -L/usr/lib -lpcreposix -lpcre

src/ssl_sock.o: In function `smp_fetch_ssl_fc_alpn':

/tmp/haproxy-1.7.8/src/ssl_sock.c:4927: undefined reference to 
`SSL_get0_alpn_selected'

src/ssl_sock.o: In function `ssl_sock_load_sctl':

/tmp/haproxy-1.7.8/src/ssl_sock.c:1006: undefined reference to 
`SSL_CTX_add_server_custom_ext'

src/ssl_sock.o: In function `ssl_sock_prepare_ctx':

/tmp/haproxy-1.7.8/src/ssl_sock.c:2879: undefined reference to 
`SSL_CTX_set_alpn_select_cb'

collect2: error: ld returned 1 exit status

make: *** [haproxy] Error 1

Norman

Norman Branitsky
Cloud Architect
MicroPact
(o) 416.916.1752
(c) 416.843.0670
(t) 1-888-232-0224 x61752
www.micropact.com
Think it > Track it > Done




Information in this e-mail may be confidential. It is intended only for the 
addressee(s) identified above. If you are not the addressee(s), or an employee 
or agent of the addressee(s), please note that any dissemination, distribution, 
or copying of this communication is strictly prohibited. If you have received 
this e-mail in error, please notify the sender of the error.

Re: X-Forwarded-For Balancing

[Aaron West]

Trenton,

To clarify I believe it will stick on XFF header if present but if not
present fall back to stick on source.IP. Basically, it will use the
first working "stick on" declaration, source IP will always work as
there will always be one so that goes in as a last resort.

Aaron West

Loadbalancer.org

www.loadbalancer.org
+1 888 867 9504 / +44 (0)330 380 1064
aa...@loadbalancer.org

LEAVE A REVIEW | DEPLOYMENT GUIDES | BLOG


On 26 July 2017 at 19:36, Andrew Smalley  wrote:
> Hi Trenton
>
> Here we use the stick on src ( Source IP ) and X-Forward-For method so we
> can stick on both criteria
>
> Also the -1 to move the XFF IP back, Imagine there are 2 or 3 proxy's all
> inserting X-Forward-For the -1 could also be -2 or -3 etc to move the ip
> forward in the list
>
> 192.168.100.12 172.16.21.20 172.31.31.2
>
> -1 would put the red address like this
>
> 172.16.21.20 172.31.31.2
>
> I hope that all makes sense
>
>
> Andruw Smalley
>
> Loadbalancer.org Ltd.
>
> www.loadbalancer.org
> +1 888 867 9504 / +44 (0)330 380 1064
> asmal...@loadbalancer.org
>
> Leave a Review | Deployment Guides | Blog
>
>
> On 25 July 2017 at 19:42, Trenton Dyck  wrote:
>>
>> Andrew,
>>
>>
>>
>> Thanks for this suggestion!  When you say ‘move the XFF header back’ and
>> you have a second stick on parameter what is the behavior you expect? Will
>> it use src ip if no X-Forwarded-For header is present (our desired
>> behavior)?
>>
>>
>>
>> Thanks,
>>
>> Trent
>>
>>
>>
>> From: Andrew Smalley [mailto:asmal...@loadbalancer.org]
>> Sent: Tuesday, July 25, 2017 12:54 PM
>> To: Trenton Dyck
>> Cc: Aleksandar Lazic; haproxy@formilux.org
>> Subject: Re: X-Forwarded-For Balancing
>>
>>
>>
>> Hi Trenton
>>
>> I hope the below example will help you with X-Forward-For + Stick table +
>> replication
>>
>> listen VIP_Name
>>
>> bind 192.168.100.50:65435 transparent
>>
>> mode http
>>
>> balance roundrobin
>>
>> option forwardfor if-none
>>
>> stick on hdr(X-Forwarded-For,-1)  # Note the ,-1 is to move the XFF
>> header back one place in the list.
>>
>> stick on src
>>
>> stick-table type string len 64 size 10240k expire 30m peers
>> loadbalancer_replication
>>
>> server backup 127.0.0.1:9081 backup  non-stick
>>
>> option http-keep-alive
>>
>> timeout http-request 5s
>>
>> option redispatch
>>
>> option abortonclose
>>
>> maxconn 4
>>
>> server RIP_Name 192.168.100.200:80  weight 100  check  inter 500  rise
>> 1  fall 1  minconn 0  maxconn 0  on-marked-down shutdown-sessions
>>
>> server RIP_Name-1 192.168.100.255:80  weight 100  check  inter 500
>> rise 1  fall 1  minconn 0  maxconn 0  on-marked-down shutdown-sessions
>>
>>
>> Andruw Smalley
>>
>> Loadbalancer.org Ltd.
>>
>> www.loadbalancer.org
>>
>> +1 888 867 9504 / +44 (0)330 380 1064
>>
>> asmal...@loadbalancer.org
>>
>> Leave a Review | Deployment Guides | Blog
>>
>>
>>
>> On 25 July 2017 at 17:36, Trenton Dyck 
>> wrote:
>>
>> Hi Alek,
>>
>> I want to balance via round-robin, but I want stick-tables to use the
>> X-Forwarded-For header instead of src ip.  It makes sense in our use case
>> because a vast majority of our clients are behind a NAT and have the same
>> source IP, but the X-Forwarded-For header is unique to them.
>>
>> Thanks,
>> Trent
>>
>>
>> -Original Message-
>> From: Aleksandar Lazic [mailto:al-hapr...@none.at]
>> Sent: Tuesday, July 25, 2017 11:20 AM
>> To: Trenton Dyck
>> Cc: haproxy@formilux.org
>> Subject: Re: X-Forwarded-For Balancing
>>
>> Hi Trenton,
>>
>> Trenton Dyck wrote on 25.07.2017:
>>
>> > Hi,
>> >
>> > Is it possible to balance, via X-Forwarded-For header?  We have come
>> > across an issue with sticky-sessions and server weight that I can't
>> > seem to find the answer to online (Unbalanced traffic).  I think
>> > stick-tables with this acl option  would be nice to have for a future
>> > version.
>>
>> http://cbonte.github.io/haproxy-dconv/1.7/configuration.html#4-balance
>>
>> Something like this
>>
>> balance hdr(X-Forwarded-For)
>>
>> Does it make sense to balance based on this header?!
>> What's the issue you want to solve?
>>
>> What do you mean with "stick-tables with this acl option"?
>>
>> > Please keep met CCed for responses since I'm not subscribed.
>> >
>> > Thanks,
>> >
>> > Trent
>>
>> --
>> Best Regards
>> Aleks
>>
>>
>
>

Re: Passing SNI value ( ssl_fc_sni ) to backend's verifyhost.

[Kevin McArthur]

I'm still thinking about something like this. What bothers me is that we
already have a ton of "check-something" which are specific to checks, and
if at all I'd rather avoid to add one more.

I was actually wondering if instead we should not consider that verifyhost
presents the *default* value to check against when there's no SNI. From the
perspective of the connection sequence it makes sense : forcing the name
check against an expectedly wrong certificate doesn't make much sense. But
by changing the logic so that SNI overrides verifyhost we could get rid of
this and ensure that health checks continue to work with the name presented
in the default cert.

Technically speaking it would cause a small additional complexity to report
the wrong cert name, but we could have two error codes, one for cert not
matching the SNI and another one for cert not maching verifyhost and I guess
that would solve it.
This would make sense to me. I cant think of a use-case where I'd want 
to override the SNI name presented by the client, but a bunch where I'd 
want to match the default presented by the backend.


In my case our server naming looks something like

internal.app2.example.ca which is a 10.something address that we cant 
easily sign with letsenc (i have to do a dns01 challenge and its all 
manual nonsense)...  so for the checks I wouldnt mind telling it to 
expect the app2.example.ca hostname in the cert (and configure it to 
return by default).


But when its a normal client-requested domain name, I need it to verify 
properly against the client's SNI all the way through. If the client 
asks for x.example.ca it needs to be secured to the haproxy and the 
haproxy to the backend needs full security too. The backend needs the 
SNI value to select the vhost to serve.


--

Kevin



On 2017-07-26 11:39 AM, Willy Tarreau wrote:

On Wed, Jul 26, 2017 at 11:25:18AM -0700, Kevin McArthur wrote:

One last thing; the health check process seems to be ignoring the cert
validation logic entirely. Could be the same pathway re default cert though.

In fact it's only enabled when verifyhost is in use, but here that
would mean forcing verifyhost which would be bad.


Its not actually important that we have tls protection on the health check,
but it should be explicitly configured I think, otherwise a future version
that corrects this will run into people needing to generate certificates for
internal servers or completely turn off checking.

Perhaps a check-ssl-verifypeer and check-ssl-verifyhost setting might make
sense to go with check-ssl?

I'm still thinking about something like this. What bothers me is that we
already have a ton of "check-something" which are specific to checks, and
if at all I'd rather avoid to add one more.

I was actually wondering if instead we should not consider that verifyhost
presents the *default* value to check against when there's no SNI. From the
perspective of the connection sequence it makes sense : forcing the name
check against an expectedly wrong certificate doesn't make much sense. But
by changing the logic so that SNI overrides verifyhost we could get rid of
this and ensure that health checks continue to work with the name presented
in the default cert.

Technically speaking it would cause a small additional complexity to report
the wrong cert name, but we could have two error codes, one for cert not
matching the SNI and another one for cert not maching verifyhost and I guess
that would solve it.

So the patches are probably not final...

Willy

HAProxy 1.7.8 compile problem with new OpenSSL

[Norman Branitsky]

I have no problem compiling HAProxy 1.7.8 on a CentOS 7 box with the default 
distribution of OpenSSL:

uname -a

Linux ip-10-241-7-240 3.10.0-123.20.1.el7.centos.plus.x86_64 #1 SMP Thu Jan 29 
22:05:39 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

openssl version

OpenSSL 1.0.1e-fips 11 Feb 2013

On another server, I upgraded OpenSSL:

# openssl version

OpenSSL 1.0.2l  25 May 2017

This is my make statement:

# make TARGET=linux2628 USE_OPENSSL=1 USE_PCRE=1 USE_SLZ=1

This is the end of the compile output:

gcc  -g -o haproxy src/haproxy.o src/base64.o src/protocol.o src/uri_auth.o 
src/standard.o src/buffer.o src/log.o src/task.o src/chunk.o src/channel.o 
src/listener.o src/lru.o src/xxhash.o src/time.o src/fd.o src/pipe.o 
src/regex.o src/cfgparse.o src/server.o src/checks.o src/queue.o src/frontend.o 
src/proxy.o src/peers.o src/arg.o src/stick_table.o src/proto_uxst.o 
src/connection.o src/proto_http.o src/raw_sock.o src/backend.o src/tcp_rules.o 
src/lb_chash.o src/lb_fwlc.o src/lb_fwrr.o src/lb_map.o src/lb_fas.o 
src/stream_interface.o src/stats.o src/proto_tcp.o src/applet.o src/session.o 
src/stream.o src/hdr_idx.o src/ev_select.o src/signal.o src/acl.o src/sample.o 
src/memory.o src/freq_ctr.o src/auth.o src/proto_udp.o src/compression.o 
src/payload.o src/hash.o src/pattern.o src/map.o src/namespace.o src/mailers.o 
src/dns.o src/vars.o src/filters.o src/flt_http_comp.o src/flt_trace.o 
src/flt_spoe.o src/cli.o src/ev_poll.o src/ev_epoll.o src/ssl_sock.o 
src/shctx.o ebtree/ebtree.o ebtree/eb32tree.o ebtree/eb64tree.o 
ebtree/ebmbtree.o ebtree/ebsttree.o ebtree/ebimtree.o ebtree/ebistree.o   
-lcrypt  -lslz -ldl  -lssl -lcrypto -ldl -L/usr/lib -lpcreposix -lpcre

src/ssl_sock.o: In function `smp_fetch_ssl_fc_alpn':

/tmp/haproxy-1.7.8/src/ssl_sock.c:4927: undefined reference to 
`SSL_get0_alpn_selected'

src/ssl_sock.o: In function `ssl_sock_load_sctl':

/tmp/haproxy-1.7.8/src/ssl_sock.c:1006: undefined reference to 
`SSL_CTX_add_server_custom_ext'

src/ssl_sock.o: In function `ssl_sock_prepare_ctx':

/tmp/haproxy-1.7.8/src/ssl_sock.c:2879: undefined reference to 
`SSL_CTX_set_alpn_select_cb'

collect2: error: ld returned 1 exit status

make: *** [haproxy] Error 1

Norman

Norman Branitsky
Cloud Architect
MicroPact
(o) 416.916.1752
(c) 416.843.0670
(t) 1-888-232-0224 x61752
www.micropact.com
Think it > Track it > Done

Re: Passing SNI value ( ssl_fc_sni ) to backend's verifyhost.

[Willy Tarreau]

On Wed, Jul 26, 2017 at 11:38:47AM -0700, Kevin McArthur wrote:
> > However I have a good news. I found that it was possible to access the
> > connection from the verify callback! With a connection comes the ability
> > to place a specific error code which we can verify later. So I did this,
> > 1) add a new error code for a wrong certificate, and 2) add the check for
> > this specific use case (ie: cert name verification failed against a non-
> > hardcoded value, so fail immediately). It now immediately reports the
> > 503 and you don't have the retries anymore.
> 
> This patch is working flawlessly.
> 
> +1 to adding all three patches to master.

Thanks for testing. Let's sleep over this series to see if we can do
something better for the checks before merging all of this.

Willy

Re: Passing SNI value ( ssl_fc_sni ) to backend's verifyhost.

[Willy Tarreau]

On Wed, Jul 26, 2017 at 11:25:18AM -0700, Kevin McArthur wrote:
> One last thing; the health check process seems to be ignoring the cert
> validation logic entirely. Could be the same pathway re default cert though.

In fact it's only enabled when verifyhost is in use, but here that
would mean forcing verifyhost which would be bad.

> Its not actually important that we have tls protection on the health check,
> but it should be explicitly configured I think, otherwise a future version
> that corrects this will run into people needing to generate certificates for
> internal servers or completely turn off checking.
> 
> Perhaps a check-ssl-verifypeer and check-ssl-verifyhost setting might make
> sense to go with check-ssl?

I'm still thinking about something like this. What bothers me is that we
already have a ton of "check-something" which are specific to checks, and
if at all I'd rather avoid to add one more.

I was actually wondering if instead we should not consider that verifyhost
presents the *default* value to check against when there's no SNI. From the
perspective of the connection sequence it makes sense : forcing the name
check against an expectedly wrong certificate doesn't make much sense. But
by changing the logic so that SNI overrides verifyhost we could get rid of
this and ensure that health checks continue to work with the name presented
in the default cert.

Technically speaking it would cause a small additional complexity to report
the wrong cert name, but we could have two error codes, one for cert not
matching the SNI and another one for cert not maching verifyhost and I guess
that would solve it.

So the patches are probably not final...

Willy

Re: Passing SNI value ( ssl_fc_sni ) to backend's verifyhost.

[Kevin McArthur]

However I have a good news. I found that it was possible to access the
connection from the verify callback! With a connection comes the ability
to place a specific error code which we can verify later. So I did this,
1) add a new error code for a wrong certificate, and 2) add the check for
this specific use case (ie: cert name verification failed against a non-
hardcoded value, so fail immediately). It now immediately reports the
503 and you don't have the retries anymore.


This patch is working flawlessly.

+1 to adding all three patches to master.

--

Kevin


On 2017-07-26 11:27 AM, Willy Tarreau wrote:

On Wed, Jul 26, 2017 at 09:58:57AM -0700, Kevin McArthur wrote:

This seems to stop the primary vector. I can still tie up a valid sni with a
misconfigured backend, but I'm not sure that would be a client-controlled
condition.

And more importantly, the client's SNI is not the only source of SNI,
there are other valid use cases.


Perhaps strict-sni should be defaulted?

No, it would be a pain to a lot of people (ie making it impossible for
a hosting provider to present an error page by default). And as mentionned
above, it would only address the issue in your use case, not all of them.

However I have a good news. I found that it was possible to access the
connection from the verify callback! With a connection comes the ability
to place a specific error code which we can verify later. So I did this,
1) add a new error code for a wrong certificate, and 2) add the check for
this specific use case (ie: cert name verification failed against a non-
hardcoded value, so fail immediately). It now immediately reports the
503 and you don't have the retries anymore.

I'm attaching the two patches that I intend to merge if there's no
objection.

Willy

Re: X-Forwarded-For Balancing

[Andrew Smalley]

Hi Trenton

Here we use the stick on src ( Source IP ) and X-Forward-For method so we
can stick on both criteria

Also the -1 to move the XFF IP back, Imagine there are 2 or 3 proxy's all
inserting X-Forward-For the -1 could also be -2 or -3 etc to move the ip
forward in the list

192.168.100.12 172.16.21.20 172.31.31.2

-1 would put the red address like this

172.16.21.20 172.31.31.2

I hope that all makes sense


Andruw Smalley

Loadbalancer.org Ltd.
www.loadbalancer.org 






+1 888 867 9504 / +44 (0)330 380 1064
asmal...@loadbalancer.org

Leave a Review
 | Deployment
Guides

| Blog 

On 25 July 2017 at 19:42, Trenton Dyck  wrote:

> Andrew,
>
>
>
> Thanks for this suggestion!  When you say ‘move the XFF header back’ and
> you have a second stick on parameter what is the behavior you expect? Will
> it use src ip if no X-Forwarded-For header is present (our desired
> behavior)?
>
>
>
> Thanks,
>
> Trent
>
>
>
> *From:* Andrew Smalley [mailto:asmal...@loadbalancer.org]
> *Sent:* Tuesday, July 25, 2017 12:54 PM
> *To:* Trenton Dyck
> *Cc:* Aleksandar Lazic; haproxy@formilux.org
> *Subject:* Re: X-Forwarded-For Balancing
>
>
>
> Hi Trenton
>
> I hope the below example will help you with X-Forward-For + Stick table +
> replication
>
> listen VIP_Name
>
> bind 192.168.100.50:65435 transparent
>
> mode http
>
> balance roundrobin
>
> option forwardfor if-none
>
> stick on hdr(X-Forwarded-For,-1)  # Note the ,-1 is to move the XFF 
> header back one place in the list.
>
> stick on src
>
> stick-table type string len 64 size 10240k expire 30m peers 
> loadbalancer_replication
>
> server backup 127.0.0.1:9081 backup  non-stick
>
> option http-keep-alive
>
> timeout http-request 5s
>
> option redispatch
>
> option abortonclose
>
> maxconn 4
>
> server RIP_Name 192.168.100.200:80  weight 100  check  inter 500  rise 1  
> fall 1  minconn 0  maxconn 0  on-marked-down shutdown-sessions
>
> server RIP_Name-1 192.168.100.255:80  weight 100  check  inter 500  rise 
> 1  fall 1  minconn 0  maxconn 0  on-marked-down shutdown-sessions
>
>
> Andruw Smalley
>
> Loadbalancer.org Ltd.
>
> www.loadbalancer.org 
>
> 
> 
> 
> 
>
> 
>
> +1 888 867 9504 / +44 (0)330 380 1064
>
> asmal...@loadbalancer.org
>
> Leave a Review
>  | Deployment
> Guides
> 
> | Blog 
>
>
>
> On 25 July 2017 at 17:36, Trenton Dyck 
> wrote:
>
> Hi Alek,
>
> I want to balance via round-robin, but I want stick-tables to use the
> X-Forwarded-For header instead of src ip.  It makes sense in our use case
> because a vast majority of our clients are behind a NAT and have the same
> source IP, but the X-Forwarded-For header is unique to them.
>
> Thanks,
> Trent
>
>
> -Original Message-
> From: Aleksandar Lazic [mailto:al-hapr...@none.at]
> Sent: Tuesday, July 25, 2017 11:20 AM
> To: Trenton Dyck
> Cc: haproxy@formilux.org
> Subject: Re: X-Forwarded-For Balancing
>
> Hi Trenton,
>
> Trenton Dyck wrote on 25.07.2017:
>
> > Hi,
> >
> > Is it possible to balance, via X-Forwarded-For header?  We have come
> > across an issue with sticky-sessions and server weight that I can't
> > seem to find the answer to online (Unbalanced traffic).  I think
> > stick-tables with this acl option  would be nice to have for a future
> version.
>
> http://cbonte.github.io/haproxy-dconv/1.7/configuration.html#4-balance
>
> Something like this
>
> balance hdr(X-Forwarded-For)
>
> Does it make sense to balance based on this header?!
> What's the issue you want to solve?
>
> What do you mean with "stick-tables with this acl option"?
>
> > Please keep met CCed for responses since I'm not subscribed.
> >
> > Thanks,
> >
> > Trent
>
> --
> Best Regards
> Aleks
>
>
>

Re: Passing SNI value ( ssl_fc_sni ) to backend's verifyhost.

[Kevin McArthur]

Awesome. I'll try this out right now.

--

Kevin


On 2017-07-26 11:27 AM, Willy Tarreau wrote:

On Wed, Jul 26, 2017 at 09:58:57AM -0700, Kevin McArthur wrote:

This seems to stop the primary vector. I can still tie up a valid sni with a
misconfigured backend, but I'm not sure that would be a client-controlled
condition.

And more importantly, the client's SNI is not the only source of SNI,
there are other valid use cases.


Perhaps strict-sni should be defaulted?

No, it would be a pain to a lot of people (ie making it impossible for
a hosting provider to present an error page by default). And as mentionned
above, it would only address the issue in your use case, not all of them.

However I have a good news. I found that it was possible to access the
connection from the verify callback! With a connection comes the ability
to place a specific error code which we can verify later. So I did this,
1) add a new error code for a wrong certificate, and 2) add the check for
this specific use case (ie: cert name verification failed against a non-
hardcoded value, so fail immediately). It now immediately reports the
503 and you don't have the retries anymore.

I'm attaching the two patches that I intend to merge if there's no
objection.

Willy

Re: Passing SNI value ( ssl_fc_sni ) to backend's verifyhost.

[Willy Tarreau]

On Wed, Jul 26, 2017 at 09:58:57AM -0700, Kevin McArthur wrote:
> This seems to stop the primary vector. I can still tie up a valid sni with a
> misconfigured backend, but I'm not sure that would be a client-controlled
> condition.

And more importantly, the client's SNI is not the only source of SNI,
there are other valid use cases.

> Perhaps strict-sni should be defaulted?

No, it would be a pain to a lot of people (ie making it impossible for
a hosting provider to present an error page by default). And as mentionned
above, it would only address the issue in your use case, not all of them.

However I have a good news. I found that it was possible to access the
connection from the verify callback! With a connection comes the ability
to place a specific error code which we can verify later. So I did this,
1) add a new error code for a wrong certificate, and 2) add the check for
this specific use case (ie: cert name verification failed against a non-
hardcoded value, so fail immediately). It now immediately reports the
503 and you don't have the retries anymore.

I'm attaching the two patches that I intend to merge if there's no
objection.

Willy
>From d0880fd22431b8f65654b77a0c4c681265fe1131 Mon Sep 17 00:00:00 2001
From: Willy Tarreau 
Date: Wed, 26 Jul 2017 20:09:56 +0200
Subject: MINOR: ssl: add a new error code for wrong server certificates

If a server presents an unexpected certificate to haproxy, that is, a
certificate that doesn't match the expected name as configured in
verifyhost or as requested using SNI, we want to store that precious
information. Fortunately we have access to the connection in the
verification callback so it's possible to store an error code there.

For this purpose we use CO_ER_SSL_WRONG_CRT.
---
 include/proto/connection.h | 1 +
 include/types/connection.h | 1 +
 src/ssl_sock.c | 3 +++
 3 files changed, 5 insertions(+)

diff --git a/include/proto/connection.h b/include/proto/connection.h
index 09467ba..2f00863 100644
--- a/include/proto/connection.h
+++ b/include/proto/connection.h
@@ -605,6 +605,7 @@ static inline const char *conn_err_code_str(struct 
connection *c)
case CO_ER_SSL_RENEG: return "Rejected a client-initiated SSL 
renegociation attempt";
case CO_ER_SSL_CA_FAIL:   return "SSL client CA chain cannot be 
verified";
case CO_ER_SSL_CRT_FAIL:  return "SSL client certificate not trusted";
+   case CO_ER_SSL_WRONG_CRT: return "Server presented an SSL certificate 
for a wrong name";
case CO_ER_SSL_HANDSHAKE: return "SSL handshake failure";
case CO_ER_SSL_HANDSHAKE_HB: return "SSL handshake failure after 
heartbeat";
case CO_ER_SSL_KILLED_HB: return "Stopped a TLSv1 heartbeat attack 
(CVE-2014-0160)";
diff --git a/include/types/connection.h b/include/types/connection.h
index 1e3fb73..4b5b5d3 100644
--- a/include/types/connection.h
+++ b/include/types/connection.h
@@ -179,6 +179,7 @@ enum {
CO_ER_SSL_RENEG,/* forbidden client renegociation */
CO_ER_SSL_CA_FAIL,  /* client cert verification failed in the CA 
chain */
CO_ER_SSL_CRT_FAIL, /* client cert verification failed on the 
certificate */
+   CO_ER_SSL_WRONG_CRT,/* server presented a certificate for a wrong 
server */
CO_ER_SSL_HANDSHAKE,/* SSL error during handshake */
CO_ER_SSL_HANDSHAKE_HB, /* SSL error during handshake with heartbeat 
present */
CO_ER_SSL_KILLED_HB,/* Stopped a TLSv1 heartbeat attack 
(CVE-2014-0160) */
diff --git a/src/ssl_sock.c b/src/ssl_sock.c
index 42d27de..be75d5b 100644
--- a/src/ssl_sock.c
+++ b/src/ssl_sock.c
@@ -4001,6 +4001,9 @@ static int ssl_sock_srv_verifycbk(int ok, X509_STORE_CTX 
*ctx)
}
}
 
+   /* report the mismatch */
+   if (!ok && !conn->err_code)
+   conn->err_code = CO_ER_SSL_WRONG_CRT;
return ok;
 }
 
-- 
1.7.12.1

>From 88dc39b889b511304222f4eaf8498e5df8ed7610 Mon Sep 17 00:00:00 2001
From: Willy Tarreau 
Date: Wed, 26 Jul 2017 20:13:37 +0200
Subject: BUG/MEDIUM: stream: don't retry SSL connections which fail the
 hostname check

Commits 2ab8867 ("MINOR: ssl: compare server certificate names to the
SNI on outgoing connections") and 96c7b8d ("BUG/MINOR: ssl: Fix check
against SNI during server certificate verification") made it possible
to check that the server's certificate matches the name presented in
the SNI field. While it solves a class of problems, it opens another
one which is that by failing such a connection, we'll retry it and put
more load on the server. It can be a real problem if a user can trigger
this issue, which is what will very often happen when the SNI is forwarded
from the client to the server.

This patch solves this by detecting that this very specific hostname
verification failed and that the hostname was provided using SNI, and
then it simply disables retries and the failure is immediate.

At the time of writing this 

Re: Passing SNI value ( ssl_fc_sni ) to backend's verifyhost.

[Kevin McArthur]

One last thing; the health check process seems to be ignoring the cert 
validation logic entirely. Could be the same pathway re default cert 
though.


Its not actually important that we have tls protection on the health 
check, but it should be explicitly configured I think, otherwise a 
future version that corrects this will run into people needing to 
generate certificates for internal servers or completely turn off checking.


Perhaps a check-ssl-verifypeer and check-ssl-verifyhost setting might 
make sense to go with check-ssl?


--

Kevin


On 2017-07-26 9:57 AM, Kevin McArthur wrote:



On 2017-07-26 9:55 AM, Willy Tarreau wrote:

On Wed, Jul 26, 2017 at 09:39:03AM -0700, Kevin McArthur wrote:
Interesting. I'd probably recommend not pushing this patch out then 
until

this can be fixed as it will be trivial to resource-exploit a haproxy
instance that is exhibiting a client-controlled retry.

For now we're in development and the previous one was already merged, so
I'd rather merge Christopher's patch at least to benefit from his 
analysis
and from the better solution than the one I came up with. For the 
release

that's a different story though.

Fair enough, I just would be weary the release.



A quick try with a
script that generates randomized SNI names shows I can open connmax and
crash the haproxy from a single instance pretty readily.

What do you mean by "crash haproxy" ? Do you instead mean that it runs
out of connection and cannot connect to the server anymore or that you
managed to kill the process ? Because for me "crash" is this last one
and is a much more serious concern.

The former, just ties up all the connections.
If there's other errors that the client can control that lead to a 
retry

like this, they're probably worthy of a CVE.

It takes approximately 5s per connection to clear the connection in 
this

condition.

I'll see if retries 0 will work for our use case, but I'd hate to 
think we'd

have to give up non-client-controlled retry support entirely (ie for a
backend apache restart, retry to another app server...) due to this.

That's why I warned you that it was a tradeoff :-)

~_~


Willy

--
Kevin

Re: Passing SNI value ( ssl_fc_sni ) to backend's verifyhost.

[Kevin McArthur]

This seems to stop the primary vector. I can still tie up a valid sni 
with a misconfigured backend, but I'm not sure that would be a 
client-controlled condition.


Perhaps strict-sni should be defaulted?

--

Kevin


On 2017-07-26 9:53 AM, Emmanuel Hocdet wrote:

Hi Kevin,


Le 26 juil. 2017 à 18:39, Kevin McArthur  a écrit :

Interesting. I'd probably recommend not pushing this patch out then until this 
can be fixed as it will be trivial to resource-exploit a haproxy instance that 
is exhibiting a client-controlled retry. A quick try with a script that 
generates randomized SNI names shows I can open connmax and crash the haproxy 
from a single instance pretty readily.

If there's other errors that the client can control that lead to a retry like 
this, they're probably worthy of a CVE.

It takes approximately 5s per connection to clear the connection in this 
condition.

I'll see if retries 0 will work for our use case, but I'd hate to think we'd 
have to give up non-client-controlled retry support entirely (ie for a backend 
apache restart, retry to another app server...) due to this.

—


Yon can add ‘strict-sni’ on bind line to reject all requests with an unknown 
sni.

Manu

Re: Passing SNI value ( ssl_fc_sni ) to backend's verifyhost.

[Kevin McArthur]

On 2017-07-26 9:55 AM, Willy Tarreau wrote:

On Wed, Jul 26, 2017 at 09:39:03AM -0700, Kevin McArthur wrote:

Interesting. I'd probably recommend not pushing this patch out then until
this can be fixed as it will be trivial to resource-exploit a haproxy
instance that is exhibiting a client-controlled retry.

For now we're in development and the previous one was already merged, so
I'd rather merge Christopher's patch at least to benefit from his analysis
and from the better solution than the one I came up with. For the release
that's a different story though.

Fair enough, I just would be weary the release.



A quick try with a
script that generates randomized SNI names shows I can open connmax and
crash the haproxy from a single instance pretty readily.

What do you mean by "crash haproxy" ? Do you instead mean that it runs
out of connection and cannot connect to the server anymore or that you
managed to kill the process ? Because for me "crash" is this last one
and is a much more serious concern.

The former, just ties up all the connections.

If there's other errors that the client can control that lead to a retry
like this, they're probably worthy of a CVE.

It takes approximately 5s per connection to clear the connection in this
condition.

I'll see if retries 0 will work for our use case, but I'd hate to think we'd
have to give up non-client-controlled retry support entirely (ie for a
backend apache restart, retry to another app server...) due to this.

That's why I warned you that it was a tradeoff :-)

~_~


Willy

--
Kevin

Re: Passing SNI value ( ssl_fc_sni ) to backend's verifyhost.

[Willy Tarreau]

On Wed, Jul 26, 2017 at 09:39:03AM -0700, Kevin McArthur wrote:
> Interesting. I'd probably recommend not pushing this patch out then until
> this can be fixed as it will be trivial to resource-exploit a haproxy
> instance that is exhibiting a client-controlled retry.

For now we're in development and the previous one was already merged, so
I'd rather merge Christopher's patch at least to benefit from his analysis
and from the better solution than the one I came up with. For the release
that's a different story though.

> A quick try with a
> script that generates randomized SNI names shows I can open connmax and
> crash the haproxy from a single instance pretty readily.

What do you mean by "crash haproxy" ? Do you instead mean that it runs
out of connection and cannot connect to the server anymore or that you
managed to kill the process ? Because for me "crash" is this last one
and is a much more serious concern.

> If there's other errors that the client can control that lead to a retry
> like this, they're probably worthy of a CVE.
> 
> It takes approximately 5s per connection to clear the connection in this
> condition.
> 
> I'll see if retries 0 will work for our use case, but I'd hate to think we'd
> have to give up non-client-controlled retry support entirely (ie for a
> backend apache restart, retry to another app server...) due to this.

That's why I warned you that it was a tradeoff :-)

Willy

Re: Passing SNI value ( ssl_fc_sni ) to backend's verifyhost.

[Emmanuel Hocdet]

Hi Kevin,

> Le 26 juil. 2017 à 18:39, Kevin McArthur  a écrit :
> 
> Interesting. I'd probably recommend not pushing this patch out then until 
> this can be fixed as it will be trivial to resource-exploit a haproxy 
> instance that is exhibiting a client-controlled retry. A quick try with a 
> script that generates randomized SNI names shows I can open connmax and crash 
> the haproxy from a single instance pretty readily.
> 
> If there's other errors that the client can control that lead to a retry like 
> this, they're probably worthy of a CVE.
> 
> It takes approximately 5s per connection to clear the connection in this 
> condition.
> 
> I'll see if retries 0 will work for our use case, but I'd hate to think we'd 
> have to give up non-client-controlled retry support entirely (ie for a 
> backend apache restart, retry to another app server...) due to this.
> 
> —


Yon can add ‘strict-sni’ on bind line to reject all requests with an unknown 
sni.

Manu

Re: Passing SNI value ( ssl_fc_sni ) to backend's verifyhost.

[Kevin McArthur]

Interesting. I'd probably recommend not pushing this patch out then 
until this can be fixed as it will be trivial to resource-exploit a 
haproxy instance that is exhibiting a client-controlled retry. A quick 
try with a script that generates randomized SNI names shows I can open 
connmax and crash the haproxy from a single instance pretty readily.


If there's other errors that the client can control that lead to a retry 
like this, they're probably worthy of a CVE.


It takes approximately 5s per connection to clear the connection in this 
condition.


I'll see if retries 0 will work for our use case, but I'd hate to think 
we'd have to give up non-client-controlled retry support entirely (ie 
for a backend apache restart, retry to another app server...) due to this.


--

Kevin





On 2017-07-26 9:26 AM, Willy Tarreau wrote:

On Wed, Jul 26, 2017 at 09:14:08AM -0700, Kevin McArthur wrote:

Looks like this patch works re verifyhost but I think there's still a
problem here. A browser that tries to load an invalid sni name now produces
4 tries to the backend with about a second delay between each attempt,
amplifying the problem. It also takes a good 5 seconds for the connections
to cleanup/close on failure.

That's the normal behaviour here which confirms it works for you (the
previous code does exactly this for me, though after discussing with
Christopher we still fail to understand precisely why it works with
my version of openssl and none with his nor yours but that's another
story).

The thing is that the layer deciding to retry the connection does it
when there is a connection error. An SSL handshake failure is one of
the many possible connection errors. This could be caused by various
things including a server which is a bit slow to start or to load its
certificates.

For now we have no way to say "don't retry if there is this or that
specific type of connection error". Also passing the information that a
failed handshake is caused by a non-matching SNI is further complicated
as everything is done using callbacks at these layers.

The best I can recommend you for now is to set "retries 0" in your
backend to disable connection retries. Ideally we should try to
enumerate the type of errors that should lead to no retry because they
may be controlled by the client.

Regards,
Willy

Re: Passing SNI value ( ssl_fc_sni ) to backend's verifyhost.

[Willy Tarreau]

On Wed, Jul 26, 2017 at 09:14:08AM -0700, Kevin McArthur wrote:
> Looks like this patch works re verifyhost but I think there's still a
> problem here. A browser that tries to load an invalid sni name now produces
> 4 tries to the backend with about a second delay between each attempt,
> amplifying the problem. It also takes a good 5 seconds for the connections
> to cleanup/close on failure.

That's the normal behaviour here which confirms it works for you (the
previous code does exactly this for me, though after discussing with
Christopher we still fail to understand precisely why it works with
my version of openssl and none with his nor yours but that's another
story).

The thing is that the layer deciding to retry the connection does it
when there is a connection error. An SSL handshake failure is one of
the many possible connection errors. This could be caused by various
things including a server which is a bit slow to start or to load its
certificates.

For now we have no way to say "don't retry if there is this or that
specific type of connection error". Also passing the information that a
failed handshake is caused by a non-matching SNI is further complicated
as everything is done using callbacks at these layers.

The best I can recommend you for now is to set "retries 0" in your
backend to disable connection retries. Ideally we should try to
enumerate the type of errors that should lead to no retry because they
may be controlled by the client.

Regards,
Willy

Re: Passing SNI value ( ssl_fc_sni ) to backend's verifyhost.

[Kevin McArthur]

Looks like this patch works re verifyhost but I think there's still a 
problem here. A browser that tries to load an invalid sni name now 
produces 4 tries to the backend with about a second delay between each 
attempt, amplifying the problem. It also takes a good 5 seconds for the 
connections to cleanup/close on failure. Pretty sure this could lead to 
resource exhaustion, etc... Perhaps this needs a caching strategy?


[WARNING] 206/160620 (19914) : Health check for server 
www-backend-https/app2 succeeded, reason: Layer6 check passed, check 
duration: 6ms, status: 3/3 UP.:www-https.accept(0004)=0006 from 
[::::33139] 
ALPN=0001:www-https.accept(0004)=0005 from 
[::::45709] 
ALPN=:www-https.clireq[0006:]: GET / 
HTTP/1.1:www-https.clihdr[0006:]: Host: 
ssltest.example.ca:www-https.clihdr[0006:]: Connection: 
keep-alive:www-https.clihdr[0006:]: 
Upgrade-Insecure-Requests: 1:www-https.clihdr[0006:]: 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) 
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.115 
Safari/537.36:www-https.clihdr[0006:]: Accept: 
text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8:www-https.clihdr[0006:]: 
Accept-Encoding: gzip, deflate, 
br:www-https.clihdr[0006:]: Accept-Language: 
en-US,en;q=0.8:www-backend-https.srvrep[0006:0007]: HTTP/1.1 200 
OK:www-backend-https.srvhdr[0006:0007]: Date: Wed, 26 Jul 2017 
16:06:51 GMT:www-backend-https.srvhdr[0006:0007]: Server: 
Apache:www-backend-https.srvhdr[0006:0007]: Vary: 
Accept-Encoding:www-backend-https.srvhdr[0006:0007]: 
Content-Encoding: gzip:www-backend-https.srvhdr[0006:0007]: 
Content-Length: 458:www-backend-https.srvhdr[0006:0007]: 
Connection: close:www-backend-https.srvhdr[0006:0007]: 
Content-Type: text/html; 
charset=UTF-8:www-backend-https.srvcls[0006:0007]0002:www-https.clireq[0006:]: 
GET /favicon.ico HTTP/1.10002:www-https.clihdr[0006:]: Host: 
ssltest.example.ca0002:www-https.clihdr[0006:]: Connection: 
keep-alive0002:www-https.clihdr[0006:]: User-Agent: 
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 
(KHTML, like Gecko) Chrome/59.0.3071.115 
Safari/537.360002:www-https.clihdr[0006:]: Accept: 
image/webp,image/apng,image/*,*/*;q=0.80002:www-https.clihdr[0006:]: 
Referer: 
https://ssltest.example.ca/0002:www-https.clihdr[0006:]: 
Accept-Encoding: gzip, deflate, 
br0002:www-https.clihdr[0006:]: Accept-Language: 
en-US,en;q=0.80002:www-backend-https.srvrep[0006:0007]: HTTP/1.1 404 
Not Found0002:www-backend-https.srvhdr[0006:0007]: Date: Wed, 26 Jul 
2017 16:06:51 GMT0002:www-backend-https.srvhdr[0006:0007]: Server: 
Apache0002:www-backend-https.srvhdr[0006:0007]: Content-Length: 
2090002:www-backend-https.srvhdr[0006:0007]: Connection: 
close0002:www-backend-https.srvhdr[0006:0007]: Content-Type: 
text/html; 
charset=iso-8859-10002:www-backend-https.srvcls[0006:0007]0004:www-https.accept(0004)=0007 
from [::::41712] 
ALPN=0005:www-https.accept(0004)=0008 from 
[::::35597] 
ALPN=0004:www-https.clireq[0007:]: GET / 
HTTP/1.10004:www-https.clihdr[0007:]: Host: 
ssltest-broken.example.ca0004:www-https.clihdr[0007:]: 
Connection: keep-alive0004:www-https.clihdr[0007:]: 
Upgrade-Insecure-Requests: 10004:www-https.clihdr[0007:]: 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) 
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.115 
Safari/537.360004:www-https.clihdr[0007:]: Accept: 
text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.80004:www-https.clihdr[0007:]: 
Accept-Encoding: gzip, deflate, 
br0004:www-https.clihdr[0007:]: Accept-Language: 
en-US,en;q=0.8*fd[0009] OpenSSL error[0x14090086] 
ssl3_get_server_certificate: certificate verify failedfd[0009] 
OpenSSL error[0x14090086] ssl3_get_server_certificate: certificate 
verify failedfd[0009] OpenSSL error[0x14090086] 
ssl3_get_server_certificate: certificate verify failedfd[0009] 
OpenSSL error[0x14090086] ssl3_get_server_certificate: certificate 
verify 
failed*0004:www-backend-https.clicls[0007:adfd]0004:www-backend-https.closed[0007:adfd]0005:www-https.clireq[0008:]: 
GET /favicon.ico HTTP/1.10005:www-https.clihdr[0008:]: Host: 
ssltest-broken.example.ca0005:www-https.clihdr[0008:]: 
Connection: keep-alive0005:www-https.clihdr[0008:]: 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) 
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.115 
Safari/537.360005:www-https.clihdr[0008:]: Accept: 

Persistence cookie "secure" on frontend

[Marco Corte]

Hi all.

A frontend listen both for HTTP and for HTTPS.
It should set the "Secure" attribute to the cookies over the encypted 
channel and not on the others.


Here are the relevant lines of the configuration

frontend XXX-FE
  bind 10.64.44.160:80  name HTTP
  bind 10.64.44.160:443 name HTTPS ssl crt /etc/ssl/private/XXX.pem
  mode http
  http-request set-header X-Forwarded-Proto https if { ssl_fc }
  http-response set-header Strict-Transport-Security max-age=1600;\ 
includeSubDomains if { ssl_fc }

  http-response replace-header Set-Cookie (.*) \1;\ Secure if { ssl_fc }
  use_backend XXX if { path_beg -i /AAA }

backend XXX
  mode http
  cookie rs insert indirect nocache httponly maxidle 1h
  server serverA 10.64.44.155:80 check cookie A
  server serverB 10.64.44.156:80 check cookie B

Testing with curl https://someserver/something.aspx the response has the 
following headers


HTTP/1.1 200 OK
Cache-Control: no-cache
Pragma: no-cache
Content-Length: 12450
Content-Type: text/html; charset=utf-8
Expires: -1
Server: Microsoft-IIS/8.5
X-AspNet-Version: 2.0.50727
Set-Cookie: ASP.NET=1hj2c; path=/; HttpOnly; Secure <- from server
X-Powered-By: ASP.NET
Date: Wed, 26 Jul 2017 14:40:11 GMT
Strict-Transport-Security: max-age=1600; includeSubDomains
Set-Cookie: rs=A|WXipz; path=/; HttpOnly <- from haproxy


It seems that the "Set-Cookie" coming from the real server correctly has 
the "Secure" attribute set by the frontend, while the load-balancing one 
does not.

Is this the expected behaviour?

Thank you

.marcoc

Re: FW: https status codes

[Aleksandar Lazic]

Hi Andy.

Franks Andy (IT Technical Architecture Manager) wrote on 26.07.2017:


> -Original Message-
> From: Franks Andy (IT Technical Architecture Manager) 
> Sent: 26 July 2017 13:52
> To: 'Aleksandar Lazic'
> Subject: RE: https status codes

> Thanks Alexander.
> I'd imagine that
>
> option httpchk GET /Login/Heartbeat HTTP/1.1\r\nHost:\ rsh-cp-iis1
>
> presents the same rsh-cp-iis1 to both the iis1 and iis2 server? It
> seems to work like this with the way I got it working, i.e. option
> httpchk GET https://rsh-cp-iis1/Login/Heartbeat, but I would need
> rsh-cp-iis1 "name" to be presented to that server, and iis2 to the
> iis2 server and so on, could be an eventual list of quite a few backends.

as I understand you right you want to do something like this.

pseudo code:

for host in iis1 iis2 ... iisN do
  check GET /Login/Heartbeat HTTP/1.1\r\nHost:\ $host

I don't know if this is possible with lua, with 'normal' haproxy I don't 
think so that this is possible.

But should the vhost not be the same on all servers?

> I'll have a look at the resolver you suggested though..
> Thanks again
> Andy

> -Original Message-
> From: Aleksandar Lazic [mailto:al-hapr...@none.at] 
> Sent: 26 July 2017 12:00
> To: Franks Andy (IT Technical Architecture Manager)
> Cc: haproxy@formilux.org
> Subject: Re: https status codes

> Hi Andy,

> Franks Andy (IT Technical Architecture Manager) wrote on 26.07.2017:

>> Hi all,
>>
>> HAProxy 1.7.6
>>  
>>   I have a hopefully easy question to answer - I'm trying to do server 
>> checks against 2x IIS nodes which require sending of the destination 
>> host name (virtual hosts) before delivering content. I'm trying to 
>> work out how to send the backend  server name with the check request. 
>> At the moment the IIS server
>>
>> isn't seeing the name, rather an IP address as far as I can tell, and 
>> responding with a 404.
>>  
>> This is the config
>>  
>>backend bk_web_ssl
>>   mode http
>>   option httplog
>>   option httpchk GET https://rsh-cp-iis1/Login/Heartbeat

> As described in the doc you just need to add the host header.

> http://cbonte.github.io/haproxy-dconv/1.7/configuration.html#4-option%20httpchk

> option httpchk GET /Login/Heartbeat HTTP/1.1\r\nHost:\ rsh-cp-iis1


>>   http-check expect rstatus 200
>>   balance roundrobin
>>   stick on src table connections
>>   cookie SERVERID insert nocache indirect
>>   server RSH-CP-IIS1 192.168.176.175:443 cookie 1 check ssl
>>   server RSH-CP-IIS2 192.168.176.176:443 cookie 2 check ssl
>>  
>>  
>> I can sort of get it to work on one of the two by including that 
>> servers name in the option httpchk line as seen:
>>  
>>   option httpchk GET https://rsh-cp-iis1/Login/Heartbeat
>>  
>> .. but would rather just do option httpchk GET /Login/Heartbeat
>>  
>> ..And something like 
>>   server RSH-CP-IIS1 RSH-CP-IIS1:443 cookie 1 check ssl
>>   server RSH-CP-IIS2 RSH-CP-IIS2:443 cookie 2 check ssl

> When you want to use names you will need to add a resolver in 1.7.

> http://cbonte.github.io/haproxy-dconv/1.7/configuration.html#5.3
>   
>> Is there some keyword I'm missing somewhere or a better way of doing this?
>>  
>> Thanks
>> Andy

-- 
Best Regards
Aleks

FW: https status codes

[Franks Andy (IT Technical Architecture Manager)]

-Original Message-
From: Franks Andy (IT Technical Architecture Manager) 
Sent: 26 July 2017 13:52
To: 'Aleksandar Lazic'
Subject: RE: https status codes

Thanks Alexander.
I'd imagine that 
option httpchk GET /Login/Heartbeat HTTP/1.1\r\nHost:\ rsh-cp-iis1
presents the same rsh-cp-iis1 to both the iis1 and iis2 server? It seems to 
work like this with the way I got it working, i.e. option httpchk GET 
https://rsh-cp-iis1/Login/Heartbeat, but I would need rsh-cp-iis1 "name" to be 
presented to that server, and iis2 to the iis2 server and so on, could be an 
eventual list of quite a few backends.

I'll have a look at the resolver you suggested though..
Thanks again
Andy

-Original Message-
From: Aleksandar Lazic [mailto:al-hapr...@none.at] 
Sent: 26 July 2017 12:00
To: Franks Andy (IT Technical Architecture Manager)
Cc: haproxy@formilux.org
Subject: Re: https status codes

Hi Andy,

Franks Andy (IT Technical Architecture Manager) wrote on 26.07.2017:

> Hi all,
>
> HAProxy 1.7.6
>  
>   I have a hopefully easy question to answer - I'm trying to do server 
> checks against 2x IIS nodes which require sending of the destination 
> host name (virtual hosts) before delivering content. I'm trying to 
> work out how to send the backend  server name with the check request. 
> At the moment the IIS server
>
> isn't seeing the name, rather an IP address as far as I can tell, and 
> responding with a 404.
>  
> This is the config
>  
>backend bk_web_ssl
>   mode http
>   option httplog
>   option httpchk GET https://rsh-cp-iis1/Login/Heartbeat

As described in the doc you just need to add the host header.

http://cbonte.github.io/haproxy-dconv/1.7/configuration.html#4-option%20httpchk

option httpchk GET /Login/Heartbeat HTTP/1.1\r\nHost:\ rsh-cp-iis1


>   http-check expect rstatus 200
>   balance roundrobin
>   stick on src table connections
>   cookie SERVERID insert nocache indirect
>   server RSH-CP-IIS1 192.168.176.175:443 cookie 1 check ssl
>   server RSH-CP-IIS2 192.168.176.176:443 cookie 2 check ssl
>  
>  
> I can sort of get it to work on one of the two by including that 
> servers name in the option httpchk line as seen:
>  
>   option httpchk GET https://rsh-cp-iis1/Login/Heartbeat
>  
> .. but would rather just do option httpchk GET /Login/Heartbeat
>  
> ..And something like 
>   server RSH-CP-IIS1 RSH-CP-IIS1:443 cookie 1 check ssl
>   server RSH-CP-IIS2 RSH-CP-IIS2:443 cookie 2 check ssl

When you want to use names you will need to add a resolver in 1.7.

http://cbonte.github.io/haproxy-dconv/1.7/configuration.html#5.3
  
> Is there some keyword I'm missing somewhere or a better way of doing this?
>  
> Thanks
> Andy

--
Best Regards
Aleks

Re: Passing SNI value ( ssl_fc_sni ) to backend's verifyhost.

[Christopher Faulet]

.Le 25/07/2017 à 19:37, Kevin McArthur a écrit :

Hi Willy,

I cant replicate your results here

I cloned from git and built the package with the debian/ubuntu build 
scripts from https://launchpad.net/~vbernat/+archive/ubuntu/haproxy-1.7 
... updating the changelog to add a 1.8-dev2 version and calling 
./debian/rules binary to build the package.


The git log shows:

commit 2ab88675ecbf960a6f33ffe9c6a27f264150b201
Author: Willy Tarreau 
Date:   Wed Jul 5 18:23:03 2017 +0200

 MINOR: ssl: compare server certificate names to the SNI on
outgoing connections




Hi,

There is a bug in this commit. I checked with openssl 1.0.2l and 1.1.0f 
and I observed the same behavior than Kevin's one. 
SSL_SESSION_get0_hostname seems to always return NULL when the server 
returns a default certificate.


It tried to explain why in my commit log.

Kevin, could you check the patch in attachment to confirm it works ?

--
Christopher Faulet
>From afe2d426c6aeb82aa11af842e8f75f54a2d9130d Mon Sep 17 00:00:00 2001
From: Christopher Faulet 
Date: Wed, 26 Jul 2017 11:50:01 +0200
Subject: [PATCH] BUG/MINOR: ssl: Fix check against SNI during server
 certificate verification

This patch fixes the commit 2ab8867 ("MINOR: ssl: compare server certificate
names to the SNI on outgoing connections")

When we check the certificate sent by a server, in the verify callback, we get
the SNI from the session (SSL_SESSION object). In OpenSSL, tlsext_hostname value
for this session is copied from the ssl connection (SSL object). But the copy is
done only if the "server_name" extension is found in the server hello
message. This means the server has found a certificate matching the client's
SNI.

When the server returns a default certificate not matching the client's SNI, it
doesn't set any "server_name" extension in the server hello message. So no SNI
is set on the SSL session and SSL_SESSION_get0_hostname always returns NULL.

To fix the problemn, we get the SNI directly from the SSL connection. It is
always defined with the value set by the client.

If the commit 2ab8867 is backported in 1.7 and/or 1.8, this one must be
backported too.
---
 include/proto/openssl-compat.h | 5 -
 src/ssl_sock.c | 6 +-
 2 files changed, 1 insertion(+), 10 deletions(-)

diff --git a/include/proto/openssl-compat.h b/include/proto/openssl-compat.h
index a1e75b47..ea92072e 100644
--- a/include/proto/openssl-compat.h
+++ b/include/proto/openssl-compat.h
@@ -94,11 +94,6 @@ static inline int SSL_SESSION_set1_id_context(SSL_SESSION *s, const unsigned cha
  * Functions introduced in OpenSSL 1.1.0 and not yet present in LibreSSL
  */
 
-static inline const char *SSL_SESSION_get0_hostname(const SSL_SESSION *sess)
-{
-   return sess->tlsext_hostname;
-}
-
 static inline const unsigned char *SSL_SESSION_get0_id_context(const SSL_SESSION *sess, unsigned int *sid_ctx_length)
 {
 	*sid_ctx_length = sess->sid_ctx_length;
diff --git a/src/ssl_sock.c b/src/ssl_sock.c
index fa815715..42d27de9 100644
--- a/src/ssl_sock.c
+++ b/src/ssl_sock.c
@@ -3951,11 +3951,7 @@ static int ssl_sock_srv_verifycbk(int ok, X509_STORE_CTX *ctx)
 	 */
 	servername = objt_server(conn->target)->ssl_ctx.verify_host;
 	if (!servername) {
-		SSL_SESSION *ssl_sess = SSL_get_session(conn->xprt_ctx);
-		if (!ssl_sess)
-			return ok;
-
-		servername = SSL_SESSION_get0_hostname(ssl_sess);
+		servername = SSL_get_servername(conn->xprt_ctx, TLSEXT_NAMETYPE_host_name);
 		if (!servername)
 			return ok;
 	}
-- 
2.13.3

Re: Fix building haproxy with recent LibreSSL

[Bernard Spil]

On 2017-07-25 17:03, Bernard Spil wrote:

On 2017-07-04 10:18, Willy Tarreau wrote:

On Tue, Jul 04, 2017 at 11:12:20AM +0300, Dmitry Sivachenko wrote:

>> https://www.mail-archive.com/haproxy@formilux.org/msg25819.html
>
>
> Do you know if the patch applies to 1.8 (it was mangled so I didn't try).


Sorry, hit reply too fast:  no, one chunk fails against 1.8-dev2 (the 
one
dealing with #ifdef SSL_CTX_get_tlsext_status_arg, it requires 
analysis

because it is not simple surrounding context change).


OK thanks. Bernard, care to have a look and ensure it works for you ?

Thanks,
Willy


I've just committed a patch to FreeBSD's ports tree for haproxy-devel
(1.8-dev2). This would be a good candidate to include.

Not sure if attachments work for the mailing-list...
https://svnweb.freebsd.org/ports/head/net/haproxy-devel/files/patch-src_ssl__sock.c

Cheers,

Bernard.


Just committed the fix to FreeBSD ports for 1.7.8 as well
https://svnweb.freebsd.org/changeset/ports/446652

With kind regards,
Bernard Spil.

Re: https status codes

[Aleksandar Lazic]

Hi Andy,

Franks Andy (IT Technical Architecture Manager) wrote on 26.07.2017:

> Hi all,
>
> HAProxy 1.7.6
>  
>   I have a hopefully easy question to answer – I’m trying to do
> server checks against 2x IIS nodes which require sending of the
> destination host name (virtual hosts) before delivering content. I’m
> trying to work out how to send the backend  server name with the check
> request. At the moment the IIS server 
>
> isn’t seeing the name, rather an IP address as far as I can tell, and 
> responding with a 404.
>  
> This is the config
>  
>backend bk_web_ssl
>   mode http
>   option httplog
>   option httpchk GET https://rsh-cp-iis1/Login/Heartbeat

As described in the doc you just need to add the host header.

http://cbonte.github.io/haproxy-dconv/1.7/configuration.html#4-option%20httpchk

option httpchk GET /Login/Heartbeat HTTP/1.1\r\nHost:\ rsh-cp-iis1


>   http-check expect rstatus 200
>   balance roundrobin
>   stick on src table connections
>   cookie SERVERID insert nocache indirect
>   server RSH-CP-IIS1 192.168.176.175:443 cookie 1 check ssl
>   server RSH-CP-IIS2 192.168.176.176:443 cookie 2 check ssl
>  
>  
> I can sort of get it to work on one of the two by including that
> servers name in the option httpchk line as seen:
>  
>   option httpchk GET https://rsh-cp-iis1/Login/Heartbeat
>  
> .. but would rather just do option httpchk GET /Login/Heartbeat
>  
> ..And something like 
>   server RSH-CP-IIS1 RSH-CP-IIS1:443 cookie 1 check ssl
>   server RSH-CP-IIS2 RSH-CP-IIS2:443 cookie 2 check ssl

When you want to use names you will need to add a resolver in 1.7.

http://cbonte.github.io/haproxy-dconv/1.7/configuration.html#5.3
  
> Is there some keyword I’m missing somewhere or a better way of doing this?
>  
> Thanks
> Andy

-- 
Best Regards
Aleks

gzip compression and logging response size

[Michał Pasierb]

Hi,

I would like to log size of response before and after compression. Is it
possible ?
I see this question was asked before at
http://thread.gmane.org/gmane.comp.web.haproxy/10008 without any resolution.

Regards,
Michal

https status codes

[Franks Andy (IT Technical Architecture Manager)]

Hi all,

HAProxy 1.7.6

  I have a hopefully easy question to answer - I'm trying to do server checks 
against 2x IIS nodes which require sending of the destination host name 
(virtual hosts) before delivering content. I'm trying to work out how to send 
the backend server name with the check request. At the moment the IIS server
isn't seeing the name, rather an IP address as far as I can tell, and 
responding with a 404.

This is the config

   backend bk_web_ssl
  mode http
  option httplog
  option httpchk GET https://rsh-cp-iis1/Login/Heartbeat
  http-check expect rstatus 200
  balance roundrobin
   stick on src table connections
  cookie SERVERID insert nocache indirect
  server RSH-CP-IIS1 192.168.176.175:443 cookie 1 check ssl
  server RSH-CP-IIS2 192.168.176.176:443 cookie 2 check ssl


I can sort of get it to work on one of the two by including that servers name 
in the option httpchk line as seen:

  option httpchk GET https://rsh-cp-iis1/Login/Heartbeat

.. but would rather just do option httpchk GET /Login/Heartbeat

..And something like
  server RSH-CP-IIS1 RSH-CP-IIS1:443 cookie 1 check ssl
  server RSH-CP-IIS2 RSH-CP-IIS2:443 cookie 2 check ssl

Is there some keyword I'm missing somewhere or a better way of doing this?

Thanks
Andy

[PATCH] Fix-bitwise-logic-for-hlua_server_check*

[Adis Nezirovic]

Hello guys,

Here is a fix for bug in
hlua_server_check_enable()/hlua_server_check_disable, the bitwise logic
in the code was inverted.

This can be applied to 1.7 too.

Best regards,
Adis
>From b51318ab44cb904f9689aebe27f61a41a26240cc Mon Sep 17 00:00:00 2001
From: Adis Nezirovic 
Date: Wed, 26 Jul 2017 09:19:06 +0200
Subject: [PATCH] BUG/MINOR: lua: Fix bitwise logic for hlua_server_check_*
 functions.

The logical operations were inverted so enable/disable operations did
the oposite.
---
 src/hlua_fcn.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/hlua_fcn.c b/src/hlua_fcn.c
index 69926132..bc6bc914 100644
--- a/src/hlua_fcn.c
+++ b/src/hlua_fcn.c
@@ -662,7 +662,7 @@ int hlua_server_check_enable(lua_State *L)
 
 	sv = hlua_check_server(L, 1);
 	if (sv->check.state & CHK_ST_CONFIGURED) {
-		sv->check.state &= ~CHK_ST_ENABLED;
+		sv->check.state |= CHK_ST_ENABLED;
 	}
 	return 0;
 }
@@ -673,7 +673,7 @@ int hlua_server_check_disable(lua_State *L)
 
 	sv = hlua_check_server(L, 1);
 	if (sv->check.state & CHK_ST_CONFIGURED) {
-		sv->check.state |= CHK_ST_ENABLED;
+		sv->check.state &= ~CHK_ST_ENABLED;
 	}
 	return 0;
 }
-- 
2.13.3