For non technical users why ia this interesting?
It's not. But if you work on libraries that transfer http data around, this could be used to help test http/3 support.
Show HN: Nginx Image with HTTP/3 (QUIC), TLS1.3 with 0-RTT, Brotli
21–30 of 69 posts
Re: Show HN: Nginx Image with HTTP/3 (QUIC), TLS1.3 with 0-RTT, Brotli
#22How about 0-RTT replay attack protection?
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.
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.
Re: Show HN: Nginx Image with HTTP/3 (QUIC), TLS1.3 with 0-RTT, Brotli
#23Earlier quoted context omitted.
Because no one is suggesting you use this to "handle all your traffic" anywhere.
Neither is the contrary suggested. I wouldn't point out something marked as experimental/not for prod use.
Do you really require someone to point this out before running in production?
If anyone doesn't know not to do that, it's on them, not OP.
Re: Show HN: Nginx Image with HTTP/3 (QUIC), TLS1.3 with 0-RTT, Brotli
#24I 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?
That's eSNI and I believe it's part of 1.3: https://tools.ietf.org/html/draft-ietf-tls-esni-04 Not sure what's the implementation status though.
Unfortunately, it’s not part of TLS 1.3 yet.
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!)
Re: Show HN: Nginx Image with HTTP/3 (QUIC), TLS1.3 with 0-RTT, Brotli
#25I think 0-RTT is just bad idea security wise.
Re: Show HN: Nginx Image with HTTP/3 (QUIC), TLS1.3 with 0-RTT, Brotli
#26Earlier quoted context omitted.
Neither is the contrary suggested. I wouldn't point out something marked as experimental/not for prod use.
They literally say > All built on the bleeding edge. Built on the edge, for the edge. The only suggestion that this is meant "to handle all your traffic" is from you. It seems like your main complaint is that the author didn't use some specific 'experimental/not for prod use' tag. For my mind, that's exactly what 'bleeding edge' implies, but if you think it doesn't why not simply suggest that they add such a tag? No…
Well, I was actually responding to the OP... but I guess I could have been clearer in my intent - that was exactly what you stated: mark it as experimental/not for anything important.
Re: Show HN: Nginx Image with HTTP/3 (QUIC), TLS1.3 with 0-RTT, Brotli
#27Earlier quoted context omitted.
Neither is the contrary suggested. I wouldn't point out something marked as experimental/not for prod use.
Do you really require someone to point this out before running in production? If anyone doesn't know not to do that, it's on them, not OP.
[deleted]
Re: Show HN: Nginx Image with HTTP/3 (QUIC), TLS1.3 with 0-RTT, Brotli
#28I 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?
That's eSNI and I believe it's part of 1.3: https://tools.ietf.org/html/draft-ietf-tls-esni-04 Not sure what's the implementation status though.
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.
Re: Show HN: Nginx Image with HTTP/3 (QUIC), TLS1.3 with 0-RTT, Brotli
#29Earlier quoted context omitted.
Neither is the contrary suggested. I wouldn't point out something marked as experimental/not for prod use.
Do you really require someone to point this out before running in production? If anyone doesn't know not to do that, it's on them, not OP.
I simply believe that honesty is important. If I publish something that I know to be experimental, I mark it clearly as such.
And I point out others when they fail to reach that bar, so that they can fix it.
Re: Show HN: Nginx Image with HTTP/3 (QUIC), TLS1.3 with 0-RTT, Brotli
#30Earlier quoted context omitted.
They literally say > All built on the bleeding edge. Built on the edge, for the edge. The only suggestion that this is meant "to handle all your traffic" is from you. It seems like your main complaint is that the author didn't use some specific 'experimental/not for prod use' tag. For my mind, that's exactly what 'bleeding edge' implies, but if you think it doesn't why not simply suggest that they add such a tag? No…
Well, I was actually responding to the OP... but I guess I could have been clearer in my intent - that was exactly what you stated: mark it as experimental/not for anything important.
Fair enough, I guess it doesn't really come across like that.
The author takes contributions, so they'd probably welcome a pull request on the README that introduced that kind of language. I have no idea if they'd merge it or not, but at least they would then reflect on the idea.