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

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

RE: HAProxy 1.7.8 compile problem with new OpenSSL

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

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

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

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

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

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

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

stickiness with cookies or url_param

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

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

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

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

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

RE: X-Forwarded-For Balancing

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

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

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

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

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

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,

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

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

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

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

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

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, > >

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

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

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

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

Re: X-Forwarded-For Balancing

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

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

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

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

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

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

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

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

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 à

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

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

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

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

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

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

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

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

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

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, >

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

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

Persistence cookie "secure" on frontend

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

Re: FW: https status codes

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 > >

FW: https status codes

-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

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

.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

Re: Fix building haproxy with recent LibreSSL

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

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

gzip compression and logging response size

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

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

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

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