On Fri, Jul 28, 2017 at 03:28:53PM -0700, Kevin McArthur wrote:
> > I really think that for most users it will be fine this way as it has been
> > for 5 years, and for me that justifies not trying to go too far for the
> > short
> > term.
> Fair enough, but don't forget that for the last 5 years f
I really think that for most users it will be fine this way as it has been
for 5 years, and for me that justifies not trying to go too far for the short
term.
Fair enough, but don't forget that for the last 5 years folks have just
been setting verify none in all the tutorials lol!
--
Kevin
O
On Fri, Jul 28, 2017 at 03:11:20PM -0700, Kevin McArthur wrote:
> More flexibility in deployment is usually a good thing so long as they have
> sane defaults. Its certainly fine to say that one has to setup an internal
> ca to get a secured check. Its just more moving parts.
Which is also more dif
On 2017-07-28 2:21 PM, Willy Tarreau wrote:
On Fri, Jul 28, 2017 at 10:24:47AM -0700, Kevin McArthur wrote:
I would propose something like the following:
New options:
check-ssl-sni (optional) .. set the value to send as sni. Defaults to the
value from the server hostname being connected. (Co
On Fri, Jul 28, 2017 at 10:24:47AM -0700, Kevin McArthur wrote:
> I would propose something like the following:
>
> New options:
>
> check-ssl-sni (optional) .. set the value to send as sni. Defaults to the
> value from the server hostname being connected. (Could be nullable? or
> another setting
On Fri, Jul 28, 2017 at 10:04:54AM -0700, Kevin McArthur wrote:
> If I add a verifyhost directive, all the normal connections identified by
> SNI break.
Huh ? Are you sure you correctly applied the patch set ? That's the
behaviour of the previous one. I've got the exact opposite here. With
verifyh
I would propose something like the following:
New options:
check-ssl-sni (optional) .. set the value to send as sni. Defaults to
the value from the server hostname being connected. (Could be nullable?
or another setting like check-sni-disable added)
check-ssl-verify (optional). required/none
On 2017-07-28 10:02 AM, Willy Tarreau wrote:
On Fri, Jul 28, 2017 at 09:46:12AM -0700, Kevin McArthur wrote:
I think somethings missing here; the check system doesn't seem to be sending
the SNI or validating the result.
If I do a backend line like:
server app2 internal.app2.example.ca:443 ss
On Fri, Jul 28, 2017 at 09:46:12AM -0700, Kevin McArthur wrote:
> I think somethings missing here; the check system doesn't seem to be sending
> the SNI or validating the result.
>
> If I do a backend line like:
>
> server app2 internal.app2.example.ca:443 ssl verify required sni ssl_fc_sni
> ca-
I think somethings missing here; the check system doesn't seem to be
sending the SNI or validating the result.
If I do a backend line like:
server app2 internal.app2.example.ca:443 ssl verify required sni
ssl_fc_sni ca-file /etc/ssl/certs/ca-certificates.crt check check-ssl
This works fine,
On Fri, Jul 28, 2017 at 08:45:37AM -0700, Kevin McArthur wrote:
> Sounds good Willy, where did we leave the issue of the SNI,
> verifypeer/verifyhost validation and the checks subsystem?
the checks are now covered by verifyhost as they used to, that
was the main purpose.
Willy
Sounds good Willy, where did we leave the issue of the SNI,
verifypeer/verifyhost validation and the checks subsystem?
--
Kevin
On 2017-07-28 3:11 AM, Willy Tarreau wrote:
Hi,
On Thu, Jul 27, 2017 at 05:17:36AM +0200, Willy Tarreau wrote:
On Wed, Jul 26, 2017 at 02:19:19PM -0700, Kevin McArt
Hi,
On Thu, Jul 27, 2017 at 05:17:36AM +0200, Willy Tarreau wrote:
> On Wed, Jul 26, 2017 at 02:19:19PM -0700, Kevin McArthur wrote:
> > 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 can
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
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
SN
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
>
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
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 protoc
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 wonderin
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
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)
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 forc
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 sp
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 cli
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 S
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 ve
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
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-contr
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 quick try with a
> sc
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
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
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
.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 a
On 2017-07-25 10:51 AM, Willy Tarreau wrote:
On Tue, Jul 25, 2017 at 10:37:10AM -0700, Kevin McArthur wrote:
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/hapro
On Tue, Jul 25, 2017 at 10:37:10AM -0700, Kevin McArthur wrote:
> 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
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 pac
Hi again Kevin,
On Tue, Jul 25, 2017 at 07:26:07AM +0200, Willy Tarreau wrote:
> > frontend www-https
> > bind :::443 v4v6 ssl crt /etc/haproxy/certs/default.example.ca.pem crt
> > /etc/haproxy/certs/
> > use_backend www-backend-https
> >
> > backend www-backend-https
> > server app d
Hi Kevin,
On Mon, Jul 24, 2017 at 04:00:04PM -0700, Kevin McArthur wrote:
> To replicate my results:
>
> Generate 3 ssl certificates (letsenc? I used a dns-01 challenge...)..
>
> default.example.ca
> working.example.ca
> should-be-broken.example.ca
>
> Configure an apache instance to serve only
To replicate my results:
Generate 3 ssl certificates (letsenc? I used a dns-01 challenge...)..
default.example.ca
working.example.ca
should-be-broken.example.ca
Configure an apache instance to serve only the first two via https.
default.example.ca and working.example.ca; don't configure any
v
Hi Willy,
I can confirm the following line does _not_ verify the hostname on the
backend.
server app2 ssltest.example.ca:443 ssl verify required sni
ssl_fc_sni ca-file /etc/ssl/certs/ca-certificates.crt check check-ssl
I setup a default https vhost on the backend server, that responds t
Hi Kevin,
On Fri, Jul 21, 2017 at 02:06:52PM -0700, Kevin McArthur wrote:
> Further... the odd/broken behavior might be being caused related to no sni
> indication on the health checks...
>
> This config sort of works:
>
>
> *server app2 ssltest.example.ca:443 ssl verify required /verifyhost
>
Further... the odd/broken behavior might be being caused related to no
sni indication on the health checks...
This config sort of works:
*server app2 ssltest.example.ca:443 ssl verify required /verifyhost
ssltest.example.ca/ sni ssl_fc_sni ca-file
/etc/ssl/certs/ca-certificates.crt check che
Ok finally got around to testing this out today; running into a bit of
an issue with the new syntax.
What I'm trying to achieve is:
frontend www-https
bind :::443 v4v6 ssl crt /etc/haproxy/certs/www.example.org.pem crt
/etc/haproxy/certs/
backend www-backend-https
server ssl 10.0.0
I'll see if I can give this a test. Thanks for adding it to master!
--
Kevin
On 2017-07-06 6:19 AM, Willy Tarreau wrote:
Hi again,
I finally merged it in master as commit 2ab8867, it will ease testing
(and a test file was provided).
Cheers,
Willy
Hi again,
I finally merged it in master as commit 2ab8867, it will ease testing
(and a test file was provided).
Cheers,
Willy
Hi Manu,
On Thu, Jul 06, 2017 at 11:10:41AM +0200, Emmanuel Hocdet wrote:
> SSL_SESSION_get0_hostname take a ssl_session not a ssl structure.
Ah crap! I did create the ssl_sess variable but forgot to change it in
the struct. It's likely that the address is the same here because the
code worked! T
Hi Willy
> Le 5 juil. 2017 à 18:38, Willy Tarreau a écrit :
>
> Hi guys,
>
> back to this old discussion.
>
> On Fri, May 12, 2017 at 04:10:20PM +0200, Willy Tarreau wrote:
>> On Tue, May 09, 2017 at 12:12:42AM +0200, Lukas Tribus wrote:
>>> Haproxy can verify the certificate of backend TLS s
Hi guys,
back to this old discussion.
On Fri, May 12, 2017 at 04:10:20PM +0200, Willy Tarreau wrote:
> On Tue, May 09, 2017 at 12:12:42AM +0200, Lukas Tribus wrote:
> > Haproxy can verify the certificate of backend TLS servers since day 1.
> >
> > The only thing missing is client SNI based backe
On Tue, May 09, 2017 at 12:12:42AM +0200, Lukas Tribus wrote:
> Haproxy can verify the certificate of backend TLS servers since day 1.
>
> The only thing missing is client SNI based backend certificate
> verification, which yes - since we can pass client SNI to the TLS server
> - we need to consid
So who do I bug to actually get this coded/patched? Not being familiar
with the code base myself ;)
--
Kevin McArthur
On 2017-05-08 3:12 PM, Lukas Tribus wrote:
Hello,
Am 08.05.2017 um 10:56 schrieb Daniel Schneller:
Just my 2c, I very much support Kevin’s argument.
Even though we are not
Hello,
Am 08.05.2017 um 10:56 schrieb Daniel Schneller:
> Just my 2c, I very much support Kevin’s argument.
> Even though we are not (yet) verifying backends — because currently we
> _are_ in a private LAN — we are planning to deploy parts of our
> application to public cloud infrastructure soon,
Just my 2c, I very much support Kevin’s argument.
Even though we are not (yet) verifying backends — because currently we _are_ in
a private LAN — we are planning to deploy parts of our application to public
cloud infrastructure soon, so it would be a quite important feature.
Regards,
Daniel
--
1. The Snowden leaks and the whole "SSL added and removed here" issue,
for example. TLS on internal networks is more important these days due
to local network implants and other security issues on LANs.
2. Our use case is actually DigitalOcean where there is "private
networking" but it is shar
On 6 May 2017 2:04 am, "Kevin McArthur" wrote:
When doing tls->haproxy->tls (bridged https) re-encryption with SNI, we
need to verify the backend certificate against the SNI value requested by
the client.
Something like server options:
server app1 app1.example.ca:443 ssl no-sslv3 sni ssl_fc_sni
When doing tls->haproxy->tls (bridged https) re-encryption with SNI, we
need to verify the backend certificate against the SNI value requested
by the client.
Something like server options:
server app1 app1.example.ca:443 ssl no-sslv3 sni ssl_fc_sni verify
required verifyhost ssl_fc_sni
Howe
57 matches
Mail list logo