Ask Slashdot: Has Gmail's SSL Certificate Changed, How Would We Know? 233
An anonymous reader writes "Recent reports from around the net suggest that SSL certificate chain for gmail has either changed this week, or has been widely compromised. Even less-than-obvious places to look for information, such as Google's Online Security Blog, are silent. The problem isn't specific to gmail, of course, which leads me to ask: What is the canonically-accepted out-of-band means by which a new SSL certificate's fingerprint may be communicated and/or verified by end users?"
Revocation (Score:4, Insightful)
Google can easily revoke certificates. They can even install what ever they want on my computer as a replacement for google chome with their automatic background updates. Don't worry about it, they own your computer and will take care of it for you.
Why do we trust SSL? (Score:5, Insightful)
That made me wonder about something at work recently. All the machines at work are owned by the organization. It would be trivial for them to add their own trusted signing authority, so they could MITM every SSL web site. It wouldn't be terribly hard to auto-generate "valid" SSL certs, and have it tagged as whoever you want the signing authority to be. All they'd have to do is add their own cert, in this case named "GeoTrust Global CA", and they'd have perfect control. To do it perfectly, they'd just need to query the site you're going to, and match up the signer's CN and sign the new fake cert, and you wouldn't know the difference. Who tracks the fingerprint of every cert for every site they go to? Well, I'm sure in this crowd, a few do.
It's good for network security, as they can pump everything out through a common proxy (or cluster of proxies) and inspect all the traffic for malicious intent (malware inbound, or organization secrets outbound). It's not good for privacy, if you were to visit your bank, gmail, etc.
As far as that goes, there are an awful lot of "trusted" signing authorities that come with any browser. I know we should probably trust them, because the authors of the browsers trust them. There's no really good reason to do so, other than if you don't, all SSL sites will warn that they may not be trustworthy.
I was considering a while back, how would *I* become my own signing authority, to be trusted by all browsers. I didn't find a good answer. An intermediary cert would solve it, but I didn't find how to accomplish that. Like, who do I throw money at to get one. Getting added to all browsers would be another even larger headache.
My thought on it was, technically it isn't hard to do. I could spend a day writing a very nice site, that would verify ownership and make whatever cert for the domain. Why can't I (or whoever) offer $5/yr, or $50/10yr single domain or wildcard cert? The code and infrastructure isn't very heavy.
Needless to say, since you haven't seen JWSmythe's Cheap Certs available, it never happened.
Re:Why do we trust SSL? (Score:5, Insightful)
It's not merely possible. It's deployed, off the shelf technology. Not necessarily common, but many companies that do it see it as a cost reduction of more effective proxy usage, rather than anything nefarious.
That said, the way SSL is handled by the browsers is absurd. Not notifying on changes compared to a cached fingerprint, and giving huge warnings on self certification are blatantly obvious errors in judgement. Conflating encryption and identity in one awkward mess has probably done more harm than good. IMHO, it should work a bit like SSH, where the first time you go to a website, you see a little unobtrusive popup saying, "This connection is encrypted. The site claims to be "Foo corp." The identity is (not verified || vouched for by the following : CA Bar, CA Baz). " Adding certs for CA's should be really obvious, not obscure black magic. So, if you attend University of Foo, you can add their self signed cert and all the servers on campus that you access over https will show up as signed by U of Foo. Untrusting certs should also be obvious in the UI. Some web of trust model should be available. If you ever get something other than what was cached, you should see the details side by side.
As is, the system is mostly useless. It fails utterly at identification. And, it scares people away from using encryption on self signed certs. (As if that were somehow worse than operating entirely in plain text...)
Re:Why do we trust SSL? (Score:5, Insightful)
The current implementation in web browsers was designed by people who couldn't tell the difference between authentication and authorization.
The reason why this paradigm has persisted is unknown, but the answer for you may vary depending on which end of the paranoia spectrum you're on. If you're on the Hanlon side, you'd say that the code is too old, and trying to change it would require too much work, so nobody really bothered. If you're on the conspiracy nut side, you'd say that the NSA and their agents are actively trying to keep these types of changes from going in.
This problem with SSL certs has been known for the better part of 10 years now, and has been in focus for at least the past 5-7 years. Why Firefox could go through 30 revisions in that time and keep this behavior while changing practically everything else is quite the mystery. I'd say the same about Opera or IE, but they're closed-source and hence could not be subjected to the same standards of scrutiny. In fact, if there ever was a failure to the OSS model security-wise, Firefox's 1990's method of handling certs would be a prime example.
Re:Why do we trust SSL? (Score:5, Insightful)
That made me wonder about something at work recently. All the machines at work are owned by the organization. It would be trivial for them to add their own trusted signing authority, so they could MITM every SSL web site.
You just described for every enterprise firewall/scanner solution works
Re:Why do we trust SSL? (Score:4, Insightful)
All the machines at work are owned by the organization.
You can stop right there. If the organization owns the machine, you have no expectation of privacy, legally or otherwise. From a technical perspective, if anyone other then you has administrative access to the machine, you should have no expectation of privacy. If you let malware gain administrative access, same story.
Re:Why do we trust SSL? (Score:4, Insightful)
As far as that goes, there are an awful lot of "trusted" signing authorities that come with any browser. I know we should probably trust them, because the authors of the browsers trust them. There's no really good reason to do so, other than if you don't, all SSL sites will warn that they may not be trustworthy.
The one and only reason you can trust them, is because if their trust is broken, the company is out of business really soon. Prime example of course is DigiNotar [wikipedia.org] which was declared bankrupt a month after a breach of its certificates came to light.
As soon as such a breach happens, browser vendors very quickly remove the offending certificate and push out a new update. Anyone using certificates from that vendor is forced to change almost instantly or people have issues accessing their web sites.
And that's the one and only reason you can trust them - and why that trust is fairly worthwhile.
Re:Why do we trust SSL? (Score:5, Insightful)
That said, the way SSL is handled by the browsers is absurd. Not notifying on changes compared to a cached fingerprint, and giving huge warnings on self certification are blatantly obvious errors in judgement. Conflating encryption and identity in one awkward mess has probably done more harm than good. IMHO, it should work a bit like SSH, where the first time you go to a website, you see a little unobtrusive popup saying, "This connection is encrypted.
Yep, completely absurd. Go into your browser security certs and notice that the Chinese root cert "CNNIC" is installed. That means any of those trusted roots can simply create an SSL cert for Google.com and unless you're manually verifying the cert chain every time you connect, you won't know you've been MITM'd -- Big green bar and everything... I like your idea about making things more like SSH, but I'm afraid users will just click through it without reading any warnings anyway. Oh, if only PKI hadn't been invented! Why, then we could just use some session salt nonce HMAC'd with our pre-shared key (password) to set up a connection that no man in the middle can intercept (since they don't have our password, or password hash, etc pre-shared secret). I can do this in JavaScript, (or more favorably with a plugin), but we really need the browsers to just prompt us for the credential to our bank or email BEFORE it ever makes the request or displays the password entry form -- The request comes in, says : "I'm user X, here's my nonce, gimme your nonce server, and we can start encrypting data with HMAC( PW, N1 ) as the key". Public key crypto should have only ever been used at account creation (the only time you need to send the pre-shared secret). I've always known the entire security community was full of morons since they didn't bitch about the foolishness of SSL PKI loudly enough -- Oh, and for the "but muh passwerds!" folks: Built in password manager. Different random password for every site, master password to unlock the keystore. This is 2013 and since it's not standard addition to browsers, I'm not sure folks like you or me CAN do anything about it if we haven't already.
Additionally: People who searched for "Tinfoil Origami" also clicked on Convergence. [convergence.io]
Re:Revocation --- or Redundancy? (Score:1, Insightful)
And for more security, we can do *THREE* certificates. Count them! *THREE* for additional security.
Super secure sites like banks can do *FOUR* certificates. If any one of the *FOUR* certificates break, then we know we're attacked! Even more secure if those *FOUR* certificates come through 4 different ways...
Are you really suggesting that?! Do you even know how PKI works?
Re:Revocation (Score:1, Insightful)
Hairy...so you turned into a full-fledged Microsoft shill now?
I (and a few others) knew you were a Microsoft shill from the beginning. But most of the time you were quite subtle and it was difficult to pin you down. But it looks like your account is converging with the other SharkLaser type accounts now. Did you join Burson marseller?
Re:Revocation --- or Redundancy? (Score:4, Insightful)
It sounds like he does indeed know how it works very well. It's actually a great idea, which is why PGP defaults (I think) to requiring about three "moderately trusted" CAs to agree, in order to confirm an identity. Upgrading from our current luddite stuff to gleaming new 1991 tech would be fantastic, and is pretty warranted, when you think about how silly our current situation is. Treating something like Verisign as a fully trusted introducer? ha! They're not that trustworthy, but they're not useless, either. PGP's concept of differing degrees of trust, gets it about right and would be a huge step forward.
Re:Revocation --- or Redundancy? (Score:5, Insightful)
Now think it through. If Verisign is owned by the NSA, and a Russian CA is owned by FSB, and a Chinese CA is owned by that government, and all three of these compromised CAs agree on a cert, what does it mean?
It means the cert is probably accurate, or about as accurate as you can possibly get, without going over to the server certing it yourself. If those three parties are conspiring to disrupt your Amazon order, then I'm afraid you're not going to get your package, no matter what crypto you use. :-)
Re:Revocation --- or Redundancy? (Score:4, Insightful)
There are situations where thinking you're secure when you're not is worse than knowing you're not secure.