Re: WolfSSL builds for use with HAProxy
On Fri, Feb 09, 2024 at 11:00:24PM +, Tristan wrote: > Hi Ilya, > > On 09/02/2024 20:31, Илья Шипицин wrote: > > I run QUIC Interop from time to time, WolfSSL shows the best > > compatibility compared to LibreSSL and aws-lc. > > it really looks like a winner today > > And in comparison to current QuicTLS? > > > I'm afraid it practice it works in a different way. > > First, you install WolfSSL to prod, next INSTALL/wiki got updated :) > > I appreciate the joke... :) Well, unfortunately they are a lot of unknows with wolfSSL, so we every new user could discover them :-) > > Either way, for now I'm waiting on OCSP support first (hi William, Rémi); > hopefully someone else figures out the best build flags by the time that's > dealt with. I'll add that to my list but that's not the biggest priority for now :) -- William Lallemand
Re: WolfSSL builds for use with HAProxy
On Thu, Feb 08, 2024 at 02:46:46PM +, 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
Re: WolfSSL builds for use with HAProxy
сб, 10 февр. 2024 г. в 00:00, Tristan : > Hi Ilya, > > On 09/02/2024 20:31, Илья Шипицин wrote: > > I run QUIC Interop from time to time, WolfSSL shows the best > > compatibility compared to LibreSSL and aws-lc. > > it really looks like a winner today > > And in comparison to current QuicTLS? > QuicTLS Run took 0:40:46.016826 +-++ | |haproxy | +-++ | quic-go | HDCLRC20MSRZ3BUAL2C1C2 | | | EV2 | | | L16 | +-++ +-+--+ | | haproxy| +-+--+ | quic-go | G: 8879 (± 46) kbps | | | C: 5504 (± 120) kbps | +-+--+ wolfSSL Run took 0:43:09.272822 +-+-+ | | haproxy | +-+-+ | quic-go | HDCLRC20MSR3BUAL2C2 | | | EV2 | | |ZL1C16 | +-+-+ +-+--+ | | haproxy| +-+--+ | quic-go | G: 8508 (± 152) kbps | | | C: 5262 (± 441) kbps | +-+--+ it is combination of quic-go client and haproxy. wolfSSL passes all tests except "TestCaseHandshakeLoss" and "TestCaseZeroRTT" I configure wolfSSL as "./configure --enable-haproxy --enable-quic", maybe there are some dedicated flags for 0-RTT, I didn't check yet > > > I'm afraid it practice it works in a different way. > > First, you install WolfSSL to prod, next INSTALL/wiki got updated :) > > I appreciate the joke... :) but more seriously I am not very > knowledgeable when it comes to low-level programming or the associated > tuning/performance-testing. > So even if I deployed it, my opinion on that topic is unlikely to be the > best (besides bug reports anyway). > > Either way, for now I'm waiting on OCSP support first (hi William, > Rémi); hopefully someone else figures out the best build flags by the > time that's dealt with. > > Tristan >
Re: WolfSSL builds for use with HAProxy
Hi Ilya, On 09/02/2024 20:31, Илья Шипицин wrote: I run QUIC Interop from time to time, WolfSSL shows the best compatibility compared to LibreSSL and aws-lc. it really looks like a winner today And in comparison to current QuicTLS? I'm afraid it practice it works in a different way. First, you install WolfSSL to prod, next INSTALL/wiki got updated :) I appreciate the joke... :) but more seriously I am not very knowledgeable when it comes to low-level programming or the associated tuning/performance-testing. So even if I deployed it, my opinion on that topic is unlikely to be the best (besides bug reports anyway). Either way, for now I'm waiting on OCSP support first (hi William, Rémi); hopefully someone else figures out the best build flags by the time that's dealt with. Tristan
Re: WolfSSL builds for use with HAProxy
чт, 8 февр. 2024 г. в 15:49, Tristan : > Hi all, > > 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 run QUIC Interop from time to time, WolfSSL shows the best compatibility compared to LibreSSL and aws-lc. it really looks like a winner today > > 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. > I'm afraid it practice it works in a different way. First, you install WolfSSL to prod, next INSTALL/wiki got updated :) > > 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? > > Thanks, > Tristan > >
WolfSSL builds for use with HAProxy
Hi all, 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. 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. 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? Thanks, Tristan
