Hi Lukas, coming back to this old thread.
On Wed, Jun 26, 2013 at 11:48:12AM +0200, Willy Tarreau wrote: > 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 :-) OK we discussed this with Emeric in the last few days and came up with a solution closer from yours than from mine. What made me accept to change my mind is to realize that many users don't see warnings at all. Probably that the new shitty service managers which replace init are responsible for this... So in practice : - verify now defaults to "required" when connecting to a server - verify without a CA file emits an error and quits explaining what is missing. - a global option "ssl-server-verify" can change the default from "required" to "none" for deployments where this mode is not desired at all (that's what we're facing when placing an appliance at a customers' in front of existing servers in practice, they trust their LAN and don't want to make things more complex for no perceived value). - a command-line option "-dV" is equivalent to "ssl-server-verify none" to ease testing of configurations during support or development. So as of now my development configs don't work anymore unless I force -dV. I think this is reasonable this way and am expecting some breakage reports in the upcoming days on the list :-) But the message is clear enough about the way to fix this, so it was better to do it before releasing 1.5. Best regards, Willy
