Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Status of HTTP/3

infoq.com

Post reply on HN
Print view View original

91–100 of 123 posts

Re: The Status of HTTP/3

#91

Post by tialaramex »

axaxs wrote: post #75
taf2 wrote: post #73

Earlier quoted context omitted.

Isn’t the DNS issue unrelated to the protocol of UDP vs TCP but rather how DNS service communicate with each other... triggers an amplification of one request into 100s or maybe 1000s... not really a tcp vs udp issue?

There's two issues at play there. What you're talking about is called amplification. That means you get responses far larger than the query. So you send a small query for say, TXT, and the server may reply with KBs of TXT records. However, that isn't useful by itself. Where it's useful is for attacking a third party. To do this, you spoof the source IP of your query to be the IP of the victim. This is called reflecti…

QUIC has address validation, basically if you talk back and forth with a remote party you can get yourself a token which proves you're on path (you might really be 10.20.30.40 we can't tell, but we can tell you can intercept packets for 10.20.30.40 because you received this token we sent there, maybe you're an adversary at their ISP) and you can use that token in future to prove you're still on path for 10.20.30.40, which an off-path attacker wouldn't be able to do because they can't get that token.

So this lets you prevent amplification. If somebody asks a question with a long answer, but doesn't provide the token to prove they're on path, you make them go around again first, a legitimate user sees one round trip wasted to get a token but attacks don't work..

Re: The Status of HTTP/3

#92

Post by wmf »

jrumbut wrote: post #46

For the builder of small to medium (say, 10k to 1 million monthly users, some media but not the primarily focus) websites, apps, APIs, etc, is it time to begin deploying HTTP/2 or even 3? How would one make the decision, what factors would influence it? What are some of the best books/essays arguing either direction? I believe in maintaining best practices even if you can get away with sloppiness on a specific projec…

You should be using public cloud and a CDN and they'll turn on protocols when they turn them on.

Re: The Status of HTTP/3

#93

Post by srj »

axaxs wrote: post #75
taf2 wrote: post #73

Earlier quoted context omitted.

Isn’t the DNS issue unrelated to the protocol of UDP vs TCP but rather how DNS service communicate with each other... triggers an amplification of one request into 100s or maybe 1000s... not really a tcp vs udp issue?

There's two issues at play there. What you're talking about is called amplification. That means you get responses far larger than the query. So you send a small query for say, TXT, and the server may reply with KBs of TXT records. However, that isn't useful by itself. Where it's useful is for attacking a third party. To do this, you spoof the source IP of your query to be the IP of the victim. This is called reflecti…

QUIC addresses this, like TCP it's a connection based protocol. It's just implemented in user space on top of UDP. The server response is required to be smaller than the client hello.

Re: The Status of HTTP/3

#94

Post by htfy96 »

mholt wrote: post #11

This article omits that Caddy has had long-running experimental support for HTTP/3 for a couple of years now: https://caddyserver.com/docs/json/apps/http/servers/experime...

One thing that drives me off from Caddy is that many features don't compose with each other well. I understand this might be a sacrifice for a simpler user interface, but the composition of declarative-style configurations is always a mess compared to imperative ones like nginx.conf

Re: The Status of HTTP/3

#96

Post by axaxs »

tialaramex wrote: post #91
axaxs wrote: post #75

Earlier quoted context omitted.

There's two issues at play there. What you're talking about is called amplification. That means you get responses far larger than the query. So you send a small query for say, TXT, and the server may reply with KBs of TXT records. However, that isn't useful by itself. Where it's useful is for attacking a third party. To do this, you spoof the source IP of your query to be the IP of the victim. This is called reflecti…

QUIC has address validation, basically if you talk back and forth with a remote party you can get yourself a token which proves you're on path (you might really be 10.20.30.40 we can't tell, but we can tell you can intercept packets for 10.20.30.40 because you received this token we sent there, maybe you're an adversary at their ISP) and you can use that token in future to prove you're still on path for 10.20.30.40,…

I was specifically answering the user's question regarding DNS attacks.

Address validation in QUIC is optional, per the RFC.

Re: The Status of HTTP/3

#97

Post by mholt »

htfy96 wrote: post #94
mholt wrote: post #11

This article omits that Caddy has had long-running experimental support for HTTP/3 for a couple of years now: https://caddyserver.com/docs/json/apps/http/servers/experime...

One thing that drives me off from Caddy is that many features don't compose with each other well. I understand this might be a sacrifice for a simpler user interface, but the composition of declarative-style configurations is always a mess compared to imperative ones like nginx.conf

Thanks for the feedback.

(To clarify, nginx's config is also declarative... well, mostly: they got in trouble for mixing declarative and imperative [1].)

You'd be surprised what we've been able to accomplish with upgrades to Caddy's configuration in Caddy 2. Its config is technically declarative, but the underlying JSON structure [2] implies a procedural flow, enabling you to compose certain behaviors that almost feels imperative. When Caddy 2 release candidates go out in a couple months, try it out with both the Caddyfile (soon to be majorly improved in beta 13) and the underlying JSON and you'll see what I mean.

Oh, but if you want to still use your nginx config, go ahead (WIP) [3]. :)

[1]: https://www.nginx.com/resources/wiki/start/topics/depth/ifis...

[2]: https://caddyserver.com/docs/json/

[3]: https://github.com/caddyserver/nginx-adapter

Re: The Status of HTTP/3

#98

Post by zamadatix »

nikeee wrote: post #29
axaxs wrote: post #16

I hate to be a curmudgeon, but I can't help but think that designing a new service over UDP isn't the best idea. DNS has been fighting off wave after wave of attack vectors, some that realistically cannot even be fixed. Making it immune to these vectors is going to look a lot like a slapped together TCP over UDP...

It's fun to see how we kind of reinvented goold old DNS as soon as we use HTTP/3 for DoH. It runs on UDP, but with HTTP in between (and encrypted, of course). We could have done that with DNS itself, but somehow this never gained traction.

The difference DoH started with something nearly every network was guaranteed to have allowed: HTTPS traffic on TCP 443. Trying to wait for every network to allow DNS on 31218 or whatever wouldn't have worked. Even with a massive amount of the web guaranteed to move to HTTP/3 there will be places that still don't allow UDP 443 five years from now.

If ever something seems dumb in network protocol design the answer probably lies with ossification. Hopefully the design of HTTP/3 ends that.

Re: The Status of HTTP/3

#99

Post by manigandham »

comex wrote: post #72
manigandham wrote: post #31

Earlier quoted context omitted.

Too bad no major internet company wants to implement a new version of TCP. We can’t even get IPv6 done after 15 years.

“A new version of TCP” is pretty much what QUIC (basis of HTTP/3) is. It’s just tunneled over UDP because existing Internet infrastructure likes to drop anything that’s not TCP or UDP.

That's the problem being cited. The best option is to do a real update of TCP at layer 4, but nobody wants to put in the work and investment to do so.

Re: The Status of HTTP/3

#100

Post by detaro »

manigandham wrote: post #99
comex wrote: post #72

Earlier quoted context omitted.

“A new version of TCP” is pretty much what QUIC (basis of HTTP/3) is. It’s just tunneled over UDP because existing Internet infrastructure likes to drop anything that’s not TCP or UDP.

That's the problem being cited. The best option is to do a real update of TCP at layer 4, but nobody wants to put in the work and investment to do so.

Except we already have those layer 4 replacements (i.e. SCTP covers a lot of the same ground), and they've never managed to get out of the niches they are in. How would you suggest "a major internet company" motivate their support better?
Post reply on HN