Update on QUIC
Closed this issue · 39 comments
Just wanted to give an update on the situation with the QUIC implementation.
At this point I'm quite glad that I didn't move forward on the implementation that ... um... quickly.
Some history:
QUIC depends directly on TLS 1.3 as a core part of the protocol. Years ago BoringSSL defined and implemented a set of additional APIs that exposed the functionality runtimes need to correctly implement TLS 1.3 for QUIC. Engineers at Akamai and Microsoft ported those APIs -- again, years ago -- to OpenSSL and had a PR that sat there ready to go for years that the OpenSSL project refused to land. Because of the indecision, Akamai and Microsoft decided to lightly fork OpenSSL with the BoringSSL QUIC APIs which, because it was backwards compatible with OpenSSL and because they were able to keep it up to date with OpenSSL, we decided to adopt. So for a while now we have been shipping Node.js with this alternative OpenSSL+quic.
However, a while back the OpenSSL project decided, for reasons that are still completely mysterious to me, that they wanted to have their entirely own implementation of the full QUIC protocol. So instead of just landing the APIs that already existed and that folks were already using, they decided to come up with an entirely new implementation from scratch. Unfortunate, up to now this implementation has not exposed any of the APIs we would actually need to be able to implement QUIC ourselves.
What this decision by the OpenSSL OMC has done is forced Akamai and Microsoft to fully fork OpenSSL into a new project called quictls which is no longer tracking OpenSSL development. They will attempt to remain as API compatible as possible for most things but the QUIC stuff is completely separate. What's worse is that quictls is currently not able to commit to the kinds of Long Term Support guarantees that we need for Node.js.
This means that we are being forced off of quictls and will need to move back to the mainline OpenSSL.
Within the past few weeks, OpenSSL has added a handful of APIs to OpenSSL 3.5 that allow other implementations to make use of the TLS 1.3 implementation .... openssl/openssl#26683 ... The problem, of course, is that OpenSSL 3.5 has not yet been released and it is not actually clear if what APIs they have exposed will actually work with the ngtcp2 library that we use to handle most of the QUIC semantics. My next task will be to try to verify that ngtcp2 can use these new, different, as yet unreleased APIs.
This puts the entire QUIC-in-Node.js project at risk. If we cannot make these APIs work then I'm not quite sure where to go from here beyond adandoning all of the work that has already been done. I will be investigating further over the next few weeks and hopefully will be able to make something work but we shall see.
One additional downside of this approach taken by OpenSSL is that it will make it impossible to backport the QUIC implementation to any Node.js versions that does not have at least OpenSSL version 3.5.
Side note: I'd actually like us to consider the possibility of switching entirely to BoringSSL and away from OpenSSL. While BoringSSL does not carry the same Long Term Support guarantees that OpenSSL does, and has a much more constrained set of algorithms/options -- meaning it would absolutely be a breaking change -- the model they follow echoes that approach that v8 takes and we've been able to deal with that just fine.
/cc @nodejs/quic @nodejs/tsc @nodejs/net @nodejs/crypto
Next steps: My next step is to dig further into the new OpenSSL APIs to determine if they can be used together with ngtcp2. I will update here once I know more.
Update: It looks like OpenSSL 3.5 is not expected to be released until sometime in April, which means we're not likely to be able to make any real progress until at least then.
Update: It looks like OpenSSL 3.5 is not expected to be released until sometime in April, which means we're not likely to be able to make any real progress until at least then.
FWIW the roadmap from OpenSSL for 3.5:
- Alpha release date: March 11, 2025
- Beta release date: March 25, 2025
- Release date: April 8, 2025
So we'll hopefully get an alpha next week. I can look at adding an on-demand CI to test dynamically linking Node.js against the alpha/beta.
Can we expect OpenSSL 3.5 to land on Node.js 24?
- It's the next LTS.
- It is releasing on April 8, 2025, which is before Node.js v24.0.0 release on April 22, 2025.
Based on https://github.com/nodejs/collaborators/discussions/202 we will end up with OpenSSL 3.5 on 22.x as well as 24.x. This does not however mean it'll happen with the first 24.x release. It'll happen eventually
Ok, unfortunately it looks like the new quic-related APIs that openssl is insisting on are not going to work with the ngtcp2 dependency. The reason is fairly straightforward... the original APIs that Openssl refused to land are based on a pull-model, where ngtcp2 pulls the necessary stuff from openssl as needed while the new apis that openssl has landed are push based. This difference means that the basic abstraction api that ngtcp2 has implemented (and that works with numerous other TLS implementations) just won't work. The author of ngtcp2 has no plans to try to make it work. Thus far, openssl has chosen to implement a model that is just fundamentally incompatible with the way the other tls implementations work.
So what does all this mean? It means that QUIC in Node.js is likely dead at this point unless one of the following occur:
- We pivot away from using ngtcp2 and nghttp3 to using an as-yet-unspecified alternative implementation that is capable of using the new openssl APIs (this would mean rewriting a massive portion of the code I have ... again).
- Someone is somehow able to implement a wrapper around the new openssl apis that makes it work with ngtcp2
- Openssl has a change of heart and decides to provide useful APIs that the ecosystem can use.
- We're able to switch to Boringssl and drop openssl entirely.
At this point I'm not confident that any of these will happen. Therefore, I'm just about ready to call it quits and just abandon the effort entirely. I will be exploring a couple of other options over the next few days but unless anyone has any helpful concrete suggestions, if I'm not able to identify a path forward within the next few days I will be opening a PR that just removes anything relating to quic back from the repo and giving up the effort entirely.
I'm just a JS dev that really likes Node, so I know I'm not qualified to comment here. But, I will anyway. :)
It really seems like the best long-term solution at this point is to abandon OpenSSL in favor of another implementation. Even beyond the issues with QUIC there are also the regular vulnerabilities that pop up. I understand that OpenSSL is pretty deeply integrated with Node, so switching would be a huge task, but that's my $0.02.
I know you've poured a ton of work/time into getting QUIC into Node, and I wanted to say thank you for that effort.
I've been digging into some options over the past few days and will be having a call soon with the folks in openssl who are working on the quic stuff they do have. Hopefully that will bear some fruit that will allow us to move forward.
I've also been chatting a bit with the author of ngtcp2 and he thinks that there might be a workaround with the openssl APIs that involves quite a bit more bookkeeping complexity but still might be possible.
There's another library called picotls that ngtcp2 can work with that also layers on top of openssl that could be an option but it has no API stability or LTS guarantees so that would likely be a last resort kind of option.
Once I have the call with the openssl folks I'll come back and update here on possible next steps.
Even beyond the issues with QUIC there are also the regular vulnerabilities that pop up.
openssl has probably more eyes who find vulnerabilities than other less reviewed implementations.
A... Quic... Update here... ;-)
Happy days! There is work underway by the lead maintainer of ngtcp2 (@tatsuhiro-t) with assistance from a couple openssl folks to implement the necessary abstraction bits to get ngtcp2 working with openssl 3.5. This means that we're back on track to having quic in node.js but there's obviously going to be more of a delay as it is not clear when that work will be ready to go. I'm monitoring closely and will update as I know more.
ngtcp2/ngtcp2#1582 is merged into main.
Now, once Node.js is updated to OpenSSL 3.5 (which @richardlau and @targos are looking at I believe) I will be able to pick this up and continue this work. Woo!
Unfortunately all of this does mean that we will be unable to backport any of the QUIC stuff to any prior Node.js version that does not have OpenSSL 3.5... but I'll just be happy when the darn thing is done.
👍 on moving to BoringSSL.
One workaround for the lack of long term support is to always build with a bundled BoringSSL that is statically linked and has its symbols stripped from the public API. Distributions would need to rebuild Node.js whenever there is a BoringSSL vulnerability.
At this time we won't be moving to BoringSSL. I'm currently on hold waiting for Openssl 3.5 to be able to land. Once that is available I will be able to continue this work.
Thank you for the work and the explanation of why a deadlock in development occurred.
When I started my Node.js WebTransport plugin for http/3 as an intermediate solution, I thought I could abandon it after a year and switch to the native implementation.
I plan to eventually create a wrapper around the native node implementation (I have working software that I would need to reimplement otherwise, and a working node native http/2 implementation).
This would also mean that my tests can run against Node.js (including tests against browsers, quiche implementation), which may help find bugs (and I may also supply patches, at least for Firefox and Chromium, it happened like this).
Please tell me if and when this would be helpful for you.
(Only the obstacle I see is that the body is only a ArrayBuffer | ArrayBufferView | Blob, which would break many streaming applications and is currently incompatible, but the underlying DataQueue C++ class should also support a stream?)
We also have a currently in development application using QUIC (using a publicly forked version of @jasnell's previous implementation). We primarily use the streaming APIs, only occasionally have we ever responded with Buffer / ArrayBuffer's (usually for error responses).
If implementing a nodejs compatible stream is too much, perhaps a .write method to write but not end (respondTo without the end)? It would be nice to be able to stream to a QUIC stream without needing to write a C++ module.
Honestly after all the defects we fixed the previous implementation works pretty damn well (at-least the APIs we use).
In the meantime, I have looked at the source code. There you find TODOs of jasnell for a stream implementation, so I assume it is planned. (You pass a stream for the body. It is a bit interesting that it then would only use readablestreams)
Any update when this will be available?
Unfortunately, no. We're stalled waiting on Openssl 3.5 to be landed, which is taking a bit of time since openssl decided to change their build sufficiently that much of it needs to be updated. There are a few folks working on that actively and I will continue this work once they've been successful.
What is the reason for using a bundled OpenSSL instead of the version provided by the OS package manager?
Bundling a vendored-in openssl means that we are better able to respond to vulnerabilities, updates, etc independently of the OS package managers, which often end up lagging behind or use support cycles that are on very different schedules than Node.js. We do support distributions that want to use their versions of openssl, but the vendored model allows much greater control, much greater stability, and reliability at the cost of a higher maintenance burden.
Bundling a vendored-in openssl means that we are better able to respond to vulnerabilities, updates, etc independently of the OS package managers, which often end up lagging behind or use support cycles that are on very different schedules than Node.js. We do support distributions that want to use their versions of openssl, but the vendored model allows much greater control, much greater stability, and reliability at the cost of a higher maintenance burden.
Also I cannot stress enough how nice is the ability for distributions to choose between bundled and shared library.
I believe it's critical that Node.js still lacks support for QUIC and HTTP/3. Node.js is a framework designed for web communication, yet it does not support these well-established protocols—despite other languages having done so for quite some time.
While it’s possible to implement QUIC using C or Rust via N-API, those solutions come with their own challenges, especially when working within the Electron environment.
Given how widely Electron and Node.js are used together, it's also important that once QUIC support is added to Node.js, it is backported to earlier versions. This would allow Electron—which typically lags a few versions behind—to adopt it more easily.
I would consider this a high-priority task.
@bergmorten Would you like to sponsor the effort or contribute some work to that end?
Well, I certainly would love to see it land sooner than later 😁 ... One step at a time.
The update to OpenSSL 3.5 is being done in PR #58100
I'm still planning on working on this, but have been distracted by my imminent move from Red Hat to IBM.
FTR we are already testing every PR to Node.js against a shared library OpenSSL 3.5 so that configuration works. The remaining work is to update the bundled version of OpenSSL in deps/openssl -- that is taking a bit more time because we need to translate OpenSSL's configure/build into Node.js' gyp based build.
Now that I think a bit more about this, given:
we are already testing every PR to Node.js against a shared library OpenSSL 3.5 so that configuration works.
Does it mean that technically the work for QUIC can already be started independently of #58100 ?
Oh! I think I missed the fact that we were testing against shared 3.5. That might be enough to get me started again, tho I'm a bit reluctant to do so until it's for sure that we're not going to have a problem with the vendored in version -- I don't want to do a ton of work only to hit yet another unexpected roadblock.
As per comment in related PR #59249 (comment), the goal is to have QUIC ready to go in time for the 25.0.0 release in October 2025.
Should this issue be closed as there has been decision to implement QUIC on top of OpenSSL 3.5, and the work is in progress?
Yep, makes sense.
Hi everyone,
I’ve been experimenting with a Node.js implementation of QUIC as part of an independent project. It’s still a work in progress (not production-ready yet), but it already includes a self-contained TLS 1.3 implementation (no OpenSSL dependency), packet parsing, and stream management.
Here’s the repo if anyone is interested in following or providing feedback:
https://github.com/colocohen/quico
I thought it might be relevant to share here, since it shows that QUIC support in pure Node.js is feasible, and can evolve with community interest. Any thoughts or feedback are very welcome.
@colocohen I was not expecting TLS1.3 in ~2000 lines of JS!
Hey jasnell / trivikr, was QUIC released as part of the Nodejs 25 release?
Hi @Arka-98, QUIC is available with option --experimental-quic in Node.js 25.x
Example code for handshake can be viewed in https://github.com/nodejs/node/blob/main/test/parallel/test-quic-handshake.mjs
Some features are yet to be implemented. And it's going to take more time for QUIC to be tested by the community before it can get stable.
Node.js is volunteer driven project. Lead developer James and others are working on their free time.
If the support for QUIC in Node.js important for you, do help us get it to completion!
An easiest way to help is to use QUIC with option --experimental-quic in Node.js 25.x+ and either submit or upvote feature requests!
An example of a feature request from last week is to support for streaming posted at https://www.github.com/nodejs/node/issues/60234
You can also dive deep into the implementation, and post PRs yourself to add support!
For example, @martenrichter who submitted the above feature request to support streaming has opened a PR at https://www.github.com/nodejs/node/pull/60237
Other ways to contribute:
- Add unit tests where they're lacking. You can refer my conference talk for an example where I post a PR live from stage.
- Write documentation for folks who want to use QUIC in experimental mode.
sure thanks trivikr
How to test this without a proper http/3 server?
@khteh the committed code can host a server and function as a client. Its transport layer.
I'll be running the same test suite on it that we previously built to experiment with the previous QUIC implementation once clienthello and streams (PR https://www.github.com/nodejs/node/issues/60234) merge.
I've been looking into committing clienthello (inc dynamic key/certificate) support, havent figured out the specifics of doing it yet though. Seems not particularly beginner friendly so I might focus elsewhere for now.