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

Some notes about HTTP/3

blog.erratasec.com

Post reply on HN
Print view View original

131–140 of 181 posts

Re: Some notes about HTTP/3

#131

Post by nneonneo »

tialaramex wrote: post #48

The discussion of standards seems like it unhelpfully conflates the reality of standardisation by bodies like the IETF that have no discernible authority and don't want it even if it were possible - with "de facto" standards which it says are just whatever people do in practice. Not so. The IETF is not a conventional SDO, nor indeed a conventional organisation of any sort, since it has no members, and it operates on…

> is an informational RFC so a Microsoft employee just dumped it as written, no chance for anyone to say...

Which is ironic, considering “RFC” stands for “Request for Comments”.

Re: Some notes about HTTP/3

#133

Post by Buge »

JBiserkov wrote: post #126
zamadatix wrote: post #113

Earlier quoted context omitted.

The challenge for http/3 will be middleboxes not endpoints. Put another way: it won't be hard to break 50% of traffic on http/3 but you will still be running 2 10 years from now if you want to reach the last 10% of users.

Middleboxes will only see UDP, no? From their perspective nothing has changed? Isn’t that the whole idea?

How many middleboxes block all UDP?

Re: Some notes about HTTP/3

#134

Post by rustcharm »

It's getting very complicated to understand everything that happens when you click on a link in a browser. And I wonder if these UDP protocols are better than fixing the issues with TCP. Of course, it may allow loading from several servers simultaneously a la bittorrent.

Re: Some notes about HTTP/3

#135

Post by mentat »

dogma1138 wrote: post #128
ComputerGuru wrote: post #123

Earlier quoted context omitted.

http.sys is strictly for listening for inbound connections and not a general purpose HTTP API. Amongst other things, it lets multiple applications listen to port 80 on Windows. Didn't read through this article the whole way, but it was the first I found to share that seemed to give a good overview: https://www.codeproject.com/articles/437733/demystify-http-s...

Yes, http.sys is an http server implemented in the Windows Kernel it’s the http server IIS and all other http based windows services use and has an API for 3rd party servers. https://docs.microsoft.com/en-us/iis/get-started/introductio... The point being that there are advantages to implementing a kernel or hybrid mode HTTP server and Microsoft has done it on Windows some other implementations exist but other than MF…

The history of IIS vulnerabilities with in kernel execution and the time it takes to get comprehensive patching seem like pretty substantial disadvantages.

Re: Some notes about HTTP/3

#136

Post by int_19h »

tor_user wrote: post #106
penagwin wrote: post #103

Earlier quoted context omitted.

Running old versions of HTTP requires nothing because people will need to support legacy devices for a long time, and it's obviously already implemented in all major components (Servers, CDNs, Clients, etc.)

???? != nothing. Why run HTTP/3 if HTTP/1 costs nothing? Where I work legacy gets dropped sooner rather than later. I hope this bombs, er tanks.

You (will) run HTTP/3, because it is more efficient, meaning that your servers will be able to service more request.

You run HTTP/2 and HTTP/1, because a lot of people are still using that, and you don't want to lose them. This especially applies to mobile devices, many of which are stuck with software that cannot be updated for various reasons.

There's no threat of the majority of websites going HTTP/3 anytime soon. By the time that might be a possibility, Tor will catch up.

Re: Some notes about HTTP/3

#137

Post by tyingq »

PeterisP wrote: post #130
tyingq wrote: post #37

Earlier quoted context omitted.

That's because other UDP based protocols don't have tcp like sequence numbers or other anti-spoofing measures. Quic has a source address token that makes it hard to spoof.

As far as I understand, the parent's point is that QUIC makes your network vulnerable to attacks from spoofed non-QUIC services because you have to allow UDP packets to reach your network - their usual practice is to protect yourself by just dropping all UDP, but as soon as you want a single system to serve QUIC, then you can't do that anymore and need to inspect all these UDP packages even if it's an extreme amount…

Confused. You don't have to allow all UDP traffic. Just port 443 for some specific set of IP addresses.

Re: Some notes about HTTP/3

#138

Post by foobiekr »

Buge wrote: post #133
JBiserkov wrote: post #126

Earlier quoted context omitted.

Middleboxes will only see UDP, no? From their perspective nothing has changed? Isn’t that the whole idea?

How many middleboxes block all UDP?

QUIC forcing these boxes out of the network is a feature not a bug.

Re: Some notes about HTTP/3

#139

Post by exabrial »

Is it possible to turn encryption off? If I'm running a cluster of sensors on a remote airgapped network, the ease of using tools like tcpdump and nc far outweigh the need for encryption, especially if one is power constrained.

Re: Some notes about HTTP/3

#140

Post by askvictor »

exabrial wrote: post #139

Is it possible to turn encryption off ? If I'm running a cluster of sensors on a remote airgapped network, the ease of using tools like tcpdump and nc far outweigh the need for encryption, especially if one is power constrained.

Presumably you're not being forced to use http/3 and can continue to use whatever you're using now? Or is there a particular reason that you want to move to http/3 for that network?
Post reply on HN