HTTP/3 is a thing. Here's some news about it

Primarily its core seems to be QUIC over HTTP. They’ve been working with the IETF and Google and Mozilla on the standard.

the TL;DR

This is where HTTP/3 comes into play: instead of using TCP as the transport layer for the session, it uses QUIC, a new Internet transport protocol, which, among other things, introduces streams as first-class citizens at the transport layer. QUIC streams share the same QUIC connection, so no additional handshakes and slow starts are required to create new ones, but QUIC streams are delivered independently such that in most cases packet loss affecting one stream doesn’t affect others. This is possible because QUIC packets are encapsulated on top of UDP datagrams.

Using UDP allows much more flexibility compared to TCP, and enables QUIC implementations to live fully in user-space — updates to the protocol’s implementations are not tied to operating systems updates as is the case with TCP. With QUIC, HTTP-level streams can be simply mapped on top of QUIC streams to get all the benefits of HTTP/2 without the head-of-line blocking.

QUIC also combines the typical 3-way TCP handshake with TLS 1.3’s handshake. Combining these steps means that encryption and authentication are provided by default, and also enables faster connection establishment. In other words, even when a new QUIC connection is required for the initial request in an HTTP session, the latency incurred before data starts flowing is lower than that of TCP with TLS.

Honestly. Might be good. I’m not sure how id test out its actual improvements in any noticeable way, but perhaps this makes a lot of sense with the increasing number of mobile devices using HTTP.

7 Likes

From an enduser perspective it’s just a bit faster.

From an IT perspective, QUIC requires substantial changes to load-balancing. But if you aren’t a big player, just flick the switch at Cloudflare and let them do it for you.

2 Likes

I know im necroing the shit out of this but I think its a relevant necro…

HTTP/3 is now implemented by NGINX. I have my webservers running it.

Its pretty nice as its removes the overhead of HTTP/2 a bit by moving to UDP. It really is a faster more stable connection request overall.

Id like to reopen the discussion without duping the thread please

5 Likes

Have they actually finished the design and implemented it as a RFC? I thought QUIC was still a work in progress.

Edit: oh, snap, a necro. thanks PLL

still a work in progress

its not low effort so technically im allowed to revive it. Here are some resources on performance I forgot to post

2 Likes

Theres an associated set of security issues as well. Things ive read on:

0-RTT resumption vulnerabilities

There are some security downsides due to the 0-RTT resumption feature. One of the most common attack vectors is replaying attacks that can be caused when an adversary resends the initial packet; in specific scenarios, this may force the server to believe that the request came from a previously known client. Another security downside of the 0-RTT resumption is the partial failure of full-forward secrecy. If an adversary compromises the tokens, they can decrypt the 0-RTT communications sent by the user-agent.

Stream exhaustion attack
A stream exhaustion attack occurs when an adversary intentionally starts multiple connection streams, which may result in an endpoint getting exhausted. The attacker can utilize the exhaustion sequence by flooding the request repeatedly. This can open up a server with increased capacity in its parameters to a DDOS attack if not managed carefully

Connection reset attack
Connection reset attacks are mainly sending stateless resets to the victims, thereby creating a possibility of denial of service attacks similar to TCP reset injection attacks. Its also similar to packet injecting disassociation packets on an STA - CLIENT infrastructure mode wifi network.

Connection ID manipulation attacks
Connection ID manipulation attacks require an attacker to be positioned between the user-agent and the server. They can manipulate the Connection ID during the initial handshake where the client and server hello messages are exchanged. The handshake will proceed as normal and the server will assume that the connection is established, but the user-agent will fail to decrypt because the Connection ID is an input to the encryption key derivation process and the user-agent and server will compute different encryption keys. This can be managed by controlling time out times

UDP amplification attack
Specifically, in QUIC, UDP amplification attacks occur when an adversary accepts an address validation token from the target and releases the IP address that was initially used to generate the token. An attacker can send a 0-RTT connection back to the server with the same IP address, which may have changed to point to a different endpoint. With the successful execution of this setup, the attacker can potentially instruct the server to send substantial traffic towards the victim server. To prevent this attack, HTTP/3 has rate-limiting features and short-lived validation tokens that can act as a compensating control to DDOS attacks, while partially mitigating the attack scenario.


I have debated emailing the folks at ssllabs by qualsys SSL Server Test (Powered by Qualys SSL Labs) about including H3 testing and helping people secure against that as H3 becomes more prevalent.

They only test H2 vulnerabilities to which my server configuration passes perfectly


It cant detect H3 yet :confused: and because of this ive disabled QUIC responses for all sockets (including DNS) and HTTP. Until it can be audited. I am capable of it which is cool

4 Likes

Apparently, HAProxy has some initial support for QUIC, but nothing fancy (can barely do a handshake). I prefer it as a reverse proxy. If I have to host anything fancy, I choose nginx as a web server usually, if not, something minimal like darkhttpd or if I get the chance to use OpenBSD, its own httpd.

2 Likes

This has now graduated as standard.

2 Likes

a (relatively) new vid released which kinda helps explain the use of UDP, and some implications

3 Likes

I came across This interview with David Bombal. He interviewed one of the team members who worked on the new QUIC protocol.
I thought I would share it. I thought it was exciting and could potentially be a security nightmare. What are your thoughts?

3 Likes

Came here to post this. beat me to it

2 Likes

I haven’t seen the interview, I think having more secure end-to-end crypto by default that ISPs/middleboxes can’t mess with as easily, is a good thing.

For corporate use, you can always install your own certs and proxy everything.

1 Like

I don’t know if other firewall vendors have added it yet but Fortinet was the first to add QUIC inspection only 3 months ago and it’s only in the 7.2.0 version which isn’t considered to be the stable build train. The recommendation for previous versions is to block QUIC enirely. Other vendors like Palo Alto also recommend blocking it.

most of my coms go over tcp rather than udp.
infact i block udp by default with the vpn on.
why?
it lacks authentication.
because there is none its a faster protocol but also prone to packet loss resulting in the need for packet duplication.

we have all played fps games where people started slewing due to packet drop, high ping, and server load balancing issues. all caused by udp.

so im at a loss as to why they would choose to use it to underpin http3

Games make a good case for UDP.
It does not help to finally find out a missing packet from two seconds ago, the critical shot either failed or succeeded, one either dodged into the cover or not.
Can’t go back in time.

Same with livestream broadcasts, no point receiving data that has already gotten past.

Obviously there needs to be two way coms, but the back and forth verification and checks add up.

I would say there are times and places for both

I do the same. All udp in / out traffic blocked centrally on the lan / wan gate and only selected machines may have an exception. Especially important when there are a lot of Android devices without root, and then the firewall does not have the ability to block udp.

:wink:

nonsense e.g. wireguard and many VPNs work over udp; tcp doesn’t really have authentication either.


TCP’s job is to packetize multiple streams of data, and keep track of what’s been received in each stream, what hasn’t been what’s been lost and needs to be re-sent, how fast to send and so on.

UDP’s job is to send packets back and forth between apps.

IP’s job is to send packets back and forth between hosts.

QUIC does the same as TCP, only encrypted. It happens to be implemented in userspace, and it just happens to use UDP as it’s underlying transport for packets, as opposed to IP directly (which is what TCP does).

This is because existing firewalls mostly block anything not TCP/UDP… incl. to a large extent ICMP.

10 or 20 years from now, we might have QUIC over IP instead of UDP, and we might have TCP-to-QUIC and QUIC-to-TCP proxies, and we might have QUIC implementations in the kernels and NIC hardware (same as we do with TCP and TLS today).

HTTP/3 just happens to be a “killer use case”, because websites require multiple resources to be displayed, which are best delivered from server to client using multiple fault tolerant streams of data. Unlike HTTP/2, it relies on QUIC to handle multiple streams, rather than implementing multiple streams itself on top of several TCP or TLS connections.

1 Like

@HEXiT Did you watch the interview he tried to use TCP, but there were so many stumbling blocks they had to use UDP; watch it. The interviewee explained why better than I could.

1 Like

I second watching the interview.

It made sense to me as basically a retard.

Things like TCP handshakes not allowing data packets, but UDP allowing it, means they can basically send three packets in one, and all sorts of fun things like that.

But, less fun for firewalls checking stuff.
Hence the title.

It’s not a hard watch

2 Likes