Hacker News Reader

Comment by jmole | Hacker News Reader

FTA [1]: "the only piece that links the authentication server to the data tunnel server is a single, public key, used to sign all blinded tokens presented during a limited period of time"

It sounds like the only information Google could produce is: "yes, this traffic came from our VPN, here is a list of the 20,000 users who logged in during this key rotation period"

Am I missing something?

View on HN

Yes, this is the concept, and the NCC report correctly identifies a lot of deltas with reality, which also I outlined in my comment above:

* Google or a privileged attacker sitting at either end of the VPN could exfiltrate the user's identity through packet inspection and unencrypted personal identifiers in the user's VPN traffic, both obvious identifiers like plaintext data on the network and less obvious identifiers like specific subdomains or IPs correlated to a specific set of identities. This is a fairly fundamental problem with all "privacy" VPNs - as soon as you've exposed your identity by logging into a service over the VPN link, you're fairly easily unmasked again to a privileged attacker.

* If the authentication and VPN services have timestamped logging, the user's identity leaks through this side channel. At Google scale of course there's still bound to be some mixing, but it's a lot more granular than a key rotation period.

* A privileged attacker could also perform network analysis between the authentication and VPN services as well to achieve the same goal.

Perhaps Google have some lightweight countermeasures against these types of attack (even a random some-milliseconds timing at the client side between receiving a signed blind token and using it to establish the VPN connection would help a tiny bit), but if they do, they weren't outlined in the report.

My takeaway from this is "Google made a fine VPN, but it's nothing ground breaking, and so-called Privacy VPNs are still not a thing." Depending on your threat model a VPN is still a very useful tool, but none of them can truly anonymize you.

Your set of queried host names via DNS (unencrypted) is probably globally unique or close to it.

Additionally SNI is (usually) not encrypted so all of your browsing hostnames are sent in the clear (over the VPN) even when using TLS and DoH.

> Perhaps Google have some lightweight countermeasures against these types of attack (even a random some-milliseconds timing at the client side between receiving a signed blind token and using it to establish the VPN connection would help a tiny bit), but if they do, they weren't outlined in the report.

The client could pre-generate session tokens days or months in advance. Then, leave their house, head to public wifi, (to avoid traffic correlation on their home network) and even after unblinding the session token, it would not be feasible to determine who paid for VPN.

If Google's VPN used Tornado Cash's protocol, they wouldn't be able to take the proof of having a session key back to Zinc to determine who asked for that to be signed. (if we assume Zinc is malicious) The protocol used looks like it was to provide anonymity with third parties, but not anonymity to the first parties. Google also links to the paper from 1982 that they're referencing. [1]

[1] https://www.hit.bme.hu/~buttyan/courses/BMEVIHIM219/2009/Cha...

Reply on news.ycombinator.com