The actual pentest findings here are pretty boring, but the architecture details are quite interesting, as are the identified risk models for the attempt at "anonymity."
The fundamental anonymity model Google have employed is that the VPN tunnel is authenticated using "blind tokens" which are signed by an authorization service "Zinc." The Zinc service validates OAuth credentials passed in from the client app to verify a user's subscription, then signs the blind token created by the client app to authorize the user's session with the actual VPN backend "Copper." Ostensibly, this will separate the user's Google identity from the VPN identity since the VPN service only knows that it got a valid, signed user token, not what user that token belongs to.
Ultimately, as pointed out in the report, this is IMHO not that useful. Google could still trivially re-correlate traffic inside of the VPN service by using packet inspection combined with a crafted (or accidental!) plaintext sidechannel from an authenticated Google client application (unencrypted DNS requests to a special subdomain, port/IP knocking style requests to a specific list of IPs in a specific order, etc.).
Also, if there's timestamped logging in both the Zinc and Copper services, the attempt at blinding between the two sides of the system is also quite meaningless since the flow to Zinc and the flow to Copper could just be back-correlated back into a user identity using timing by a Google employee with access to logs.
Although it might not be very reassuring to people on the outside who treat Google as a monolithic threat, internal controls like this do make insider attacks more difficult, by making them more visible to internal security and audits.
In particular, it sounds like it would be difficult to do it via log analysis alone; it would have to be a more active attack and may require code changes. Either changing code in source control or somehow swapping in a different binary can be pretty noisy (assuming there are good controls over the build and deploy process).
You might compare with having good accounting. You can't just trust people when they say, "we have strict accounting" because they could very well be lying, but nonetheless, not having proper accounting is a red flag.
It seems interesting to me that even if we consider Google as a monolith, the authorities with abilities to compel Google are not monolithic and have varied rights and varied legitimacy. Quite a few groups that could subpoena logs could not compel active actions like wire tapping, etc.
> The fundamental anonymity model Google have employed is that the VPN tunnel is authenticated using "blind tokens" which are signed by an authorization service "Zinc." The Zinc service validates OAuth credentials passed in from the client app to verify a user's subscription, then signs the blind token created by the client app to authorize the user's session with the actual VPN backend "Copper." Ostensibly, this will separate the user's Google identity from the VPN identity since the VPN service only knows that it got a valid, signed user token, not what user that token belongs to.
In case you needed even more information on how this works, Google provides on their page [1]
> The blinding algorithm employed was first described by Chaum in 19826, and is commonly referred to as ‘RSA Blind Signing’. The goal is to never use the same identifier in the Authentication server and the Key Management Service. To accomplish this, the client generates a token, hashes it using a Full Domain Hash, and combines it with a random value and the server’s public signing key to produce a blinded token. That blinded token is then signed by our authentication server. When the client wants to connect to the VPN, it can unblind the blinded token and its signature using the random value only it knows. The unblinded token and the signature are then verifiable by our Key Management Server.
This is an easy way to understand how this works. This actually does not sound like the start-of-the-art for cryptography. In their example, the client has to provide the secret, which, then corresponds to a hash that was encrypted using this secret key along with Zinc's public key. Zinc knows who provided it the blinded token that it signed. On revelation of this secret key, Zinc could immediately determine who is the owner.
Tornado Cash bypasses this leak of information by using a zero knowledge proof involving a Merkle path [2]
> This actually does not sound like the start-of-the-art for cryptography.
I'm wrong. Review the paper Google provided as a source for more information. [1] There are also lectures available online from Ronald Rivest, [2] one of the researchers that helped to invent/discover the RSA cryptosystem. (If you are not familiar with how RSA works)
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"
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.
> 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]
It seems very silly to analyze the Google VPN with Google as your privacy adversary. The point of the VPN is to hide your traffic from 9th-circle privacy adversaries like local telephone companies.
It also seems pretty silly to mix in interesting findings in a big PDF sprinkled among other items that are, speaking generously, debatable matters of opinion, like whether programs should be stripped or not.
One such "interesting finding" is that the VPN software is run with admin privileges, including the parts that deal with concepts which would not need admin privileges, such as debug logging, because this increases the attack surface for a hacker who already has limited control of the machine, to potentially elevate their privileges, if they manage to find vulnerability.
This is one of their medium findings. This report smells like "Guys, we MUST find something, give me something, anything!"... :P
These reports usually start from a baseline template/checklist. I'm sure the "unobfuscated binary" and "admin" findings that everyone on this thread is making fun of are part of the SOP for NCC Group audits of native applications.
We laugh and argue that this makes pentests a joke (which plenty are!), but at the end of the day that "admin" note resulted in a material improvement, however tiny, in the system. Google reacted by removing the need for escalation from the application and now an attacker needs one more exploit to build a full chain.
I agree with this - VPNs protect you from only the ends of the chain, while centralizing the middle, and it's rather foolish to think that any VPN construct will reliably blind traffic and identity from the VPN provider. Depending on your threat model this is a good thing or a bad thing overall.
However, this "privacy" goal is something that a huge number of VPN providers, including Google, claim as a goal and market heavily against, so it's fair to assess against it IHMO.
As for the second part, yeah, that's pentest reports in a nutshell. A few nuggets of information combined with checklist-satisfying irrelevant findings from automated tooling.
A VPN service that doesn't log should reliable be expected to protect you from dragnet style surveillance that is initiated after the fact. If the government asks google for everyone who searched for a term in a range of dates will return a list of IPs and times. Comcast may choose to happily connect your real identity when asked but a VPN provider that didn't log can honestly answer that they have no way to establish that.
At another level a vpn provider that doesn't operate in country can reliably refuse orders to surveil you in the future wherein orders don't rise to the level of obtaining international cooperation AND don't meet standards higher than the nonsensically low standards in say the US.
This wont be enough to protect your international criminal empire but might well provide reasonable assurance of privacy to concerned individuals. I'm sure the google one is good for something....
Perhaps keeping your ISP from chiding or blocking you for pirating music until that hole is plugged...or keeping people who access http websites over coffee shop wifi safe?
And they should be so worried, because of Google's apparent lack of respect for user privacy, which has them using, selling, or handing over data to whatever authorities and 3rd parties at anytime they were asked, feel like it, or could profit. From the history, trusting Google looks to be insanity.
I pay for Mullvad and also have Google One. I use Google One for times that I have to connect to an unknown WiFi network but don't care about if Google knows it is me. I use Mullvad when I want some confidence in not being tracked.
This is not what privacy primarily is about, though. Taking Cypher's choice is also not some profound path.
While privacy is indeed a measure protecting one against becoming a victim or a target of malicious intent. First and foremost, however, privacy determines who is in control and has power over you through (access to) knowledge related to you. It's a human right that shapes all aspects of any society, not just some best practice like locking one's door.
The problem is people don't think or care much about far away ills, that's why it is too easy for us to dismiss and normalize the degradation of our rights.
Google already has my personal information. Using my Google account while logged into Mullvad isn't a good idea cause then I leak that to Google and whoever else they share data with.
Because Mullvad allows for totally anonymous payment, and is thus preferred by the nefarious.
I assume Google only allows you to pay with a payment card as usual, and even getting a Google account requires a phone number now.
I use Mullvad all of the time. Some of their locations' public exit IPs are blocked for some/all services. Can't log in to HN from some of them, can't use Etsy at all from some of them, can't checkout on eBay from some of them, etc.
I guess that makes sense. I use Mullvad as well, and anecdotally it seemed to have a similar rate of blacklisted endpoints to Nord. I guess in Nord's case maybe its ubiquity is the problem.
The same reason why tor exit nodes are blocked/limited by services. You have the anonymity (if your opsec is good) and endless bandwith. So these will very likely be used for shady/illegal stuff. To do this with google or other providers would be not very smart, the majority of people will use these only for hiding your traffic from your isp, your local network or geo location spoofing and the percentage of suspicious activity from their IP ranges will be very small.
>The fundamental anonymity model Google have employed is that the VPN tunnel is authenticated using "blind tokens" which are signed by an authorization service "Zinc." The Zinc service validates OAuth credentials passed in from the client app to verify a user's subscription, then signs the blind token created by the client app to authorize the user's session with the actual VPN backend "Copper." Ostensibly, this will separate the user's Google identity from the VPN identity since the VPN service only knows that it got a valid, signed user token, not what user that token belongs to.
The fundamental anonymity model Google have employed is that the VPN tunnel is authenticated using "blind tokens" which are signed by an authorization service "Zinc." The Zinc service validates OAuth credentials passed in from the client app to verify a user's subscription, then signs the blind token created by the client app to authorize the user's session with the actual VPN backend "Copper." Ostensibly, this will separate the user's Google identity from the VPN identity since the VPN service only knows that it got a valid, signed user token, not what user that token belongs to.
Ultimately, as pointed out in the report, this is IMHO not that useful. Google could still trivially re-correlate traffic inside of the VPN service by using packet inspection combined with a crafted (or accidental!) plaintext sidechannel from an authenticated Google client application (unencrypted DNS requests to a special subdomain, port/IP knocking style requests to a specific list of IPs in a specific order, etc.).
Also, if there's timestamped logging in both the Zinc and Copper services, the attempt at blinding between the two sides of the system is also quite meaningless since the flow to Zinc and the flow to Copper could just be back-correlated back into a user identity using timing by a Google employee with access to logs.