Update on QUIC

[jasnell]

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

[jasnell]

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.

[richardlau]

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.

[trivikr]

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.

[panva]

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