
Show HN: Nginx Image with HTTP/3 (QUIC), TLS1.3 with 0-RTT, Brotli - ranadeep
https://github.com/RanadeepPolavarapu/docker-nginx-http3
======
ricardbejarano
You may find my NGINX image[1] interesting.

There's some features you could easily add to yours in order to make it a
better overall image.

[1]
[https://github.com/ricardbejarano/nginx](https://github.com/ricardbejarano/nginx)

~~~
darkwater
The ARG approach to everything is really good IMO, it let you customize the
final image without having to change the Dockerfile. For example, in the OP
Dockerfile, the GPG key at very least should go in an ARG.

------
mnutt
I'm just curious, is there a reason not to use a multi-stage docker build
here? There are a ton of build steps, and it seems pretty tedious to have to
start from scratch every time while developing the image without any layer
caching.

~~~
ranadeep
Hi, my main task this weekend was to get it fully working. I will break down
the steps over this week to utilize cache layers. I will try to get it done
hopefully this week or by the weekend depending on work. Thanks a lot for your
feedback.

~~~
techntoke
Might I suggest you use Skaffold for this task, which can work with regular
Docker as well.

------
djsumdog
I haven't been following the TLS1.3 development. What is the current state of
SNI encryption? Is it possible to encrypt the name of the host you're trying
to connect to?

~~~
viraptor
That's eSNI and I believe it's part of 1.3:
[https://tools.ietf.org/html/draft-ietf-tls-
esni-04](https://tools.ietf.org/html/draft-ietf-tls-esni-04)

Not sure what's the implementation status though.

~~~
tialaramex
No, it isn't part of TLS 1.3

At the point where the last drafts of TLS 1.3 were shaping up, Eric
(Rescorla)'s initial ideas for how to achieve eSNI had failed and the extant
draft was only a problem statement. It basically said: Here is what eSNI needs
to achieve in our opinion, we don't know how to do that

Between that point and when TLS 1.3 was published, several people brainstormed
a proof of concept for how to actually make it work, which so far led to the
draft you've linked.

The eSNI draft is defined as an extension to TLS 1.3 but - since the whole
point is to deny snoopers information about who we're talking to - if we have
to "fall back" to not doing eSNI because the server isn't compatible then we
lost.

Cloudflare and Firefox devs cooperate to implement drafts of eSNI, so if you
have a recent Firefox and a site which has opted into Cloudflare's trial of
this feature, then it works for you, but the drafts definitely will change
further and you should not go building anything based on this draft that you
aren't able to support updating to future drafts or abandon altogether weeks
or months from now.

~~~
Santosh83
> Cloudflare and Firefox devs cooperate to implement drafts of eSNI, so if you
> have a recent Firefox and a site which has opted into Cloudflare's trial of
> this feature, then it works for you, ...

Well, at least not yet with the latest release version of Firefox (v69).
Tested with Cloudflare's own page for testing eSNI browser support (and TLS
1.3, DNSSEC & DoH). Firefox supports the other three but not eSNI, according
to that page. Even the Dev channel (v71) has no support.

[https://www.cloudflare.com/ssl/encrypted-
sni/](https://www.cloudflare.com/ssl/encrypted-sni/)

~~~
pritambaral
It's not enabled by default, and not exposed under browser preferences. It's
available in about:config under network.security.esni.enabled.

------
cafxx
I would suggest highlighting the experimental nature of the repo, especially
if someone reaches it without going through HN. I've read the catchy "All
built on the bleeding edge. Built on the edge, for the edge." but IMO it
doesn't really sound like a warning that this may not be suitable for serious
production use.

------
zegvold
I did exactly this 3 days ago, forked from fholzer/docker-nginx-brotli our
work looks very much the same

See [https://github.com/githubcdr/docker-nginx-
brotli](https://github.com/githubcdr/docker-nginx-brotli)

------
LeonM
I've played around with the nginx cloudflare patches and quiche, and it all
seems to work just fine in my lab setup.

I don't like having to apply third party patches to any mission critical
software such as nginx. So I'll wait until nginx releases official support for
linking the quiche library, like they did with brotli.

------
anfilt
I think 0-RTT is just bad idea security wise.

~~~
tialaramex
Good news, any participants under your control can (and so should) refuse to
do 0RTT. Clients can choose never to send early data and servers can choose to
always reject it, everything still works.

At the API layer reject any libraries or tools that try to foist this on you,
many today either don't do 0RTT or correctly offer it as a separate API call
for those willing to pay a price in terms of Replay resistance.

~~~
anfilt
That's even more concerning that there are libraries that hide such a thing.
There is gonna be instances that bites someone hard where said replay is not
idempotent.

------
vasilia
How about 0-RTT replay attack protection?

~~~
regecks
Well, "ssl_early_data" is opt-in. If you enable it on a virtualhost, then you
also need to look at the "Early-Data" request header in your backend and make
a decision there. e.g. process GET requests, otherwise send HTTP 425 Too
Early.

It does seem a bit unsafe. An administrator might opt-in because they copy-
pasted it from a tutorial, and not understand or pay attention to the second
part.

~~~
vasilia
I think it will be better to fully disable early data for people without full
control of DC's network equipment. I don't know why Cloudflare made a decision
about using headers and Too Early response. They have full control of their
POPs. It will be better to measure RTT and use UDP based KV storage with
tickets only for clients with high RTT. So for clients with RTT higher then
access to KV storage it will be better to issue tickets, for other clients it
will be better to drop early data and use full handshake. Currently, I'm
working on a project with the same idea.

~~~
tialaramex
> It will be better to measure RTT

To measure RTT you need to perform a round trip. Hence the name. But the
_whole point_ of this feature is to avoid incurring the cost of an extra round
trip if possible.

~~~
vasilia
There is no need to send extra data to measure RTT. On the TCP handshake
SYN/ACK you already know RTT. Linux kernel provides this info in tcp_info data
structure.

------
jwr
This is great, and I'll be using it for development! However, I've been
looking for something a bit more predictable, and yet still modern, for
production use. I do not know why Brotli support isn't included in every nginx
image at this point.

------
fulafel
From WP I get the impression that the work-in-progress now called HTTP/3 was
not necessarily designed supposed to supplant HTTP/2:

> On 28 October 2018 in a mailing list discussion, Mark Nottingham, Chair of
> the IETF HTTP and QUIC Working Groups, made the official request to rename
> HTTP-over-QUIC as HTTP/3 to "clearly identify it as another binding of HTTP
> semantics to the wire protocol ... so people understand its separation from
> QUIC"

Any opinions on how things are likely to play out?

~~~
sseth
I believe this is the separation of the transport layer protocol (QUIC) from
the application layer protocol (HTTP/3). QUIC can be seen as a replacement for
TCP. HTTP over QUIC then becomes HTTP/3 - with improvements in latency and
head-of-line blocking over HTTP/2\. So in that sense it will supplant HTTP/2
as QUIC gets adopted more widely.

------
The_rationalist
Are there any benchmarcks of http3? I would like to see how it compare vs
http2 h2 + tcp fast open

------
w-ll
OT: musl is pronounced like 'muscle' or do you spell it out 'm-u-s-l'

~~~
lbotos
>It’s pronounced the same as the English words “mussel” or “muscle”. musl is
small like one but powerful like the other.

[https://www.musl-libc.org/faq.html](https://www.musl-libc.org/faq.html)

The logo is a mussel :)

------
SomeOldThrow
For non technical users why ia this interesting?

~~~
proverbialbunny
It's not. But if you work on libraries that transfer http data around, this
could be used to help test http/3 support.

------
sdan
Looks I don't need Cloudflare anymore XD.

~~~
xmichael999
Yes, it's "almost" comical. The advantage of having a CDN with a pop in every
city, vs. just having 3 or 4 well placed POP's around the world will be
marginal once HTTP3 is broadly supported.

~~~
viraptor
I honestly can't tell if this is a serious take or sarcasm. I hope the
latter...

