13 ms·

VPN by Google One security assessment

189 points by campuscodi 4y ago

bri3d 4y ago
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.
- jeffbee 4y ago
  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.
  - bri3d 4y ago
    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.
    - michaelmrose 4y ago
      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?
  - Izmaki 4y ago
    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
    - jeffbee 4y ago
      Yeah, I love the finding that an attacker in possession of your unlocked iOS device could discover your email address. Big news!
    - bri3d 4y ago
      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.
      - nibbleshifter 4y ago
        They are SOP/standard findings. You work through a checklist for arse covering, which generates a lot of meaningless/low value findings. If you omit a lot of those issues, the client thinks you didn't do the work sufficiently. If you put in too many of those findings, the report gets made fun of for containing "filler".
  - dfc 4y ago
    What does "9th-circle privacy adversary" mean?
    - xnx 4y ago
      Reference to Dante's Inferno and the 9th circle of hell. I believe it's away of saying "very very bad" advertisers here.
  - zoklet-enjoyer 4y ago
    Yeah, I just use it so my employer can't see what websites I'm browsing
    - clay-dreidels 4y ago
      You should use a second cheap computer for that.
      - zoklet-enjoyer 4y ago
        That would be impractical
        clay-dreidels 4y ago
  - anon84873628 4y ago
    I assumed people are mostly worried about Google being compelled to de-anonymize the traffic (for a government).
    - Tozen 4y ago
      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. https://www.datacenterdynamics.com/en/news/google-handed-over-user-data-to-the-hong-kong-government/ https://www.datacenterdynamics.com/en/news/google-handed-ove... https://www.forbes.com/sites/andygreenberg/2011/06/27/google-hands-over-user-data-for-94-of-law-enforcement-requests/?sh=47cbfd6f2f89 https://www.forbes.com/sites/andygreenberg/2011/06/27/google... https://www.theguardian.com/technology/2020/aug/17/google-giving-user-data-authorities-documents-reveal https://www.theguardian.com/technology/2020/aug/17/google-gi... https://www.dailystar.co.uk/tech/news/google-hand-over-video-footage-27591616 https://www.dailystar.co.uk/tech/news/google-hand-over-video...
- encryptluks2 4y ago
  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.
  - chiefalchemist 4y ago
    Why not Mullvad all the time?
    - worldsavior 4y ago
      Probably to separate identities.
    - jonas-w 4y ago
      Because mullvad exit IP's may be more suspicious than other vpn providers IP addresses.
      - eightails 4y ago
        I'm curious, why would that be the case?
        sneak 4y ago
        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.
        eightails 4y ago
        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.
- rasz 4y ago
  >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 video form for those not keeping up: https://www.youtube.com/watch?v=y8OnoxKotPQ https://www.youtube.com/watch?v=y8OnoxKotPQ
- World177 4y ago
  > 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] [1] https://one.google.com/about/vpn/howitworks https://one.google.com/about/vpn/howitworks [2] https://github.com/tornadocash/tornado-core https://github.com/tornadocash/tornado-core
  - jmole 4y ago
    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?
- skybrian 4y ago
  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.
  - yakak 4y ago
    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.
Izmaki 4y ago
Writing that report must have been hell with - I bet - all the attention from Sr. management.
- sillysaurusx 4y ago
  The actual process of writing those reports is generally pretty laid back. It was hell mostly because it consumes all your time. Only about 50% of your time is spent hacking, if that. The rest is poured into that damn report. It goes through multiple rounds of review, and every small detail is caught and corrected. Which is how it should be. It’s just the opposite of fun. The report is literally the product. The implications of that didn’t sink in until a few months on the job.
  - rfoo 4y ago
    Not to mention you HAVE to put some really lame recommendation here. "Application binary is not obfuscated", seriously, wtf?
    - hsnewman 4y ago
      Since it's not obfuscated the binary can be decompileed easily and any coding issues can be identified more easily.
      - saagarjha 4y ago
        This is a good thing.
      - deleted 4y ago
        [deleted]
    - Spooky23 4y ago
      The point of an assessment like this is to identify potential risks. That one is categorized as “informational”, and isn’t a defect. These types of recommendations are useful in context. You may have a moderate finding or series of findings that in context are more significant because of some informational finding.
svet_0 4y ago
Really boring report, nothing of real essence. Either G's product is bullet-proof or the research quality from NCC has deteriorated.
- nibbleshifter 4y ago
  The quality of work from NCC has always been really inconsistent. It also depends on "which part of NCC" you were looking at.
  - Aachen 4y ago
    > It also depends on "which part of NCC" you were looking at. For the security consultancy part of NCC, it's not like I catalogue and re-check their findings so probably this is biased, but the only report I remember is the one from Keybase where they failed to notice that the claimed end to end encryption trusts the server to deliver the right keys. This was tested together with some other people on HN and packet capturing (one theory was that it checks the third-party websites like reddit/HN/... proofs, and that it's user error if you don't have any, but no, not even that). I was really surprised by both Keybase getting something so fundamental wrong (they claim some blockchain magic verification which you can do on the command line, but the app doesn't have a blockchain client and no manual fallback either, so it's never verifying anything and instead fully trusts the centralized Keybase-operated proprietary servers) and by NCC not noticing this problem. Someone I knew from the security stackexchange site and whom I admire greatly took part in the audit, but of course they never replied (not even declining to comment) when I emailed them with a question about how this verification works (at that point, I still felt like I must be missing something so this email wasn't phrased accusatorily). I don't have a bad impression of NCC in general and we all make mistakes, but yeah that's the example that stuck in my mind.
    - nibbleshifter 4y ago
      My experience with them has been both knowing a large number of their consultants at certain locations, and reading the reports they issue for network and webapp pentests. Work quality on those was a real mixed bag, some was terrible, some was excellent. It didn't leave me with much faith in their QA process. Similar experiences with other larger consultancies (MWR - now FSecure, etc).
jokowueu 4y ago
I hope they audit outline next
xnx 4y ago
Google One VPN is a big deal, and potentially as big a nightmare for shady data brokers as the iOS cookie apocalypse was for Facebook and others. Google One was available to paid subscribers on Android, then on Windows, and Mac. Now some Pixel owners can use it. Imagine if they turn it on for all Chrome OS users, or all Chrome mobile users, or all Chrome users period. You can have your suspicions about Google, but I'd trust them over any other tech company or VPN provider.
- WanderPanda 4y ago
  Can you elaborate why you trust them over Apple?
  - xnx 4y ago
    Probably a tie with Apple. I like that Apple isn't trying to sell my attention (yet), but I do prefer the higher level of openness from Google (Android, Chrome, open source contributions, etc.)
    - brodock 4y ago
      Apple have their ads business already, it's a matter of time until profits from that business become big enough that shareholders demand changes. You can't have and Ads business and defend privacy at the same time
  - dathinab 4y ago
    Maybe due to Apple acts in/wrt. China. People somehow end up thinking Apple cares deeply about their private but AFIK Apple only cares about privacy because it makes them money. Or more specifically the image it creates helps them in selling phones.But the moment the _long term_ cost outweighs the benefits they also have shown to bail. (I highlighted long terms because there had been case where short term it was more expensive because it e.g. involved legal cases, but especially this legal cases are a grate image profit form them as people will use it like "don't worry see they didn't even brake their security to help the police with <insert arrested very bad person>"). Now that doesn't mean Apple is bad to some degree it's a win win for the user: They get better privacy and Apple gets more users. But it doesn't mean you can fully trust Apple (or IMHO any Company).
jmclnx 4y ago
> “With VPN by Google One, we will never use the VPN connection to track, log, or *sell* your online activity. This can be expanded to: "And by using Google VPN, only Google can see your search history and WEB Sites you visit. Apple will not see anything they do not need to see." :)
quotemstr 4y ago
Some of the findings are ridiculous. To highlight the lack of binary obfuscation as a threat (albeit a "low-severity" one) is absurd. Kerckhoff's principle [1] applies. Security through obscurity (or obfuscation) is no security at all. To highlight the lack of binary obfuscation (which, in its maximal form, would be the client being open source software) as a security threat is the "demand" for security vulnerabilities exceeding the "supply". If you, as a business, make money from identifying security vulnerabilities in applications, then you have every incentive to invent vulnerabilities where not exist. And if you're a client of such a service, then no matter how conscientious you are, no matter how much attention you pay to security, someone, somewhere, will be able to claim that he's discovered a vulnerability if he's able to make arbitrarily hostile assumptions about the underlying platform. In the limit: "Attack: Program fails to defend against an attack in which Intel specially and secretly recognizes this program's machine code and sends the contents of its memory space to the NSA. Recommendation: Program ceases to exist.". Give me a break! [1] https://en.wikipedia.org/wiki/Kerckhoffs%27s_principle https://en.wikipedia.org/wiki/Kerckhoffs%27s_principle
- smoldesu 4y ago
  If binary obfuscation is a threat, then every iPhone and Android handset ships with a pretty broken threat model. I don't disagree with what you're saying, but binary fuzzing is pretty much par for the course on these matters.
  - quotemstr 4y ago
    Huh? The system libraries of Android are not especially obfuscated
- deleted 4y ago
  [deleted]
- BeefWellington 4y ago
  To highlight the lack of binary obfuscation as a threat (albeit a "low-severity" one) is absurd. Kerckhoff's principle [1] applies. The report doesn't call lack of binary obfuscation a "low-severity" threat. They mention it as an informational finding. Informational is not Low severity and the rest of your rant seems based on this misunderstanding. You're not wrong in the general case about pentest firms having an incentive to make severity up; you're just wrong about that applying to this particular case.
oars 4y ago
What is Google's long term strategy with this product? Or will it be another thing they deprecate in a few years...
SXX 4y ago
I guess it would be super easy to verify whatever Google VPN have any privacy in it at all. Just start using their VPN to agressively parse Google own services and look if it get's your VPN account banned.
752963e64 4y ago
javajosh 4y ago
Starting on page 13, where they talk about the broadcast receiver issues, the report mentions "tiktok libraries" several times. What's going on there? Is Google's VPN solution dependent on tiktok in some way?
- ywoski 4y ago
  TikTok is the name of Google's internal (and convoluted) framework for first party Android apps. They have some internal libraries developers are supposed to use when handling intents that prevent common mistakes developers might make.

189 points by campuscodi 4y ago

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.

jeffbee 4y ago
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.
- bri3d 4y ago
  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.
  - michaelmrose 4y ago
    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?
- Izmaki 4y ago
  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
  - jeffbee 4y ago
    Yeah, I love the finding that an attacker in possession of your unlocked iOS device could discover your email address. Big news!
  - bri3d 4y ago
    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.
    - nibbleshifter 4y ago
      They are SOP/standard findings. You work through a checklist for arse covering, which generates a lot of meaningless/low value findings. If you omit a lot of those issues, the client thinks you didn't do the work sufficiently. If you put in too many of those findings, the report gets made fun of for containing "filler".
- dfc 4y ago
  What does "9th-circle privacy adversary" mean?
  - xnx 4y ago
    Reference to Dante's Inferno and the 9th circle of hell. I believe it's away of saying "very very bad" advertisers here.
- zoklet-enjoyer 4y ago
  Yeah, I just use it so my employer can't see what websites I'm browsing
  - clay-dreidels 4y ago
    You should use a second cheap computer for that.
    - zoklet-enjoyer 4y ago
      That would be impractical
      - clay-dreidels 4y ago
- anon84873628 4y ago
  I assumed people are mostly worried about Google being compelled to de-anonymize the traffic (for a government).
  - Tozen 4y ago
    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. https://www.datacenterdynamics.com/en/news/google-handed-over-user-data-to-the-hong-kong-government/ https://www.datacenterdynamics.com/en/news/google-handed-ove... https://www.forbes.com/sites/andygreenberg/2011/06/27/google-hands-over-user-data-for-94-of-law-enforcement-requests/?sh=47cbfd6f2f89 https://www.forbes.com/sites/andygreenberg/2011/06/27/google... https://www.theguardian.com/technology/2020/aug/17/google-giving-user-data-authorities-documents-reveal https://www.theguardian.com/technology/2020/aug/17/google-gi... https://www.dailystar.co.uk/tech/news/google-hand-over-video-footage-27591616 https://www.dailystar.co.uk/tech/news/google-hand-over-video...
encryptluks2 4y ago
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.
- chiefalchemist 4y ago
  Why not Mullvad all the time?
  - worldsavior 4y ago
    Probably to separate identities.
  - jonas-w 4y ago
    Because mullvad exit IP's may be more suspicious than other vpn providers IP addresses.
    - eightails 4y ago
      I'm curious, why would that be the case?
      - sneak 4y ago
        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.
        eightails 4y ago
        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.
rasz 4y ago
>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 video form for those not keeping up: https://www.youtube.com/watch?v=y8OnoxKotPQ https://www.youtube.com/watch?v=y8OnoxKotPQ
World177 4y ago
> 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] [1] https://one.google.com/about/vpn/howitworks https://one.google.com/about/vpn/howitworks [2] https://github.com/tornadocash/tornado-core https://github.com/tornadocash/tornado-core
- jmole 4y ago
  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?
skybrian 4y ago
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.
- yakak 4y ago
  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.

Izmaki 4y ago

Writing that report must have been hell with - I bet - all the attention from Sr. management.

sillysaurusx 4y ago
The actual process of writing those reports is generally pretty laid back. It was hell mostly because it consumes all your time. Only about 50% of your time is spent hacking, if that. The rest is poured into that damn report. It goes through multiple rounds of review, and every small detail is caught and corrected. Which is how it should be. It’s just the opposite of fun. The report is literally the product. The implications of that didn’t sink in until a few months on the job.
- rfoo 4y ago
  Not to mention you HAVE to put some really lame recommendation here. "Application binary is not obfuscated", seriously, wtf?
  - hsnewman 4y ago
    Since it's not obfuscated the binary can be decompileed easily and any coding issues can be identified more easily.
    - saagarjha 4y ago
      This is a good thing.
    - deleted 4y ago
      [deleted]
  - Spooky23 4y ago
    The point of an assessment like this is to identify potential risks. That one is categorized as “informational”, and isn’t a defect. These types of recommendations are useful in context. You may have a moderate finding or series of findings that in context are more significant because of some informational finding.

svet_0 4y ago

Really boring report, nothing of real essence. Either G's product is bullet-proof or the research quality from NCC has deteriorated.

nibbleshifter 4y ago
The quality of work from NCC has always been really inconsistent. It also depends on "which part of NCC" you were looking at.
- Aachen 4y ago
  > It also depends on "which part of NCC" you were looking at. For the security consultancy part of NCC, it's not like I catalogue and re-check their findings so probably this is biased, but the only report I remember is the one from Keybase where they failed to notice that the claimed end to end encryption trusts the server to deliver the right keys. This was tested together with some other people on HN and packet capturing (one theory was that it checks the third-party websites like reddit/HN/... proofs, and that it's user error if you don't have any, but no, not even that). I was really surprised by both Keybase getting something so fundamental wrong (they claim some blockchain magic verification which you can do on the command line, but the app doesn't have a blockchain client and no manual fallback either, so it's never verifying anything and instead fully trusts the centralized Keybase-operated proprietary servers) and by NCC not noticing this problem. Someone I knew from the security stackexchange site and whom I admire greatly took part in the audit, but of course they never replied (not even declining to comment) when I emailed them with a question about how this verification works (at that point, I still felt like I must be missing something so this email wasn't phrased accusatorily). I don't have a bad impression of NCC in general and we all make mistakes, but yeah that's the example that stuck in my mind.
  - nibbleshifter 4y ago
    My experience with them has been both knowing a large number of their consultants at certain locations, and reading the reports they issue for network and webapp pentests. Work quality on those was a real mixed bag, some was terrible, some was excellent. It didn't leave me with much faith in their QA process. Similar experiences with other larger consultancies (MWR - now FSecure, etc).

jokowueu 4y ago

I hope they audit outline next

xnx 4y ago

Google One VPN is a big deal, and potentially as big a nightmare for shady data brokers as the iOS cookie apocalypse was for Facebook and others. Google One was available to paid subscribers on Android, then on Windows, and Mac. Now some Pixel owners can use it. Imagine if they turn it on for all Chrome OS users, or all Chrome mobile users, or all Chrome users period. You can have your suspicions about Google, but I'd trust them over any other tech company or VPN provider.

WanderPanda 4y ago
Can you elaborate why you trust them over Apple?
- xnx 4y ago
  Probably a tie with Apple. I like that Apple isn't trying to sell my attention (yet), but I do prefer the higher level of openness from Google (Android, Chrome, open source contributions, etc.)
  - brodock 4y ago
    Apple have their ads business already, it's a matter of time until profits from that business become big enough that shareholders demand changes. You can't have and Ads business and defend privacy at the same time
- dathinab 4y ago
  Maybe due to Apple acts in/wrt. China. People somehow end up thinking Apple cares deeply about their private but AFIK Apple only cares about privacy because it makes them money. Or more specifically the image it creates helps them in selling phones.But the moment the _long term_ cost outweighs the benefits they also have shown to bail. (I highlighted long terms because there had been case where short term it was more expensive because it e.g. involved legal cases, but especially this legal cases are a grate image profit form them as people will use it like "don't worry see they didn't even brake their security to help the police with <insert arrested very bad person>"). Now that doesn't mean Apple is bad to some degree it's a win win for the user: They get better privacy and Apple gets more users. But it doesn't mean you can fully trust Apple (or IMHO any Company).

jmclnx 4y ago

> “With VPN by Google One, we will never use the VPN connection to track, log, or *sell* your online activity. This can be expanded to: "And by using Google VPN, only Google can see your search history and WEB Sites you visit. Apple will not see anything they do not need to see." :)

quotemstr 4y ago

Some of the findings are ridiculous. To highlight the lack of binary obfuscation as a threat (albeit a "low-severity" one) is absurd. Kerckhoff's principle [1] applies. Security through obscurity (or obfuscation) is no security at all. To highlight the lack of binary obfuscation (which, in its maximal form, would be the client being open source software) as a security threat is the "demand" for security vulnerabilities exceeding the "supply". If you, as a business, make money from identifying security vulnerabilities in applications, then you have every incentive to invent vulnerabilities where not exist. And if you're a client of such a service, then no matter how conscientious you are, no matter how much attention you pay to security, someone, somewhere, will be able to claim that he's discovered a vulnerability if he's able to make arbitrarily hostile assumptions about the underlying platform. In the limit: "Attack: Program fails to defend against an attack in which Intel specially and secretly recognizes this program's machine code and sends the contents of its memory space to the NSA. Recommendation: Program ceases to exist.". Give me a break! [1] https://en.wikipedia.org/wiki/Kerckhoffs%27s_principle https://en.wikipedia.org/wiki/Kerckhoffs%27s_principle

smoldesu 4y ago
If binary obfuscation is a threat, then every iPhone and Android handset ships with a pretty broken threat model. I don't disagree with what you're saying, but binary fuzzing is pretty much par for the course on these matters.
- quotemstr 4y ago
  Huh? The system libraries of Android are not especially obfuscated
deleted 4y ago
[deleted]
BeefWellington 4y ago
To highlight the lack of binary obfuscation as a threat (albeit a "low-severity" one) is absurd. Kerckhoff's principle [1] applies. The report doesn't call lack of binary obfuscation a "low-severity" threat. They mention it as an informational finding. Informational is not Low severity and the rest of your rant seems based on this misunderstanding. You're not wrong in the general case about pentest firms having an incentive to make severity up; you're just wrong about that applying to this particular case.

oars 4y ago

What is Google's long term strategy with this product? Or will it be another thing they deprecate in a few years...

SXX 4y ago

I guess it would be super easy to verify whatever Google VPN have any privacy in it at all. Just start using their VPN to agressively parse Google own services and look if it get's your VPN account banned.

752963e64 4y ago

javajosh 4y ago

Starting on page 13, where they talk about the broadcast receiver issues, the report mentions "tiktok libraries" several times. What's going on there? Is Google's VPN solution dependent on tiktok in some way?

ywoski 4y ago
TikTok is the name of Google's internal (and convoluted) framework for first party Android apps. They have some internal libraries developers are supposed to use when handling intents that prevent common mistakes developers might make.