Hi Willy
On 2023-07-06 (Do.) 22:05, Willy Tarreau wrote:
Hi all,
as the subject says it, Fred managed to make QUIC mostly work on top of
a regular OpenSSL. Credit goes to the NGINX team who found a clever and
absolutely ugly way to abuse OpenSSL callbacks to intercept and inject
data from/to the TLS hello messages. It does have limitations, such as
0-RTT not being supported, and maybe other ones we're not aware of. I'm
hesitating in merging it because there are some non-negligible impacts
for the QUIC ecosystem itself in doing this, ranging from a possibly
lower performance or reliability that could disappoint some users of the
protocol, to discouraging the efforts to get a real alternative stack
working.
I've opened the discussion on the QUIC working group here to collect
various opinions and advices:
https://mailarchive.ietf.org/arch/browse/quic/?gbt=1&index=M9pkSGzTSHunNC1yeySaB3irCVo
Unsurprizingly, the perception for now is mostly aligned with my first
feelings, i.e. "OpenSSL will be happy and QUIC will be degraded, that's
a bad idea". But I also know that on the WG we exclusively speak between
implementors, who don't always have the users' perspective.
I would encourage those who really want to ease QUIC adoption to read
the thread above (possibly even share their opinion, that would be
welcome) so that we can come to a consensus regarding this (e.g. merge,
drop, merge conditioned at build time, or with an expert runtime option,
anything else, I don't know). I feel like it's a difficult stretch to
find the best approach. The "it's not possible at all with openssl,
period" excuse is no longer true, however "it's only a degraded approach"
remains true.
I wouldn't like end-users to just think "pwah, all that for this, I'm
not impressed" without realizing that they wouldn't be benefitting from
everything. But maybe it would be good enough for most of those who are
not going to rebuild QuicTLS or wolfSSL. I sincerely don't know and I
do welcome opinions.
Amazing work from the nginx team :-)
From my point of view is the way to go wolfSSL as the way on which
OpenSSL is does not looks very promising for the future, at least for
me. This implies that HAProxy will have different packages for the OS
and creates much more work for the nice packaging Persons :-(. I don't
know how big the challenge is to run HAProxy complete with wolfSSL, if
it's not already done but to have a package like "haproxy-openssl" and
"haproxy-quic" which implies wolfSSL would be a nice solution for the
HAProxy Users, imho. A nice Change would be if nginx and Apache HTTPd
also move to wolfSSL :-).
What's not clear to me is how the future of wolfSSL will be as the
Company behind the lib looks for now very open for Open Source Projects
but who knows the future.
Maybe another option could be gnutls as it added the QUIC API in 3.7.0
but I think that's even a higher challenge then to move from OpenSSL to
wolfSSL then to gnutls just because there is not even a single line of
code with gnutls.
https://lists.gnupg.org/pipermail/gnutls-help/2020-December/004670.html
...
** libgnutls: Added a new set of API to enable QUIC implementation
(#826, #849, #850).
...
ngtcp2 have examples with different TLS library, just fyi.
https://github.com/ngtcp2/ngtcp2/tree/main/examples
Another Question is, is the TLS/SSL Layer in HAProxy enough separated to
add another TLS implementation? I'm pretty sure that a lot of people
knows this but just for the archive let me share the way how curl handle
different TLS backends.
https://github.com/curl/curl/tree/master/lib/vtls
All in all from my point of view was OpenSSL a good library in the past
but for the future should a more modern and open (from Org and Mindset)
Library be used, Jm2c.
Cheers,
Willy
Regards
Alex
