Hi Lukas,
On Wed, Jun 26, 2013 at 09:52:32AM +0200, Lukas Tribus wrote:
> Hi Willy,
>
> I sense we are not going to agree on this, but I'm posting my two cents
> here anyway.
you're welcome :-)
> > I think that the statement in the doc is clear enough about this.
>
> The statement in the doc is very clear and does not leave room for
> interpretation. In fact, it even warns about MITM.
>
> But I'm seeing this more from an operational perspective, considering that
> an administrator cannot possibly be aware of everything which is in those
> 12000 lines of config-documentation. In fact I think its very likely that
> in a project - a few months after the initial deployment - such specific
> implementation details will be forgotten, but configurations adjustments
> may still be necessary. Or the haproxy guy may be on vacation and someone
> else has to implement a new backend "on-the-fly", etc.
I get your point, but on any client when you check a certificate, you have
to configure a list of valid CAs to check it against. So someone who would
be surprized to see that haproxy does not validate a cert while he as not
configured any CA for sure needs to take some meds, or at least stop using
SSL at all.
> In the end, my opinion is that when reading the configuration there should
> be no chance that the user mistakenly assumes the configuration is
> "secure", while its not even though he is not fully aware of the
> documentation. We should not "fool" the user when it comes to such things.
>
>
> Considering all this, instead of changing the default, I would rather simply
> require the verify keyword when ssl is used on the backend and remove the
> default completely.
>
> So we:
> - force the user to configure the verify keyword (even if its set to none),
> so their are no doubts about the behavior when reviewing the configuration
> - otherwise abort at config parser level instructing the user what to do
I'm still thinking about it. I'm not completely satisfied with it but I like
the general idea. My concern is mainly about handling of the default-server
line in fact. Also, I wouldn't make it an error but just a warning, because
as for every warning, the config is valid, does what it describes, which may
or may not necessarily be what the user intends to do (eg: similar to block
rules set up after use_backend). Ideally I think we should probably change
the "verify" default to strict so that it does not become necessary anymore
when you already have to write the "cafile".
Just thinking loud as I'm writing, but we could probably have this :
- verify set to "strict" by default
- if no "cafile" is given, emit a warning saying that "cafile" is missing
and that verify has been set to the insecure "none" mode.
At least it should incite users to set up a cafile to make the warning
disappear.
> > Yes but most users of this will in fact just wantto recipher when connecting
> > to the local server haproxy was installed in front of because they don't
> > know
> > how to make it accept non-ssl connections. And that's a fairly common case
> > with certain products or commercial applications. For example some
> > applications
> > will automatically build "https://"; links only if the connection was
> > accepted
> > over SSL. Then in this case, SSL is used as HTTP, but provides additional
> > connectivity.
>
> This is true, of course. But at the same time I'm sure there are a lot of
> users deploying HAProxy in the cloud, where they barely know in what country
> the VM/instance is spawned, not to mention how many NSA/GCHQ listening
> stations their backend traffic passes :). Backend traffic isn't exclusively
> going through the company-owned Top-of-Rack switch anymore. Too many players
> are involved in cloud-based environments.
I get your point but I hate it when we make the life more complicated for
skilled users just because of a few junkies who don't care about anything
and that we want to prevent from shooting themselves in the foot.
The other issue I'm seeing on my side is that I don't know how we'll handle
this for appliance customers who see their configuration automatically
migrated when they upgrade. We don't want to add "verify none" on each
server line as it could have been set to "strict" on the default-servers
line, including in the last "defaults" section, which becomes a big tricky
to parse and process. Probably they'd have to live with the warning in fact.
Emeric will hate me, especially since he rarely reads the list and will
discover this on next major upgrade :-)
Best regards,
Willy
