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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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 >

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

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,

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

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

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

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

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

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

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

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

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

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: Passing SNI value ( ssl_fc_sni ) to backend's verifyhost.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 >

Re: Passing SNI value ( ssl_fc_sni ) to backend's 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

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

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

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

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

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

Hi again, I finally merged it in master as commit 2ab8867, it will ease testing (and a test file was provided). Cheers, Willy

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

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!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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