Hi Willy, I sense we are not going to agree on this, but I'm posting my two cents here anyway.
> 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. 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 > 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. > Since "verify" would not work without a "cafile" setting, it would be quite > annoying. Yes, we would annoy the user. But I think the approach with making the verify keyword a required configuration statement on ssl-enabled backends is something we can put the user up with. We can abort with a very clear error message, like: Backend server with ssl keyworkd, but missing verify [none|required] statement. The user already sees this at config check time and I believe the frustration and the time to configure "verify none" after such a change would be limited and acceptable, considering that the alternative is a false suggestion of security. Regards, Lukas
