On Thu, Feb 08, 2024 at 02:46:46PM +0000, Tristan wrote:
> Hi all,
> 

Hello,

> With the ever-increasing threat of one day needing to give up on OpenSSL
> 1.1.1 (whenever the next bad CVE is found on QuicTLS 1.1.1w, essentially) I
> was looking at alternatives a bit closer.
> 
> Based on the wiki,
> https://github.com/openssl/openssl/issues/20286#issuecomment-1527869072, and
> that it has support for other features I'm interested in (notably ECH),
> WolfSSL seems by far my best bet at the moment.
> 

I have personnally more hope with aws-lc, given the fact that this is a
fork of a stack we know, and they maintain a stable ABI. But we don't
even have the clienthello callback in it yet, we have to invest some
time on this library too. But WolfSSL could a good alternative for you,
but this is still experimental.

> However, given that almost everything is compile time and defaults focus on
> suitability for constrained embedded environments rather than best
> big-proxy-server oriented performance, does anyone have pointers on what
> flags are important/traps/etc?
> 
> Besides the getrandom thing, HAProxy's INSTALL/wiki only vaguely mention
> that such build-time tuning is required, so I'm hoping someone might have
> gone through that already.
> 

--enable-haproxy is suppose to enable every features we support. you
could be needing --enable-keylog-export for debugging with the keylog
file, but it actually does not support TLS1.3 so that would be useless
for QUIC. You also need --enable-quic.

The other useful flags are optimizations depending on your CPU, for
example --enable-aesni , --enable-intelasm .


> This one is a bit extra, but considering that aiming for bleeding edge with
> WolfSSL is not entirely compatible with how most distros work (ie even if it
> was packaged, it's likely going to be perpetually quite far behind), what
> does the future look like in that regard from the distros' side?
> 

5.6.6 is already in debian testing and will be in the next ubuntu LTS
release, the problem is that it won't be compatible with haproxy... We
are trying to make them enable the haproxy features in --enable-distro
but it seems like it's already too late. At least --enable-quic is now
enable by default.

https://github.com/wolfSSL/wolfssl/issues/6834

So basically we reached a deadlock which will last 2 years. Regarding
Redhat I don't think they are even packaging it.

But yes, wolfssl cycles are not really compatible with LTS distro, so it
would need a PPA which provides the updated lib with the right flags.

-- 
William Lallemand

Reply via email to