Lets start from the beginning: the NSA "hack" became possible because Google (and its security team) made bad assumptions about the security of the connection between Google's data centers and did not encrypt the traffic. Basically, this is security 101: protect data at rest and protect data in flight. So, sorry but I think the better subject for discussion would be how badly Google screwed up, not how evil is NSA. M…
Google Security Team Member on NSA: "Fuck These Guys"
71–80 of 420 posts
Re: Google Security Team Member on NSA: "Fuck These Guys"
#72Appreciate Mike speaking up like this. We need more people within the industry to speak up. Not just hackers. (People within these companies are also hackers, but they have more effect when they speak because they are part of a company)
I agree, but I do wonder what is going to happen when people start speaking up to say something quite the opposite. "I don't speak for my employer, but I think the NSA is quite awesome and I don't mind that they've been listening to us at all." Or something to that effect. The clash might be interesting to watch.
Re: Google Security Team Member on NSA: "Fuck These Guys"
#73Earlier quoted context omitted.
Also, what kind of spy uses gmail? Sheesh. The kind that is trying to maintain cover as a non-spy so uses the same email services as everybody else.
Sure but only an idiot uses their personal email account for work, right? Especially if your work can get you killed.
Of course, that means the joke's on them, because the NSA was listening to everyone...
Re: Google Security Team Member on NSA: "Fuck These Guys"
#74Lets start from the beginning: the NSA "hack" became possible because Google (and its security team) made bad assumptions about the security of the connection between Google's data centers and did not encrypt the traffic. Basically, this is security 101: protect data at rest and protect data in flight. So, sorry but I think the better subject for discussion would be how badly Google screwed up, not how evil is NSA. M…
The assumption isn't bad - it's a private network line, not a public internet connection. Nobody else had access to that line, at least they weren't supposed to. Splicing a fiber line is a bit outside the scope of your random attacker. You can't blame Google for not anticipating a hostile break-in by the government. The discussion should absolutely, 100% be directed at the NSA here. To accept that a private network connection is open season for the government to tap is batshit insane.
> Moreover, it is not clear if other governments or criminals also had access to the users' data (e.g. in Google's data centers located outside of the US). So far Google did not produce any public post-mortem thus we have no clue how bad was the problem.
How is Google supposed to tell you if they themselves didn't know?
Although from the leaks it sounds like everyone is fucked thanks to the GCHQ and the NSA getting friendly with each other.
Re: Google Security Team Member on NSA: "Fuck These Guys"
#75Lets start from the beginning: the NSA "hack" became possible because Google (and its security team) made bad assumptions about the security of the connection between Google's data centers and did not encrypt the traffic. Basically, this is security 101: protect data at rest and protect data in flight. So, sorry but I think the better subject for discussion would be how badly Google screwed up, not how evil is NSA. M…
Would you still feel Google had screwed up if the way the US government got the data was to burglarize one of their datacenters and tap directly into the machines' CPUs and memory buses?
Basically, I think Google's decision to do not encrypt the traffic is a gross negligence and I would love to see how someone would sue Google for it.
Re: Google Security Team Member on NSA: "Fuck These Guys"
#76> "Bypassing that system is illegal for a good reason."
Yes, so is invasion of privacy. Yet Google has no problem breaking the law and violating civil rights for profit.
> "Unfortunately we live in a world where all too often, laws are for the little people."
Yeah, like tax laws and privacy laws...
If you want to get on this high horse, you shouldn't be working for Google.
Re: Google Security Team Member on NSA: "Fuck These Guys"
#77Lets start from the beginning: the NSA "hack" became possible because Google (and its security team) made bad assumptions about the security of the connection between Google's data centers and did not encrypt the traffic. Basically, this is security 101: protect data at rest and protect data in flight. So, sorry but I think the better subject for discussion would be how badly Google screwed up, not how evil is NSA. M…
I can't agree with that, this was on Google's on fiber connections between their own data centers, right? And no other company with multiple data centers encrypts all traffic between them, right? (maybe you'll find a small counterexample but no big one.) So I don't think this is "security 101".
Re: Google Security Team Member on NSA: "Fuck These Guys"
#78My feeling is that the NSA/GCHQ hack was arguably an unfortunate thing for them to do, although somewhat predictable, once one knows of the existence of the network topology vulnerability that was exploited. But presumably somewhere in Google someone knew about this possibility sometime back. I wonder whether there was an assumption that nobody would be clever enough to figure things out, or whether security engineer…
Re: Google Security Team Member on NSA: "Fuck These Guys"
#79Earlier quoted context omitted.
Why do people assume the Chinese government is not able to use similar techniques?
I would assume they use similar techniques within China and perhaps allied countries like North Korea and Cuba, but the US is performing wiretapping in at least the UK, Canada, Australia, and New Zealand. Also, how much non-Chinese Internet traffic passes through China?
I'm sure lots of botnets use China servers as well.
Re: Google Security Team Member on NSA: "Fuck These Guys"
#80Earlier quoted context omitted.
The RPC protocol is stated to be based on protocol buffers so the encoding is known. What you would need to do to reverse engineer it is coming up with matching message descriptions. But, even without that piece of the puzzle, reverse engineering a protocol that doesn't use encryption wouldn't be "extremely difficult". This is not an indication of an inside man. https://developers.google.com/protocol-buffers/docs/ove…
The only published information is how the values are encoded, not what is encoded (the specifications aren't transported together with the data) so to crack 1622 different protocols only involved in authorization according to the NSA slide is not such a small task, at least if they are interested in more than just recognizing e-mail addresses which can be found using regexps. And just counting the protocols proves th…
You're talking about the NSA here, an outfit which has cracked the cryptosystems of foreign governments in a variety of foreign languages, and even cracked a Russian one-time-pad that they had accidental;y used more than once.
I don't think it's very hard at all for them to reverse engineer RPC serialization that is not even encrypted if they can crack cryptosystems.