currently, it is client support for QUIC openssl/CHANGES.md at master · openssl/openssl · GitHub <https://github.com/openssl/openssl/blob/master/CHANGES.md>
пт, 7 июл. 2023 г. в 10:58, Aleksandar Lazic <[email protected]>: > Hi. > > Just a addendum below to my last mail. > > On 2023-07-07 (Fr.) 00:33, Aleksandar Lazic wrote: > > 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. > > Interesting point, at least for me, it looks like that OpenSSL starts to > implement quic, is there any official info from OpenSSL about this part > in this year? Is there also a statement about the performance issue with > 3.x? > > https://github.com/openssl/openssl/tree/master/ssl/quic > > >> Cheers, > >> Willy > > > > Regards > > Alex > > > >
