Hi guys,
On Thu, Nov 22, 2018 at 09:10:43PM +0100, Lukas Tribus wrote:
> > one bind for multiple IPs would reduce the flexibility of the config, you
> > could not longer set different Backends on different IPs that share one
> > certificate (directory) for example. There are clealy ways to reduce
> > the reload times by changing the configuration, however there is a
> > strong preference to keep the current configuration layout and solve
> > the problem in code, if there are no strong reasons against it.
>
> You are advocating for a new code path and along with an additional
> configuration knob. Feature bloat is a problem and if a use-case can
> be covered by modifying the configuration slightly, I'd personally opt
> for the latter. We should certainly look at all possibilities to cover
> the use-case. But I want to make it clear: I'm not the the SSL
> maintainer or the author, this is merely my personal opinion about
> this as a contributor.
In fact, after Aurelien's patches to update SSL certs over the CLI,
we've had a long meeting here with Emeric and William trying to spot
the various corner cases. We came up to the conclusion that there
definitely is some value in being able to merge same certs, but that
the name is not something sufficent. One simple example is when you
present different certs with different key sizes depending on the
listener (the bind line in fact). The common case is when you have
a partner connecting over a VPN using a crappy old client with some
algorithms or key size limitations and that TLS is almost useless on
this path, but you also want to present a strong certificate to the
net. It can also be the opposite, a partner demanding very strong
security for critical operations but you don't want to affect your
regular users. And the same distinction sometimes exists between
internal and public networks. So we figured that since in the end
it's about loading files and these files end up being the only
discriminant on the file system, which can be atomically updated, the
path to the cert files definitely had to be used as the key to
distinguish all these certs. We also found that it's important to
distinguish the cert types (RSA/DSA/ECDSA) as not all bind lines
necessarily want to share all of them, thus you may end up creating
different contexts for the same cert just based on the types used.
One valid use case for sharing certs is when some people use multiple
"bind" lines to bind to different processes/threads for improved
performance. I want to address these by moving the process and thread
masks from the bind_conf struct to the listener itself. The code
already supports having multiple listeners per bind_conf since it
supports port ranges and comma-delimited addresses. So it's not very
difficult but it requires quite some changes spread all over the code
that I don't feel enthousiast to do right now.
There are some other (ugly) use cases where people load certs from
directories, and instead of having one directory per hosted site,
they load all the certs in all frontends... It uses quite some RAM and
some startup time! We've seen one such case where haproxy was using
something like 3.5 GB on startup because a few tens of thousands of
certs present in a directory were loaded multiple times.
> As for flexibility with my 2 proposals you can access the destination
> IP in an ACL with the dst variable, which I believes gives you
> everything you need, including backend selection based on the
> connected IP, all with a single bind statement. I understand that was
> just an example, but with the ACL variables you should be able to do
> *a lot*.
In general I agree that it is one of the best solutions, which happens
to be very flexible and can even be updated without reloading, over the
CLI. Some even use map files for this, something roughly like this :
frontend public
bind :443 ...
use_backend %[dst,map(ip-to-back.map)]
And your ip-to-back.map file contains things like this :
10.0.0.1 back-cust1
10.0.0.2 back-cust2
...
With this said, I'd like that we manage to deduplicate certs at startup
after 1.9, at least in order to ease updates over the CLI. Boot time and
RAM usage savings will mostly be a byproduct of this. I don't want to
encourage bad usages when solutions exist but if new features come with
improvements to existing ones, that's fine :-)
Cheers,
Willy
