27 ms·

Website Fingerprinting on Early QUIC Traffic

338 points by pueblito 6y ago

tyingq 6y ago
"allowing adversaries to infer the users' visited websites by eavesdropping on the transmission channel." Ah, ok, that kind of fingerprinting. I suppose then this might be where our local ISP's find a way to replace their now threatened DNS query sniffing. Assuming 95.4% accuracy means what I think it does, that's pretty impressive.
- bostik 6y ago
  I skimmed the paper and read it as an improved passive attack against ESNI and Do{T,H} setups. There's nothing really new, other than QUIC making it easier to identify the destinations. Traffic analysis is a harsh villain.
  - jeroenhd 6y ago
    Sadly, eSNI is dead in the water, but an alternative is being worked on. It'll just take longer for it to come to market.
    - vlmutolo 6y ago
      When you say ESNI is dead in the water, do you mean that it’s moved on to being ECH (encrypted client hello)? Or do you mean the entire concept is dead? If the latter, what makes you say that?
      - jeroenhd 6y ago
        I meant the conversion to ECH. eSNI has had proof-of-concept support built in for a while and, had it worked out better, could have been deployed publicly any day now. The new extension, ECH, will need significant testing and development until it can reach the same level of support again. The concept is the clear and obvious way forward in web security; what's the point in encrypting DNS when the SNI is still readable. I'm also glad that eSNI has been dropped because of the obvious flaws found in it rather than continuing attempts to secure an inherently flawed protocol. However, this does mean that deployment will take longer than previously estimated, which is kind of a bummer.
- wolfium3 6y ago
  Hah. I accidentally read "advertisers" instead of "adversaries". Still valid I guess...?
  - lrossi 6y ago
    That’s exactly how I read it as well!
    - kibwen 6y ago
      In the same way that we use "i18n" to abbreviate "internationalization", I propose we start using "adver5s" for both of these. :P
  - matheusmoreira 6y ago
    They might as well be synonyms at this point.
- londons_explore 6y ago
  I bet you could get 95.4% accuracy by simply looking at the IP addresses that users connect to. Each webpage comes from an IP, but includes subresources from a whole set of domains. I would guess that for the vast majority of web sites, that set of domains is unique.
  - tyingq 6y ago
    I'm guessing not, as they say "whereas only 60.7% when on HTTPS".
  - pabs3 6y ago
    Here is a presentation and blog post where they did a study about this: "What can you learn from an IP?" https://irtf.org/anrw/2019/slides-anrw19-final44.pdf https://irtf.org/anrw/2019/slides-anrw19-final44.pdf https://blog.apnic.net/2019/08/23/what-can-you-learn-from-an-ip-address/ https://blog.apnic.net/2019/08/23/what-can-you-learn-from-an...
    - londons_explore 6y ago
      > The majority of websites (95.7%) have a unique PLF, suggesting there is a risk of identifying that a user is visiting the site solely from a list of contacted IP addresses So, yes, IP addresses are plenty sufficient to figure out what someone is browsing.
deleted 6y ago
[deleted]
mdale 6y ago
It's odd state of the world where we will have to add significant amounts of noise to prevent browsers from revealing what site they are visiting because of traffic request protocols getting too efficient and browsers trying to be efficient in predictable ways.
- zdragnar 6y ago
  Isn't predictability the problem? It seems that many hardware and software attacks, at a very very high level, amount to being too predictable.
  - monadic3 6y ago
    No, the problem is the business model that incentivized selling their users up the river.
  - infogulch 6y ago
    I don't find it particularly surprising that optimizing for efficiency makes systems more predictable -- efficient implementations often lie in a local minimum that are independently discoverable.
- nine_k 6y ago
  Remember how truly secure channels keep transmitting random noise at a constant rate when they are not transmitting encrypted messages at the same rate. Anything which is non-uniform is an attack surface. If an efficiency improvement makes things more predictable, then it adds a possibility of a new snooping attack. All your interactions have to be as inefficient as your most inefficient interaction, else an adversary can tell them apart
  - anticristi 6y ago
    I never thought about this. Also, I find it depressing. Basically my browser needs to "keep watching some YouTube stream", so an attacker can't figure out that I switched to reading emails.
jamescun 6y ago
What are the proposed benefits of QUIC? May be misguided, but I feel a little uneasy about bundling TCP functionality, TLS and HTTP into a single protocol over UDP.
- Jonnax 6y ago
  Here's a comparison of HTTP2 vs HTTP3 (QUIC) from Cloudflare: https://blog.cloudflare.com/http-3-vs-http-2/ https://blog.cloudflare.com/http-3-vs-http-2/
- jsnell 6y ago
  Proper stream multiplexing, working connection migration on IP changes, faster connection setup for the common case with 0-RTT, solving the TCP ossification issues by decoupling protocol upgrades from OS upgrades and by preventing middleboxes from messing up flows when new options are introduced.
  - the8472 6y ago
    > working connection migration on IP changes MPTCP is available in iOS and recent linux kernels. So you don't need QUIC for that. > decoupling protocol upgrades from OS upgrades This is as much a downside as it is an upside. Now you have to potentially juggle hundreds of applications each shipping their own transport protocol implementation. And maybe their own DNS client too.
    - infogulch 6y ago
      Dynamic linking has lost. Static linking fully self-contained binaries / containers etc combined with robust, deterministic build automation is the future.
      - simias 6y ago
        I do think that in many situations dynamic linking doesn't make a whole lot of sense these days (like, say, a JPEG decoding library for instance). But having a central point where you can configure, test and administer networking makes a lot of sense to me. The idea of every application coming up with its own DNS implementation for instance annoys me greatly. I can already anticipate the amount of time I'm going to lose hunting down the way application X handles DNS because it won't apply my system-wide settings. I also firmly believe that SSL/TLS should've been handled at the OS level instead of everybody shipping their own custom OpenSSL implementations (complete with various vulnerabilities). I wish I could just use some setsockopt() syscalls to tell the OS I want a secure socket and let it figure out the rest. Moving stuff to higher layers is, IMO, mainly because Google wants to become the new Microsoft/Apple and moving that stuff up is a way to take the control away from Windows/Mac OS. The browser is the OS. You use web apps instead of apps. You turn every device out there into a glorified ChromeBook.
bluedino 6y ago
Is it still true that QUIC avoids inspection/filtering, so it's blocked by a lot of corporate firewalls?
- Jonnax 6y ago
  It's UDP which is generally blocked
- ReactiveJelly 6y ago
  Since it's a new protocol, they will probably err on the side of blocking it until they figure out how to MITM it. (Recently had to deal with a client who said nothing about MITMing our HTTPS, and a coworker who then installed a root cert for them anyway... really pissed me off.)
quotemstr 6y ago
Anything other than a pipenet will be fingerprintable at some level. A pipenet is a network in which all links run at constant utilization, with dummy traffic (indistinguishable from useful traffic) sent over the links during idle periods. Pipenets are of course inefficient, but everything else is going to reveal some kind of signal distinguishable from noise at some level.
- ReactiveJelly 6y ago
  Since I have broadband, it would be nice to set aside a couple percent of my bandwidth for a pipenet (maybe over Tor, as well) and then leave the rest for low-security stuff. That way I have a place for high-security low-bandwidth text to go if I ever need it.
  - pabs3 6y ago
    It is a shame that Tor itself doesn't have pipenet features.
tialaramex 6y ago
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.
- legulere 6y ago
  > 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
  - eli 6y ago
    Do any user agents still use gquic? People still use old phones but pretty rarely old versions of chrome.
    - gsnedders 6y ago
      Pretty sure Chromium/Chrome/derivatives still support gQUIC.
      - jefftk 6y ago
        There hasn't been any Intent to Remove, and it was mentioned in https://groups.google.com/a/chromium.org/g/blink-dev/c/K3rYLvmQUBY/m/vOWBKZGoAQAJ 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)
jpcsmith 6y ago
We had also investigated the differences in fingerprintability between HTTP/QUIC and HTTPS (WF in the Age of QUIC, PETS'21). We had found equivalent fingerprintability with deep-learning classifiers when eavesdropping on the traffic through Wireguard. It's interesting though to see the stark difference they found between fingerprinting HTTP/QUIC and HTTPS when using only the first ~40 packets. The trends in those early packets had also allowed us to easily differentiate between the two types of traffic over the VPN. Our paper, in case you want to read more on this area: https://petsymposium.org/2021/files/papers/issue2/popets-2021-0017.pdf https://petsymposium.org/2021/files/papers/issue2/popets-202...
superkuh 6y ago
QUIC is for corporations. Integrating TLS into a fundemental protocol means that cert authorities are integrated. Cert authorities mean that individual human people cannot communicate with each other over the protocol unless a corporation allows it on their whim. If QUIC is widely adopted it will do much to improve the performance video streaming from corporate services, but it will absolutely destroy the decentralization of the internet and provide single points of technical and political failure.
- cogman10 6y ago
  The internet hasn't been decentralized since pretty much it's inception. ICANN very much introduces a single point of failure that could wipe out the internet if it were disrupted. It could be replaced, but it would take years. In many ways, cert authorities are more decentralized than ICANN. This isn't to say we shouldn't worry about these single points of failure, rather, I think it's just an exaggeration of QUIC's impacts on decentralization.
  - ori_b 6y ago
    It's worth trying to reduce the amount of centralization, and make baby steps to improving the situation.
- pradn 6y ago
  We can hope that initiatives like LetsEncrypt will continue to exist so there's an alternative to paying for certs. LetsEncrypt does rely on a private company for it's certs, but at least it exists.
- jrockway 6y ago
  Nothing is stopping you from starting your own CA and distributing your own web browser that trusts the certificates. What underlying transport protocol is used doesn't change the complexity of removing corporate influence from the Internet. There is one root DNS namespace. Certificates prove that the stream your user agent receives from example.com is the example.com that is pointed to by the DNS system. That's it. No part of the Internet requires DNS or trusted-by-default CAs. It's just a convenience. Before widespread TLS adoption, your ISP could (and did!) inject ads into arbitrary websites. Now they can't. That's a good thing. It is actually amazing how little power your ISP has to tamper with your network traffic -- all they can do it shut it off completely.
1vuio0pswjnm7 6y ago
Pipelining, HTTP/1.1-style, not necessarily SPDY, HTTP/2 or QUIC-style, can effectively counter this sort of fingerprinting that relies on analysis of request-response sizes.^1 I have used HTTP/1.1 pipelining outside the browser for bulk data retrieval for decades. Although I do not normally randomise requests, the UNIX-style filters I wrote to do pipelining could easily be used for this purpose. 1. https://blog.torproject.org/experimental-defense-website-traffic-fingerprinting https://blog.torproject.org/experimental-defense-website-tra...
zeronone 6y ago
I assume most websites have a unique public IP, once you know the destination address, isn't it easy to infer the visited website.
- pabs3 6y ago
  If you don't use shared hosting it is very easy, and even if you do use shared hosting it is fairly easy: "What can you learn from an IP?" https://irtf.org/anrw/2019/slides-anrw19-final44.pdf https://irtf.org/anrw/2019/slides-anrw19-final44.pdf https://blog.apnic.net/2019/08/23/what-can-you-learn-from-an-ip-address/ https://blog.apnic.net/2019/08/23/what-can-you-learn-from-an...
deleted 6y ago
[deleted]

338 points by pueblito 6y ago

"allowing adversaries to infer the users' visited websites by eavesdropping on the transmission channel." Ah, ok, that kind of fingerprinting. I suppose then this might be where our local ISP's find a way to replace their now threatened DNS query sniffing. Assuming 95.4% accuracy means what I think it does, that's pretty impressive.

bostik 6y ago
I skimmed the paper and read it as an improved passive attack against ESNI and Do{T,H} setups. There's nothing really new, other than QUIC making it easier to identify the destinations. Traffic analysis is a harsh villain.
- jeroenhd 6y ago
  Sadly, eSNI is dead in the water, but an alternative is being worked on. It'll just take longer for it to come to market.
  - vlmutolo 6y ago
    When you say ESNI is dead in the water, do you mean that it’s moved on to being ECH (encrypted client hello)? Or do you mean the entire concept is dead? If the latter, what makes you say that?
    - jeroenhd 6y ago
      I meant the conversion to ECH. eSNI has had proof-of-concept support built in for a while and, had it worked out better, could have been deployed publicly any day now. The new extension, ECH, will need significant testing and development until it can reach the same level of support again. The concept is the clear and obvious way forward in web security; what's the point in encrypting DNS when the SNI is still readable. I'm also glad that eSNI has been dropped because of the obvious flaws found in it rather than continuing attempts to secure an inherently flawed protocol. However, this does mean that deployment will take longer than previously estimated, which is kind of a bummer.
wolfium3 6y ago
Hah. I accidentally read "advertisers" instead of "adversaries". Still valid I guess...?
- lrossi 6y ago
  That’s exactly how I read it as well!
  - kibwen 6y ago
    In the same way that we use "i18n" to abbreviate "internationalization", I propose we start using "adver5s" for both of these. :P
- matheusmoreira 6y ago
  They might as well be synonyms at this point.
londons_explore 6y ago
I bet you could get 95.4% accuracy by simply looking at the IP addresses that users connect to. Each webpage comes from an IP, but includes subresources from a whole set of domains. I would guess that for the vast majority of web sites, that set of domains is unique.
- tyingq 6y ago
  I'm guessing not, as they say "whereas only 60.7% when on HTTPS".
- pabs3 6y ago
  Here is a presentation and blog post where they did a study about this: "What can you learn from an IP?" https://irtf.org/anrw/2019/slides-anrw19-final44.pdf https://irtf.org/anrw/2019/slides-anrw19-final44.pdf https://blog.apnic.net/2019/08/23/what-can-you-learn-from-an-ip-address/ https://blog.apnic.net/2019/08/23/what-can-you-learn-from-an...
  - londons_explore 6y ago
    > The majority of websites (95.7%) have a unique PLF, suggesting there is a risk of identifying that a user is visiting the site solely from a list of contacted IP addresses So, yes, IP addresses are plenty sufficient to figure out what someone is browsing.

deleted 6y ago

[deleted]

mdale 6y ago

It's odd state of the world where we will have to add significant amounts of noise to prevent browsers from revealing what site they are visiting because of traffic request protocols getting too efficient and browsers trying to be efficient in predictable ways.

zdragnar 6y ago
Isn't predictability the problem? It seems that many hardware and software attacks, at a very very high level, amount to being too predictable.
- monadic3 6y ago
  No, the problem is the business model that incentivized selling their users up the river.
- infogulch 6y ago
  I don't find it particularly surprising that optimizing for efficiency makes systems more predictable -- efficient implementations often lie in a local minimum that are independently discoverable.
nine_k 6y ago
Remember how truly secure channels keep transmitting random noise at a constant rate when they are not transmitting encrypted messages at the same rate. Anything which is non-uniform is an attack surface. If an efficiency improvement makes things more predictable, then it adds a possibility of a new snooping attack. All your interactions have to be as inefficient as your most inefficient interaction, else an adversary can tell them apart
- anticristi 6y ago
  I never thought about this. Also, I find it depressing. Basically my browser needs to "keep watching some YouTube stream", so an attacker can't figure out that I switched to reading emails.

jamescun 6y ago

What are the proposed benefits of QUIC? May be misguided, but I feel a little uneasy about bundling TCP functionality, TLS and HTTP into a single protocol over UDP.

Jonnax 6y ago
Here's a comparison of HTTP2 vs HTTP3 (QUIC) from Cloudflare: https://blog.cloudflare.com/http-3-vs-http-2/ https://blog.cloudflare.com/http-3-vs-http-2/
jsnell 6y ago
Proper stream multiplexing, working connection migration on IP changes, faster connection setup for the common case with 0-RTT, solving the TCP ossification issues by decoupling protocol upgrades from OS upgrades and by preventing middleboxes from messing up flows when new options are introduced.
- the8472 6y ago
  > working connection migration on IP changes MPTCP is available in iOS and recent linux kernels. So you don't need QUIC for that. > decoupling protocol upgrades from OS upgrades This is as much a downside as it is an upside. Now you have to potentially juggle hundreds of applications each shipping their own transport protocol implementation. And maybe their own DNS client too.
  - infogulch 6y ago
    Dynamic linking has lost. Static linking fully self-contained binaries / containers etc combined with robust, deterministic build automation is the future.
    - simias 6y ago
      I do think that in many situations dynamic linking doesn't make a whole lot of sense these days (like, say, a JPEG decoding library for instance). But having a central point where you can configure, test and administer networking makes a lot of sense to me. The idea of every application coming up with its own DNS implementation for instance annoys me greatly. I can already anticipate the amount of time I'm going to lose hunting down the way application X handles DNS because it won't apply my system-wide settings. I also firmly believe that SSL/TLS should've been handled at the OS level instead of everybody shipping their own custom OpenSSL implementations (complete with various vulnerabilities). I wish I could just use some setsockopt() syscalls to tell the OS I want a secure socket and let it figure out the rest. Moving stuff to higher layers is, IMO, mainly because Google wants to become the new Microsoft/Apple and moving that stuff up is a way to take the control away from Windows/Mac OS. The browser is the OS. You use web apps instead of apps. You turn every device out there into a glorified ChromeBook.

bluedino 6y ago

Is it still true that QUIC avoids inspection/filtering, so it's blocked by a lot of corporate firewalls?

Jonnax 6y ago
It's UDP which is generally blocked
ReactiveJelly 6y ago
Since it's a new protocol, they will probably err on the side of blocking it until they figure out how to MITM it. (Recently had to deal with a client who said nothing about MITMing our HTTPS, and a coworker who then installed a root cert for them anyway... really pissed me off.)

quotemstr 6y ago

Anything other than a pipenet will be fingerprintable at some level. A pipenet is a network in which all links run at constant utilization, with dummy traffic (indistinguishable from useful traffic) sent over the links during idle periods. Pipenets are of course inefficient, but everything else is going to reveal some kind of signal distinguishable from noise at some level.

ReactiveJelly 6y ago
Since I have broadband, it would be nice to set aside a couple percent of my bandwidth for a pipenet (maybe over Tor, as well) and then leave the rest for low-security stuff. That way I have a place for high-security low-bandwidth text to go if I ever need it.
- pabs3 6y ago
  It is a shame that Tor itself doesn't have pipenet features.

tialaramex 6y ago

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.

legulere 6y ago
> 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
- eli 6y ago
  Do any user agents still use gquic? People still use old phones but pretty rarely old versions of chrome.
  - gsnedders 6y ago
    Pretty sure Chromium/Chrome/derivatives still support gQUIC.
    - jefftk 6y ago
      There hasn't been any Intent to Remove, and it was mentioned in https://groups.google.com/a/chromium.org/g/blink-dev/c/K3rYLvmQUBY/m/vOWBKZGoAQAJ 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)

jpcsmith 6y ago

We had also investigated the differences in fingerprintability between HTTP/QUIC and HTTPS (WF in the Age of QUIC, PETS'21). We had found equivalent fingerprintability with deep-learning classifiers when eavesdropping on the traffic through Wireguard. It's interesting though to see the stark difference they found between fingerprinting HTTP/QUIC and HTTPS when using only the first ~40 packets. The trends in those early packets had also allowed us to easily differentiate between the two types of traffic over the VPN. Our paper, in case you want to read more on this area: https://petsymposium.org/2021/files/papers/issue2/popets-2021-0017.pdf https://petsymposium.org/2021/files/papers/issue2/popets-202...

superkuh 6y ago

QUIC is for corporations. Integrating TLS into a fundemental protocol means that cert authorities are integrated. Cert authorities mean that individual human people cannot communicate with each other over the protocol unless a corporation allows it on their whim. If QUIC is widely adopted it will do much to improve the performance video streaming from corporate services, but it will absolutely destroy the decentralization of the internet and provide single points of technical and political failure.

cogman10 6y ago
The internet hasn't been decentralized since pretty much it's inception. ICANN very much introduces a single point of failure that could wipe out the internet if it were disrupted. It could be replaced, but it would take years. In many ways, cert authorities are more decentralized than ICANN. This isn't to say we shouldn't worry about these single points of failure, rather, I think it's just an exaggeration of QUIC's impacts on decentralization.
- ori_b 6y ago
  It's worth trying to reduce the amount of centralization, and make baby steps to improving the situation.
pradn 6y ago
We can hope that initiatives like LetsEncrypt will continue to exist so there's an alternative to paying for certs. LetsEncrypt does rely on a private company for it's certs, but at least it exists.
jrockway 6y ago
Nothing is stopping you from starting your own CA and distributing your own web browser that trusts the certificates. What underlying transport protocol is used doesn't change the complexity of removing corporate influence from the Internet. There is one root DNS namespace. Certificates prove that the stream your user agent receives from example.com is the example.com that is pointed to by the DNS system. That's it. No part of the Internet requires DNS or trusted-by-default CAs. It's just a convenience. Before widespread TLS adoption, your ISP could (and did!) inject ads into arbitrary websites. Now they can't. That's a good thing. It is actually amazing how little power your ISP has to tamper with your network traffic -- all they can do it shut it off completely.

1vuio0pswjnm7 6y ago

Pipelining, HTTP/1.1-style, not necessarily SPDY, HTTP/2 or QUIC-style, can effectively counter this sort of fingerprinting that relies on analysis of request-response sizes.^1 I have used HTTP/1.1 pipelining outside the browser for bulk data retrieval for decades. Although I do not normally randomise requests, the UNIX-style filters I wrote to do pipelining could easily be used for this purpose. 1. https://blog.torproject.org/experimental-defense-website-traffic-fingerprinting https://blog.torproject.org/experimental-defense-website-tra...

zeronone 6y ago

I assume most websites have a unique public IP, once you know the destination address, isn't it easy to infer the visited website.

pabs3 6y ago
If you don't use shared hosting it is very easy, and even if you do use shared hosting it is fairly easy: "What can you learn from an IP?" https://irtf.org/anrw/2019/slides-anrw19-final44.pdf https://irtf.org/anrw/2019/slides-anrw19-final44.pdf https://blog.apnic.net/2019/08/23/what-can-you-learn-from-an-ip-address/ https://blog.apnic.net/2019/08/23/what-can-you-learn-from-an...

deleted 6y ago

[deleted]