Hacker News Reader

Comment by tialaramex | Hacker News Reader

At least some of this document is based on much older versions of QUIC. In particular it mentions RST_STREAM which went away by the end of 2018 in favour of RESET_STREAM.

In fact it's possible it isn't even talking about the proposed IETF protocol QUIC at all, but instead Google's QUIC ("gQUIC" in modern parlance) in which case this might as well be a paper saying the iPhone is vulnerable to an attack but it turns out it means a 1980s device named "iPhone" not the Apple product.

It certainly references a bunch of gQUIC papers, which could mean that's blind references from a hasty Google search by researchers who don't read their own references - but equally could mean they really did do this work on gQUIC.

View on HN

As you know from carefully reading the paper, it states that they cloned the sites with HTrack and served them on their LAN with "Caddy Server2". Perhaps then we could guess that the version of QUIC they tested is the version of QUIC that Caddy is using: https://github.com/lucas-clemente/quic-go (v0.19.3)

> in which case this might as well be a paper saying the iPhone is vulnerable to an attack but it turns out it means a 1980s device named "iPhone" not the Apple product.

More like it means the iPhone X instead of the newer iPhone 11

Do any user agents still use gquic? People still use old phones but pretty rarely old versions of chrome.

Pretty sure Chromium/Chrome/derivatives still support gQUIC.

There hasn't been any Intent to Remove, and it was mentioned in https://groups.google.com/a/chromium.org/g/blink-dev/c/K3rYL..., so yes I think it still supported.

On the other hand, since this set of vulnerabilities seems to be about passive fingerprinting by intermediaries, what actually matters is how much traffic is still running gquic, right? And I think most servers have moved over to HTTP/3?

(Disclosure: I work for Google, speaking only for myself)

Given gQUIC was never _that_ broadly deployed (mostly Google and a few CDNs, IIRC), I can't imagine it would be overly significant to disable. Last I knew there were some Google properties still using gQUIC, but that was a while ago.

Current versions of Chrome still use gQUIC for most instances when talking with gQUIC-capable servers such as Google and Youtube.

Just checked, mine used version Q050 just now.

Of course, there are many versions of gQUIC, some more like IETF QUIC than others as they are transitioning parts of the protocol in stages. Version Q050 is the pre-TLS version.

As it's used between Chrome and Youtube, a lot of the world's internet traffic is over gQUIC at the moment.

But this can indeed might make a difference if you're talking vulnerabilities and support - for example, iPhone 10 is vulnerable to checkm8 while models 11 and newer aren't.

A more accurate analogy based on the relationship between gQUIC and IETF QUIC would be that an early non-released version of the iPhone is vulnerable to an attack.

Reply on news.ycombinator.com