OpenSSL HTTP/3 QUIC Support Not Landing In OpenSSL Until 3.1

eva2000 · Feb 8, 2020

An OpenSSL pull request discussion at WIP: master QUIC support by tmshort · Pull Request #8797 · openssl/openssl reveals that OpenSSL folks have no plans to add HTTP/3 QUIC support into OpenSSL until at least OpenSSL 3.1 which would be due in 2021. This means most likely Nginx 1.17 mainline HTTP/3 QUIC development on their Nginx roadmap isn't going to progress anytime soon as Nginx only lands features supported in OpenSSL historically. So that means only current Nginx implementation of HTTP/3 QUIC out there we can use right now or test with at least is Cloudflare's Quiche BoringSSL HTTP/3 QUIC Nginx patches I started testing for Centmin Mod Nginx at https://community.centminmod.com/threads/centmin-mod-nginx-with-cloudflare-http-3-nginx-patch.18482/. However, such Quiche + BoringSSL library doesn't support OCSP stapling for better HTTPS performance like OpenSSL does out of the box. This means for sites to get HTTP/3 QUIC support right now, best to use Cloudflare proxy and Cloudflare SSL in front of your Centmin Mod Nginx sites.

OpenSSL folks posted a blog in November 2019 about currently state of OpenSSL 3.0 development which is the next major OpenSSL version after the current OpenSSL 1.1.1 (which Centmin Mod Nginx uses by default).

Regarding OpenSSL 3.0

Our original timeline had us aiming to be code complete by the end of this year (2019), after which we would do a series of beta releases in parallel with the FIPS lab doing its work. The final release of 3.0 was expected in early Q2 2020 with the actual validation of the FIPS module occurring sometime after that.

In spite of the extensive progress made there is still much left to do. It has become clear that we will not be able to achieve those original timeline aspirations. We are now not expecting code completion to occur until the end of Q2 2020 with a final release in early Q4 2020.
Click to expand...

From OpenSSL pull request latest comment at WIP: master QUIC support by tmshort · Pull Request #8797 · openssl/openssl

The OMC discussion was a consensus view that this is outside the scope of the 3.0 release - it is not on our road map - and there are a number of items we need to address that require attention to be applied to this which would pull resources away from the 3.0 work.

No formal vote was called for (any OMC member can call for a vote but none did) given the consensus.

The continuing work here by @tmshort is both useful and valuable to the openssl community and keeping this PR up to date through the 3.0 code changes is appreciated.

The hold remains - most likely until the 3.0 work is completed and we can plan the next release after that and have the time to further discuss our QUIC approach.
Click to expand...

WIP: master QUIC support by tmshort · Pull Request #8797 · openssl/openssl

OpenSSL won't land new features on 1.1.1, and doesn't plan a 1.2, so no 1.1.1 ABI compatible version of OpenSSL with HTTP3/QUICS support will ever be released (*).

Correct

OpenSSL won't land new features on 3.0.0 so even when HTTP3/QUICS support lands, its earliest possible release will be in version 3.1.

There is no blanket ban on features. But we have decided against adding support for this feature. So, yes, the earliest possible release for HTTP3/QUIC support will be in version 3.1 (or whatever comes after 3.0)

Is it known whether either of 3.0.x or 3.1.x be LTS, or is it too early still?

There has been no decision on this. My best guess is that 3.0 will not be LTS. Beyond that I cannot say.
Click to expand...

curl's main developer Daniel Stenberg is for adding HTTP/3 QUIC support to OpenSSL sooner and his comments WIP: master QUIC support by tmshort · Pull Request #8797 · openssl/openssl

I realize running the project is hard work and this is of course a decision for the project to make.

Lots of prominent developers waiting for this for entire ecosystems is not a reason enough to actually think this is an important step for OpenSSL? If so, will a few mails to the users list really going to change anything?

The code is already mostly written (thanks to tireless work by @tmshort and others) and I'm sure there are also a bunch of people here and around, who would love to help polish and make sure that the code is working and is good going forward.

Why not for example merge the code as "experimental" to start with and perhaps put it behind a config option, so at least we get wider testing and it won't have to be externally maintained for yet another year but not with a promised behavior or stability already from the start? That could give it time and a chance to evolve and stabilize a bit before it would become part of the real and public API and ABI.

A straight out not until 2021 (which is what it sounds like) is really counter-productive and frankly, a little hostile and unfriendly.
Click to expand...

eva2000 · Feb 8, 2020

For folks wanting to know more about HTTP/3 Daniel Stenberg (main curl developer) gave a talk at FOSDEM 2020 in Brussels below

Xon · Feb 8, 2020

A straight out not until 2021 (which is what it sounds like) is really counter-productive and frankly, a little hostile and unfriendly.
Click to expand...

To be honest; this has been OpenSSL for the longest time for any contributions from the wider community

eva2000 · Feb 8, 2020

Xon said: ↑

To be honest; this has been OpenSSL for the longest time for any contributions from the wider community
Click to expand...

Yeah it was the same when they were developing OpenSSL 1.1.1 and TLSv1.3 IIRC. I sort of understand being a developer of my own open source Centmin Mod project though One thing I am amazed to observe with popular open source projects is how they deal with the issues of having too many cooks in the kitchen

Though I am not at that stage where I get alot of code level/feature contributions yet. But probably something to juggle further down the road - if I am lucky enough

buik · Feb 9, 2020

eva2000 said: ↑

Yeah it was the same when they were developing OpenSSL 1.1.1 and TLSv1.3 IIRC.
Click to expand...

Xon said: ↑

To be honest; this has been OpenSSL for the longest time for any contributions from the wider community
Click to expand...

One of the real few drawbacks of open source feature project management. Various companies make employees available (in working hours).

Because each company has its own interest and not always a common interest.
you'll quickly get a mess. (conflict of interest.)

eva2000 · Feb 10, 2020

buik said: ↑

Because each company has its own interest and not always a common interest.
you'll quickly get a mess. (conflict of interest.)
Click to expand...

Ah overlooked that factor too. Though I can't see any company not wanting HTTP/3 QUIC support.

buik · Feb 10, 2020

eva2000 said: ↑

Though I can't see any company not wanting HTTP/3 QUIC support.
Click to expand...

Simple. The priority is with FIPS at this version 3 release.
OpenSSL is sponsored by large American company's like. Akamai Technologies (making developers available)
et al.
As FIPS is a U.S. government computer security standard.

FIPS gets priority.
Because it's a pretty thingy in the US.

It looks like there is just no more room for HTTP / 3, to get the job done for release 3.0.

Daniel Stenberg is from Europe, FIPS has 0 weight in Europe so it makes sense that he has other priorities.

Xon · Feb 11, 2020

eva2000 said: ↑

Yeah it was the same when they were developing OpenSSL 1.1.1 and TLSv1.3 IIRC. I sort of understand being a developer of my own open source Centmin Mod project though One thing I am amazed to observe with popular open source projects is how they deal with the issues of having too many cooks in the kitchen
Click to expand...

From memory; a large chunk of the OpenSSL's core development team are employees of an OpenSSL FIPS consulting company.

FIPS is basically a security standard which chooses really fucking horrible defaults; but is the one certified for US government contracting.

eva2000 · Feb 12, 2020

Xon said: ↑

From memory; a large chunk of the OpenSSL's core development team are employees of an OpenSSL FIPS consulting company.

FIPS is basically a security standard which chooses really fucking horrible defaults; but is the one certified for US government contracting.
Click to expand...

Yeah I guess the fact is priorities and agendas will dictate when and what is added eventually.

2021 isn't that long away though so who knows

buik · Feb 13, 2020

eva2000 said: ↑

Yeah I guess the fact is priorities and agendas will dictate when and what is added eventually.

2021 isn't that long away though so who knows
Click to expand...

We can see it as a bit positive because HTTP/3 is not yet a definitive standard.
Until then it does not matter what OpenSSL does and even does not matter what Nginx does.

Given the history with other standards (for example TLS 1.3) it can take a while before HTTP/3 is final as IETF standard and later before it is available in Nginx, OpenSSL, even in the browser, and later again before it is switched on by default in the browser.
I suspect it won't even matter much in time before all links in the chain are ready.

Log in / Register

Forums

Learn about Centmin Mod LEMP Stack today

OpenSSL HTTP/3 QUIC Support Not Landing In OpenSSL Until 3.1

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

Xon Active Member

eva2000 Administrator Staff Member

buik “The best traveler is one without a camera.”

eva2000 Administrator Staff Member

buik “The best traveler is one without a camera.”

Xon Active Member

eva2000 Administrator Staff Member

buik “The best traveler is one without a camera.”

.

Log in / Register

Useful Searches

Learn about Centmin Mod LEMP Stack today

OpenSSL HTTP/3 QUIC Support Not Landing In OpenSSL Until 3.1

eva2000 Administrator Staff Member

eva2000 Administrator Staff Member

Xon Active Member

eva2000 Administrator Staff Member

buik “The best traveler is one without a camera.”

eva2000 Administrator Staff Member

buik “The best traveler is one without a camera.”

Xon Active Member

eva2000 Administrator Staff Member

buik “The best traveler is one without a camera.”

.