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
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
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
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
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
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
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
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
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
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
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
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
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,
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
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
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
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,
> >
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
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
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
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
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
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
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 à
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
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
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
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
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,
>
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
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
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
>
>
-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
.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
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
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
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
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
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
39 matches
Mail list logo