Hi Sergey, On Thu, Jul 13, 2023 at 03:33:42PM +0400, Sergey Kandaurov wrote: > On Thu, Jul 06, 2023 at 12:06:17PM +0200, Willy Tarreau wrote: > > > > 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. > [..] > > > 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. > > > > Thanks for raising this topic. > > Every decision on a project is a trade-off (between technical, > business, community, and other spaces). As for us, open source users, > we give alternatives to compat layer (BoringSSL, QuicTLS, LibreSSL), > so we are not taking their options away but giving another convenient > option to them if the trade-offs are acceptable. As for Nginx Plus > product, this is a commercial product, and we have to be mindful on > support and maintenance cost both for us and for our customers. That > is what guided our decision (on trade-off side of things). We will > learn from the feedback from our commercial users if there is a need > for more than compat layer gives. 0-RTT support is on the roadmap.
Thanks for your feedback. We're currently thinking about possibly enabling it only via a global config option that explicitly states that it is a degraded mode. It seems that it would be the best tradeoff we could do for users who don't want/are not able to build their own alternative library, while making it clear to them that what they're using is not exactly QUIC but something looking like it. We do think that there are some valid use cases, for example users who want to progressively test it and be sure their whole infrastructure is compatible with UDP, those who want to observe how many of their visitors are compatible and honor alt-svc, or who want to test their application over QUIC (e.g. check how auxiliary services such as WebSocket are handed), etc. But we want to make sure they won't confuse this with a "normal" QUIC stack. We are interested as well in collecting feedback from our users. It's possible that some will report bugs affecting our stack thanks to this compatibility layer, just because it can enable more deployments. Of course we do continue to encourage and explain the normal way to use QUIC which consists in building one of the TLS libraries that is not OpenSSL (since they basically all support it now). BTW it's nice to know that you're foreseeing a possibility for 0-RTT support. This could definitely address some important limitations. Thanks, Willy
