Google speeding up end-to-end crypto between data centers worldwide

http://arstechnica.com/tech-policy/2013/09/google-speeding-up-end-to-end-crypto-between-data-centers-worldwide/

by Suraj-Sun • 13 years ago

38 40 13 years ago

eksith• 13 years ago

I'm still quite astonished that (according to some of the comments) it's fairly standard that traffic between datacenters is not encrypted.

Granted we're talking about extremely large throughput, but I thought Google of all companies would have invested in routers capable of doing this or at least gone to the trouble of designing their own hardware that does it; since Google is no stranger to this already.

revelation• 13 years ago

Why would routers do this? IPSec didn't exactly take off (this weeks news reminded us why), so end-to-end encryption wouldn't really happen on their level.

That said, I certainly expected and assumed Google would already encrypt traffic between data centers. Whats the point of forcing HTTPS on gmail when you constantly backup my complete email repository across the world over unencrypted connections? In this new context, the statements on Prism ("we do not give them direct access!") certainly seem misleading. Right, you do not give them direct access, you just sync your databases over fibers that you know they have access to, without encrypting the data.

raldi2• 13 years ago

Whats the point of forcing HTTPS on gmail when you constantly backup my complete email repository across the world over unencrypted connections?

To protect users on questionable public WiFi, or traveling through a country known for spying on its telecommunications, or who might be using an ISP with untrustworthy employees, or working for a company with a nosy IT department.

Until recently, the USA wasn't generally considered part of that second category, and private leased lines were generally considered secure -- at Google and elsewhere -- for the same reason a LAN transmission within a datacenter is / was generally considered secure.

abcd_f3• 13 years ago

IPSec didn't exactly take off

Oh, jezus. Did you read it on the Internets?

IPsec (s is in lowercase) is the standard to securing L2 connectivity and it has been ubiquitously used for site-to-site and client-to-site connectivity for ages. In addition to several mature FOSS implementations, every network equipment vendor ships one. There is also a ton of client software - Windows supported it since Windows 2000, the SSH company (you know, the ssh creators) has been selling an IPsec Toolkit since as early as 1999, Cisco has a VPN client that is de-facto software in Cisco-based shops for remote workers, etc.

nimrody• 13 years ago

Mail messages may go through multiple relays. Even if they are encrypted between relays, all routing mailers see the message unencrypted.

Your only option to secure your mail messages is end-to-end encryption. Do you really trust Google or any other company more than you trust the NSA?

some_googler4• 13 years ago

What raidi and other said. But also, do not assume that we didn't encrypt any of the backend backbone transfers, or that some specific kind of information was exposed before -- for one thing, when we make inter-DC backups/replication of data that's already stored in encrypted form (you gmail folders and such), it's likely that we just ship this data around without bothering to decrypt and re-encrypt it, which would be wasteful and pointless. (I'm not a intimate with netops here, just making educated guesses like anybody could do.) Also there's some significant data that needs no encryption, e.g. the gobs of public youtube content that we have to mirror and cache in a thousand places.

We have tons of our own stuff moving through the same pipes (proprietary source code, all files in our corp network filesystems...), so it's our best interest to protect these. I suspect most of the unencrypted traffic is actually what the NSA would call "metadata" -- if valuable information can be mined from simple metadata like phone calls, I guess even better stuff can be derived from extremely rich RPCs/protobufs even if the core information was already in encrypted fields. Anyway the more comprehensive encryption support should turn our backbone into a wasteland for spooks.

philip1209• 13 years ago

Yes, this seems like a huge man-in-the-middle vulnerability.

tekacs• 13 years ago

In this context eavesdropping is probably far more likely than MITM.

Quite apart from MITM being an active attack only needed (ish) for manipulation of the transferred data, at the throughputs likely involved here and the fact that leased lines are used, MITM would probably provide far too much hassle for its worth.

Gusfoo_2• 13 years ago

These are private circuits between datacentres, and as such have always been in the "assumed secure" category.

INTPenis• 13 years ago

Agreed, I first thought the title said that Google was decreasing the key size of the crypto to speed up the traffic, and that the story was a negative one.

I work for TeliaSonera and I can tell you that it's very standard for us to use VPN connections between worldwide datacenters.

rdl4• 13 years ago

If Google comes up with a much more sane version of or alternative to IPsec, deployed on all their boxes, it would be an amazing improvement for the world.

toomuchtodo• 13 years ago

Especially if they integrated it with Chrome (a la VPN over SSL). If I have to pick between Google having all my traffic and the NSA, its an easy pick.

marcuspovey3• 13 years ago

Except of course, as we've learnt over the last few weeks, they're essentially one and the same thing.

You can't trust a third party with your data if you want it kept secure. Period.

abcd_f3• 13 years ago

What exactly don't you like about IPsec?

rdl4• 13 years ago

Lack of opportunistic encryption (in the style of Hugh Daniels Free S/WAN).

General complexity and baroqueness.

IKE and various implementations -- keying in general. True, keying is a hard problem, but I'd prefer a simple default which was secure against passive eavesdroppers, and then progressively better systems.

scrrr• 13 years ago

At this point everything they could come up with, would have the feature to be accessible by the NSA, don't you think?

hahainternet• 13 years ago

No?

rdl4• 13 years ago

No, since they don't fall under CALEA. It's possible Google Voice specific stuff would need CALEA access, but I'm sure they handle that at a higher level in the application.

Google needs this kind of stuff not to defend against just NSA but also every other intelligence agency out there. For 0.1% of the IC's annual budget, I could give a third-tier country (Belgium? Nigeria?) about 5% of NSA's capability. That, IMO, is the true risk here.

frank_boyd• 13 years ago

The timing suggests this is supposed to be a PR move. And a cheap/ridiculous one at that.

abcd_f3• 13 years ago

Don't know why you are downvoted, but it's clearly a damage control move.

raverbashing• 13 years ago

Damage control yes, but not necessarily external.

Google probably knows even though they're mostly in good terms, this may change.

I guess they got uncomfortable with people knowing too much already and don't trust too much

tytso• 13 years ago

If you were to actually read the article, you'll note that the project began _before_ the Snowden revelations started coming out.

pjc50• 13 years ago

This is _not_ end-to-end crypto, that would require users storing the keys to their own emails on their own systems. This is basically TLS on a giant scale but does not prevent email from being intercepted while "at rest" on a gmail server.

djim• 13 years ago

let's not pretend these emails are sitting in plaintext on google's servers though. they are "fragmented and obfuscated" at rest.

brokenparser• 13 years ago

Anyone who wants their mail to remain encrypted until it's read by the recipient should use GPG.

icebraining3• 13 years ago

The PGP encrypted emails I sent were very secure - no one ever read them!

Mordor• 13 years ago

It's all about protecting the data from non-US interests, Google has probably already given the keys to the NSA.

Google speeding up end-to-end crypto between data centers worldwide

Related Stories