Nginx Test Roadmap for QUIC and HTTP/3 Support in NGINX

As of September 2021, the HTTP/3 protocol is still officially an Internet Draft, but is already supported by 73% of running web browsers and,
according to W3Techs, 21% of the top 10 million websites. (1)

So... It's about time to start testing Nginx with HTTP/3.
To be prepared ready when HTTP/3 becomes an internet standard.
There are several options for getting Nginx to HTTP/3:

• Nginx-quic with BoringSSL as primary choice by the Nginx team, written in the official Nginx quic readme. (2)
• Nginx with Cloudflare's Nginx 1.16 patch and Cloudflare's Quiche. (3) And if needed, the patch is upgraded to the latest Nginx (as of today version 1.21.3) by our valued colleague Karl Chen (4)
• Nginx-quic with Quictls OpenSSL 1.1.1. The official Nginx quic code with OpenSSL 1.1.1 merged with Quic. Quic added by the Quictls team from Akamai and Microsoft. (5)
• Nginx-quic with Quictls OpenSSL 3.0.0. The official Nginx quic code with OpenSSL 3.0.0 merged with Quic. Quic added by the Quictls team from Akamai and Microsoft. (5)

After I conducted the first tentative test.
I come to the following preliminary conclusion.

---

1. Nginx-quic with BoringSSL misses several Nginx features because Nginx is compiled with BoringSSL.
I refer to the fact that the Nginx Multiple SSL Certificates feature is not supported (10).

Also, Nginx OCSP stapling does not work (11).
Neither of these two features are working because BoringSSL simply does not support it.

2. More or less the same as for point 1. Misses several features because Nginx is compiled with Cloudflare's Quiche.
And Cloudflare's Quiche depends on BoringSSL (6). If Nginx 1.16 is not desirable. You should have to look out for an alternative patch (4).

Quiche powers Cloudflare edge network's HTTP/3 support for example.
Because Cloudflare bases multiple services on Quiche.
It make sense that Cloudflare uses Quice with Nginx as well.

But if we as Centmin users, use Quiche, its only for Nginx.
As Cloudflare's Quiche is included as extra software package.
It provides us additional debugging. In case of bugs and errors.

3. Nginx-quic with Quictls OpenSSL
Nginx supports HTTP/3 (up to draft 34 (7)) and will obviously support HTTP/3 final when it is ready as official internet standard.
This code is already part of the Nginx core. No aditional software or code is required.
Because it is added to the official Nginx code. It is also thoroughly tested as a whole.

And as it is compiled with Quictls OpenSSL. It supports functions such as: Nginx Multiple SSL Certificates and Nginx OCSP stapling.
Quictls OpenSSL is no more and no less than OpenSSL stable with QUIC ported from the initial BoringSSL Quic (8).

Given the above, it currently seems like 3 is the best option to test HTTP/3 with Nginx.
Because there's going to be no additional software, no additional patches needed.

Should you choose Cloudflare's Quiche when HTTP/3 is final.
The official Nginx HTTP/3 code will not be used.

Because Quiche takes care of HTTP/3.
You still need the patch Nginx to faviour Quiche for Nginx own HTTP/3 code.

Finally it is strongly discouraged to use BoringSSL in a project.
In any way because of of the API or ABI instability.

'Although BoringSSL is an open source project, it is not intended for general use, as OpenSSL is.
We don't recommend that third parties depend upon it. Doing so is likely to be frustrating because there are no guarantees of API or ABI stability.' (9)

(1) https://en.wikipedia.org/wiki/HTTP/3
(2) https://quic.nginx.org/readme.html
(3) https://github.com/cloudflare/quiche/tree/master/extras/nginx
(4) https://github.com/kn007/patch
(5) https://github.com/quictls/openssl
(6) https://github.com/cloudflare/quiche/tree/master/deps
(7) https://www.nginx.com/blog/our-roadmap-quic-http-3-support-nginx/
(8) https://github.com/openssl/openssl/pull/8797
(9) https://boringssl.googlesource.com/boringssl/
(10) https://github.com/apache/trafficserver/pull/8014
(11) https://community.centminmod.com/threads/nginx-no-longer-needed-workaround-for-boringssl.8427/

 

I don't use any external Nginx patch nor HTTP/3 anymore as it does not matter for private sites. As written years before, i can't get sites faster then 0,2/0,3 sec.
With or without Nginx patches and HTTP/3 or no HTTP/3.

Of course it can be made faster, but then you have to make concessions on the end user experience which you should not want.

The problem continues to be the end user's connection. Often mobile.

Companies like Cloudflare and Akamai host millions of sites.
It is logical that every 0.1 second counts there.

Anyway to everyone.
Don't be fooled by Cloudflare's blissful blogs.
People are afraid of missing the boat.
But there is not so much to miss if you only own a few sites.

It is better to focus on new content than constantly optimizing a site in the margins. Google etc. ranks more on content than speed with small websites.

 

I would like to add a new option to the roadmap:

4. Nginx-quic with BabaSSL
Same as option 3. To the new point of:

It is compiled with BabaSSL from the Alipay team (1) forked from OpenSSL.
It supports functions such as: Nginx Multiple SSL Certificates and Nginx OCSP stapling.

BabaSSL is in fact OpenSSL stable with QUIC ported from BoringSSL.
BabaSSL also has some extra features relative to OpenSSL, but they are not relevant for Nginx, Quic HTTP/3 and non Asian country based use.

Compared to Quictls OpenSSL, BabaSSL differs in that it synced the latest code from BoringSSL.

0-RTT - Quic HTTP/3 does work on Nginx-quic with BabaSSL but it does not work on Nginx-quic with Quictls OpenSSL.

Looking at the code; The Nginx based configuration can find Quic support on Quictls OpenSSL but cannot find the needed 0-RTT code. The Quictls OpenSSL 0-RTT implementation is slightly different than that of BoringSSL. As a result, the feature won't be compiled and does not function as of written today.

Too bad Cloudflare doesn't make its BoringSSL fork open source with support for Multiple SSL Certificates and OCSP stapling. Competition and annoying support questions from newbies ruin this: 'Cloudflare locked as spam and limited conversation to collaborators'.

It's been a while. But it looks like quiche will one day support OpenSSL.
The problem remains that you have an extra software package in the name of: quiche. Very logical for Cloudflare because several services use quiche.

Less logical for Nginx only users.
As another software package is added, you have to debug extra in case of problems.

For the simple user, Nginx-quic remains the easiest. With BabaSSL if 0-RTT is needed. Let's hope OpenSSL officially adds Quic soon. That saves a lot of hassle.

(1) https://github.com/BabaSSL/BabaSSL
(2) https://www.babassl.com/

 

Well now that the umpteenth OpenSSL fork presents itself. It seems to me quite clear that various members and organizations do not agree with the course OpenSSL is heading.

 

Damn, OpenSSL looks almost like a political party.
Defragmentation is a big problem and is getting bigger and bigger within open source land. Why keep reinventing the wheel again and again?

As Rich Salz rightly points out and I've posted here on the forum just in the first post. OpenSSL + Quic (3) is just already ready to be used right away.

Looks like OpenSSL wants to develop its own QUIC stack (1).
Which is labeled by some expert as: 'What a colossal mistake'.

There is no chance of ignoring Quic experts (2) and as OpenSSL team, just keep working for years on something that is superfluous.

Just like the last 3 years with the development of OpenSSL v3.
As it was all in on FIPS which is a US only feature.
The world is bigger than the US. Even then, Quic was already simply ignored.

 

It would also be nice if someone fixes dual cert and OSCP stapling in BoringSSL.
Then you also have a seriously nice alternative.

The other options OpenSSL with Quic and BabaSSL are both OpenSSL with Quic copied from BoringSSL. The only difference is that BabaSSL uses newer code and has added some Chinese specific crypto in addition.

Curious how much work it is to fork BoringSSL with restoring OSCP stapling and dual cert. Which have been removed at an earlier stage by BoringSSL developers.

Cloudflare already has done this with BoringSSL, for example, but this project is not open source.