Hi, while everyone here is probably aware of the difficulties caused to various of our implementations by the OpenSSL team when they decided not to adopt the QUIC patch set, I don't know if many noticed this news a month ago: the NGINX crew found a very clever trick allowing to implement QUIC on top of a regular OpenSSL library without having to patch nor even rebuild it. This is particularly interesting for the vast majority of users who only want to rely on their operating system's OpenSSL library and do not want to maintain their own rebuild of an alternate library sur as QuicTLS or other ones.
My undestanding (which could be flawed since I'm very bad at TLS layers) of the way it works is that it provides callbacks to hijack the Hello messages so as to decode them and extract the required info, or inject the required info there, as it would be done over TCP for other use cases. It is apparently particularly tricky due to where the interception happens but it gets the job done. One identified limitation is that 0-RTT is not supported. The original NGINX code is here: https://github.com/nginx/nginx/blob/master/src/event/quic/ngx_event_quic_openssl_compat.c We didn't know if this trick was portable to other implementations or not, so Fred tried to do the same on HAProxy, and it just happened to work remarkably well in not that long a time, which tends to confirm it could be easily adopted by other implementations (e.g. maybe it could be an option for ngtcp2). For those curious about it, the port to HAProxy is there: https://github.com/haproxytech/quic-dev/commits/fle-quic-openssl-compat We also suspect (but have not tried) that it should theoretically work for clients as well (e.g. if it would work with ngtcp2 then maybe curl could support QUIC on top of out-of-the-box openssl; Daniel/Tatsuhiro you may be interested in having a look). However till now I refrained from merging this work due to a concern I first wanted to discuss privately with a few people, and now here on the WG. My main concern was that if two of the most commonly found internet facing server stacks start to drop certain QUIC features as not implementable due to the limitations of the underlying OpenSSL library, this could possibly constitute the beginning of an ossification of the protocol, where, maybe, some simple clients could think "no need to implement 0-RTT anyway, it's not supported in field". I tend to think it's not the case because large players who do not use these stacks will continue to set the standard, but I wanted to openly share this concern here before merging the patch set into HAProxy. On the other hand, given the current situation that users are facing in field nowadays, where it's basically impossible to get QUIC working without having to build and maintain an alternate TLS library themselves, I'm also inclined to think that anything that eases the protocol adoption, even with a limited feature set, will improve its exposure and the feedback we need to make it better over time. So right now my temptation would be to merge all of this in HAProxy 2.9 but I'm particularly interested in hearing about any form of objection or encouragements regarding this. Thanks! Willy
