Hello Artur, On Wed, Feb 05, 2025 at 06:07:39PM +0100, Artur wrote: > Hello ! > > I'm testing aws-lc library with haproxy (3.1) and I was surprised to get a > start failure after migration from quictls to aws-lc : > > [ALERT] : config : parsing [/etc/haproxy/haproxy.cfg:19] : unknown keyword > 'ssl-dh-param-file' in 'global' section; did you mean > 'tune.ssl.default-dh-param' maybe ?
Hmmm bad, we need to improve this. We *know* that some keywords (very few actually) may depend on certain libs, and we'd need to make special cases for a few of them and emit a warning instead, such as: Warning: the ssl-dh-param-file file is not supported by aws-lc and will be ignored. If you don't use dh algos (you shouldn't), you can safely remove that line to get rid of this warning. > I removed 'ssl-dh-param-file' and haproxy started. However it made me wonder > if there is some other differences/limitations related to aws-lc. > I've already seen that some ciphers are not available in aws-lc. That's what I understood, yes. I don't know the exact extent of differences though they are very thin since aws-lc has ancestry from boringSSL which itself is derived from openssl. I'd be tempted to suggest that the differences between openssl versions and aws-lc should be in the same range as the difference between major openssl versions built with default settings (i.e. some algos are sometimes deprecated etc). Maybe William has other differences in mind. > So, I'm currently looking for a suggested (basic/secure) config for use with > aws-lc. Maybe some articles are available to explain haproxy and aws-lc > interactions from admin point of view ? I'd say that for now it's the closest working alternative to openssl we've seen to date and it's getting a growing importance in our tests and usages. That's the one I'm using by default when I build haproxy tens to hundreds of times a day during development for example. We've started to work on an article comparing the various libs but it takes an amazing amount of time so it's still not ready. But at this point I would say that I'm confident this lib is prod-ready, and that we'll write more about it soon. Regarding the visible differences, we definitely need to do a bit better and at least take care of a few keywords that make configs break. Thanks for this very useful feedback! Willy
