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. (Could be nullable? or
another setting like check-sni-disable added)
check-ssl-verify (optional). required/none. Affects only the check subsystem
validations. Defaults to required.
check-ssl-verifyhost (optional). Set a hostname to verify against. Defaults
to the value from the server hostname being connected to, or null if check
verify = none)
check-ssl-ca-file. (optional). Use a different bundle for ca certs for the
checks instead of the normal list, as this will likely be an internal ca.
For me it creates too many confusing options for stuff that mostly nobody
is interested in seeing different. Possibly that the check-ssl-sni could
be useful but then it would be useful. "verify" being set is enough to
say that you care about the server connections being verified and that
all protocol elements that are fed need to be checked ; that rules out
the need for "check-ssl-verify". "check-ssl-verifyhost" doesn't provide
any benefit as without SNI there is no reason for seeing a different name
being returned on the same connections. Regarding the CA file it's the same.
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.
verifyhost-sni-or-string (optional) default.example.ca. Use the SNI value or
if no sni value a provided default string. default string would be the
hostname from the server line.
That's exactly what "verifyhost" does in the latest patchset (except this
"hostname" from the server line, which is a bad idea in many cases as a
lot of people use plain IP addresses).
Ah my bad here. I was running off the patches from the mailing list and
not what you added to master. Rebuilding makes the new verifyhost
behavior work as above. The ML patchset doesn't do this which is where
the disconnect is.
This would make the following scenarios work;
--
An internal server is being used as a backend. There is no valid cert for
the internal.* variant of the domain. The server returns a valid cert for
app2.example.ca as the check system told the server to use app2.example.ca
SNI rather than the actual hostname being connected to. The check connection
is secure and SNI vhosts are too.
server app2 internal.app2.example.ca:443 ssl verify required
verifyhost-sni-or-string app2.example.ca sni ssl_fc_sni ca-file
/etc/ssl/certs/ca-certificates.crt check check-ssl check-ssl-sni
app2.example.ca
You can do the same (except sending the SNI with the check) using this
today :
server app2 internal.app2.example.ca:443 ssl verify required verifyhost
app2.example.ca sni ssl_fc_sni ca-file /etc/ssl/certs/ca-certificates.crt check
check-ssl
Being able to send the SNI would be nice... ;)
An internal server is being used as a backend, but doesn't have a valid tls
certificate for the server itself. In this case disable verify on checks but
maintain it for normal connections to the backend
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 check-ssl-verify
none
That's what you do without verifyhost today, without having to add
"check-ssl-verify none".
I was thinking more like a self-signed localhost cert that wouldn't
chain to a valid root and therefore fails the verify part, not one that
only mismatches the hostname but is otherwise valid.
An internal server is being used as a backend, but used an internal CA for
the internal server domains but not for normal client domains. In this case
provide a different ca for the check system.
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 check-ssl-ca-file
/path/to/local-ca.crt
I hardly see a reasonably valid use case for using a different CA for the
checks quite honnestly! Please keep in mind that all these possibilities
become very painful to configure for most users to cover the most common
cases (and by the way there wasn't any such request (not even a single
one) in the last 5 years). These "server" directives become quite long
and complex! I tend to prefer to adapt to real needs than provide features
complicating normal configs and whose benefits are hard to verify in field.
Need not be complex if the defaults are the same as not implementing
them. Just helps make some internal architectures easier to deploy
securely. That said, this doesn't block me as I'll just happily
verifyhost against a public cert as a default and 'trick' haproxy that
way even though its connecting to an internal server. So its not critical.
Regards,
Willy
