Show HN: Nginx Image with HTTP/3 (QUIC), TLS1.3 with 0-RTT, Brotli |
Show HN: Nginx Image with HTTP/3 (QUIC), TLS1.3 with 0-RTT, Brotli |
There's some features you could easily add to yours in order to make it a better overall image.
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.
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.
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.
> 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?
https://www.musl-libc.org/faq.html
The logo is a mussel :)
Not sure what's the implementation status though.
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.
The link you posted is the right one, but it’s to the Internet-Draft. This is the step prior to becoming an RFC, where revisions are stored for everyone (including implementors) to use. So (for example) when you hear someone saying “I support TLS 1.3 Draft 8”, that means they support version 8 of the Internet-Draft.
Once this is finalized and becomes an RFC, you’ll see it updated here: https://datatracker.ietf.org/doc/draft-ietf-tls-esni/ (and I’m sure someone here will post about it!)
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.
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.
This pattern of concatenating commands to have a minimal image is a workaround from times when multi-stage builds were not available.
[0] https://github.com/moby/buildkit/blob/master/frontend/docker...
[1] https://geraldonit.com/2017/11/13/how-to-create-small-docker...
[2] https://docs.docker.com/engine/reference/commandline/image_b...
> I suggest reading about multi-stage builds. They basically squash layers at the end so it's a "have cake and eat it too" scenario.
That's completely different thing. Multi-stage builds are great for separating build environment from production environment, but if you need several layers for production environment, they won't be squashed. See here: https://github.com/docker/compose/issues/4235#issuecomment-3...
Workaround would be to move these files to one directory on host, COPY it in one command to /tmp (or even better, /dev/shm or other ramdisk) and then use script to distribute files where needed.