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