The QUIC API OpenSSL will not provide (2021) | Hacker News Reader

The QUIC API OpenSSL will not provide (2021)

daniel.haxx.se

28 pointsrom1v10 comments

Note this is a blog post from 2021, which should be added to the title. The information included is out of date by several years now.

OpenSSL has done stuff with QUIC since then, a cursory search turned up this README in their main repo on using QUIC and OpenSSL: https://github.com/openssl/openssl/blob/master/README-QUIC.m...

While they have done stuff with QUIC, this more recent blog from Daniel [1] seems to indicate the situation is still not quite ideal.

[1]: https://daniel.haxx.se/blog/2024/06/10/http-3-in-curl-mid-20...

As an HTTP server author, this doesn't surprise me.

We've ceded HTTP specification development to the big guys, and in so doing have made it more or less impossible to implement without resources on their scale. Have you looked at RFC 9000 et al? They're monstrously big, far larger than most independent shops could ever hope to economically pull off. The only way to comprehensively implement something of that scale is to have Google level resources to throw entire teams of engineers and years of focus at it.

I've long said that any protocol worthy of being foundational should be reasonably implementable as a fourth-year term project. It doesn't have to be production ready or ergonomic or even generally useful, but if a group of fourth year CS students can't pull an end-to-end implementation together in a semester, the protocol is just too complex. It's not perfect, but it's as good of a yardstick as I've found.

HTTP/1 passes this test easily; you can make a working version of it in about ninety seconds right in your terminal. HTTP/2 looks intimidating at first glance, but it's so much better specified than HTTP/1 that it's almost easier to get to a reasonable implementation. HTTP/3 on the other hand is...... well, weeks (if not months) of work just to get a QUIC foundation working reasonably well enough that you could hope to start iterating on connections from a 'real' peer, and THEN you have to start on RFC 9114. Not to mention that the way it's structured you end up doing most of that work in the dark, hoping that you line everything up just so so that your first Hello World actually works. It's a way of working that is completely at odds with the hacker ethos that the best foundational protocols have in spades, and ends up looking and acting like what it is: a tool by the big guys, for the big guys. The rest of the internet need not apply.

Just recently apt listchanges informed me that "curl" (the binary) switched to gnuTLS to support HTTP3 (libcurl remained on openSSL for compatibility). So I assume this is still not fully resolved.

Ah, the QUIC drama. When everyone adopted quic before the protocol was even fully specified.

Yet here we are in 2025, with OpenSSL still lacking a QUIC server API and RFC9000 approaching its fourth birthday.

They pretty much told everyone that a proper integration for OpenSSL would take years. The server API seems to be in an early review state and slowly progressing.

https://github.com/openssl/openssl/tree/feature/quic-server

As the blog post mentions, the main question is not why a including a QUIC implementation in OpenSSL will take years (that’s reasonable), it’s why the only way to do QUIC using OpenSSL is to use their implementation of the whole thing. The way QUIC hooks into TLS is admittedly a little bit peculiar, but it’s in no way impossible to separate the layers. The OpenSSL devs just decided they don’t want to.

Now that is not really fair. For an RFC to be accepted as standard, it needs to have functioning implementations. The code and the specifications come hand-in-hand.

The same happened when TLS 1.3Bwasnarpundnthe corner. Several draft version with different implementations that browsers shipped before the RFC was finalized. OpenSSL wasn't as late as QUIC to implement TLS 1.3 though.

These are selective improvements, and where every millisecond counts, I don't think see anything negative about implementations want to get ahead of the game.

I think Caddy browser gained a significant market share because it supports HTTP/3 by default, while Apache (that uses OpenSSL) lags behind.

Reply on news.ycombinator.com