Hacker News new | past | comments | ask | show | jobs | submit login

I upvoted this because I want it to kickstart a movement among companies, so everyone increases their security, end to end.

But at least on my part, this doesn't begin to "impress me". So far they're only talking about encrypting data between servers and they've also recently talked about encrypting Drive storage data (why wasn't it encrypted in the first place?!)

They need to implement OTR or some form of end to end encryption with PFS for Hangouts, and it would be nice if they at least gave the option to have encrypted calls and voice calls with ZRTP in Hangouts. The button should be right there and obvious for everyone who wants to use it. But I'm saying it's optional only because I'm not sure how it could impact what they're trying to do with Hangouts, and if ZRTP works with multiple people at once. But if they can do that, then it should be by default for everyone.

I'm also not sure exactly what kind of forward secrecy they are using for Google search - is it really a new key being generated per session - or is it like a few weeks? Because I think I read something about "a few weeks".

I think all SSL/TLS encryption is almost useless without PFS so everyone should use it, when we're talking about the government. A single order from them and they could get your key for everything. That's just completely unacceptable! So every service should be using PFS.

If I were them I'd also seriously evaluate whether RSA 2048 bits is enough, and if there's any doubt that it is, then they should move to more bits, or if the whole RSA algorithm is in danger, then they should be looking for alternatives quickly.

When Google and others start doing that, then I will begin to have some trust in them again. All of these press releases so far, and the lawsuit to fight to only disclose (not stop) the mass requests aren't fooling me, and I hope they aren't fooling many others either.

Until then I'll be on the lookout for any new great service that promises that type of security, and I'll switch to them as soon as they're available, and recommend others to do it, too, both offline and online.

I hope Google and Microsoft and others aren't thinking that because I haven't "ragequit" their services yet, it means the whole NSA thing doesn't bother me. It just means I'm anxiously waiting for the alternatives to appear - which will appear. There is a crypto war (again), and I do believe the security community will win again, so it's only a matter of time.




</dev/null openssl s_client -showcerts -connect www.google.com:443

Includes in the output: Server public key is 2048 bit ... Protocol : TLSv1.2 Cipher : ECDHE-RSA-AES128-GCM-SHA256 (ie: not RC4, as long as your client supports non RC4 ciphers, uses ECDHE for PFS) and: TLS session ticket lifetime hint: 100800 (seconds) (session keys are discarded by the client every 1d4h, so presumably the server rotates them every 24 hours or so (4hrs to allow for clock skew, I assume, or to allow for the fact that people might be slightly late on something they check every 24 hours (eg when the wake up each morning)))

Nobody is going to make the change from 1024 bit keys to something else without first verifying that the new bit length is "secure enough" for a reasonable enough time (if nothing else, you don't want to have to go through the expense of the process of getting everything upgraded more often than you have to). Although you're right, it would be nice if they published their reasoning.

I don't know how to verify the security of hangouts. Looking at the webrtc standard, it doesn't appear to support encryption. There is also a lot of opposition to standardising encryption for webRTC because of "DRM" concerns. So I guess it's probably not encrypted, but don't quote me on that.

Disclaimer: I'm a Google employee.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: