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?"
What happened to certificate stapling? (Score:5, Interesting)
A few months ago, Google removed the ability in Chrome to staple a TLS/SSL certificate to your DNSSEC-signed DNS records: https://www.imperialviolet.org/2011/06/16/dnssecchrome.html [imperialviolet.org]
It was finally a way to get an HTTPS secured website without needing to go to a CA. And they removed it.
I just thought they were being incompetent as they usually were, but now I can't help but wonder if the NSA got on their backs about not being able to sign their own replacement certificate...
Revocation --- or Redundancy? (Score:5, Interesting)
It's just like any other single-point-of-failure in your network. You probably work with two telcom companies to make sure your website and/or company has network access. Why shouldn't you do the same for certificates. Buy one from a US CA, one from a Russian one, and one from a Chinese one, and if browsers could check to make sure *all* (or two out of the three, whatever) validate, unless they collude you should be pretty safe.
Even better if one of those can be a self-signed one. You can even exchange those keys over normal boring https, and then unless your commercial CA was already hacked at the time you distribute your self-signed one, your self-signed one will protect against your commercial CA being hacked in the future.
Twitter, too (Score:5, Interesting)
Another one that Certificate Patrol has flagged inthe past week is *.twimg.com, which appears to be a mess of certs from different CAs.
One subdomain ( s0 ) has switched from a DigiCert EV wildcard cert to a Verisign per-subdomain cert.
Another has gone from Verisign to Comodo.
Annoyingly twimg.com seems to be embedded across the Web...
I've been rejecting them all, given that Twitter provide no information on their site as to whether this was a planned change.
Re:Revocation --- or Redundancy? (Score:4, Interesting)
These are similar thoughts to my own. It needs to be about a web of trust, and it might just work.
If more parties are able to come along and say "I trust all these authorities" when it comes to doing business with me, this is the paradigm shift. I don't believe that there is *an* independent authority, I believe we should elect to allow *multiple* authorities to rate the trustworthiness of a certificate.
At the moment, outside of high-end corporate who roll their own, it is the operating system provider making that trust decision for all of us in their selection of root authorities. Now Microsoft, Google and Apple are all on the PRISM slides, and Linux is probably compromised in its own way - not one of them do I want to be the sole gatekeeper of my trust.
So, I believe that the 1st group that should be brought into this system are the banks. This is the group that has the most to lose financially, if you're the victim of fraud. Specifically *your* SSL, should be vouched for by *your* bank - with the condition that the online fraud protection on your bank account is only effective, if you were entering your card details in an SSL session they vouched for.
Now I see a future where we all allow multiple people to vouch for the goodness of certificates and authorities (I think this extends to public keys too) - particularly our social network. Anyone we trust to vouch may approve or *disapprove* any cert. Any time we do anything requiring crypto trust, we should be able to see how all the people we trust feel about it. I have a number of friends I'd really trust to always do a secure key-exchange; I'd boost their scores. Beyond that, the wisdom of crowds is a not a bad fallback.
We have to understand that trust is on an analogue scale. For many things it's fine that we don't have close to 5x 9s of trust. But when we do need to be really certain of who's on the other end, we should be able to push into our social network and see who will vouch for the other parties public key / certificate.
Re:Why do we trust SSL? (Score:3, Interesting)
Forge the CA so you can forge the certificates to do a man in the middle, its trivial. I've done it on multiple occasions at work in order to facilitate sniffing passwords to migrate users to different a new service (say from office365 to gmail without getting everyones passwords by asking).
You only know the thumbprint doesn't match if you check it and manually record it. Your browser's checks are being processed correctly via the forged certs.
I sign our MITM certs with our domain CA, its clear that we're doing it ... if you bother to look. I'm not trying to hide it, just accomplish part of my job. Being that we're on an ActiveDirectory domain with a certificate authority, the domain cert is automatically deployed to all the windows domain PCs, all I have to do is have the domain CA sign certs for my use, and all the PCs trust it.
It requires nothing special to accomplish and is working as designed. When you're using someone else's computer, you should assume they can see and hear everything you are doing at a minimum.
And no, you have no right to privacy on your companies computers or network at work, thats what you have your own home computer and network for.
Re:Why do we trust SSL? (Score:3, Interesting)
SSL has absolutely nothing at all to do with authorization. It carries no authorization information.
You are confused and clearly don't understand how SSL works and what it does.
SSL works by generating a new password for a symmetrical encryption algorithm on each session. Neither end knows the password before that point, they actually generate it together based on a communication method that ensures only the end points know the password.
Because both sides generate a password for each session, if you did not do authentication, anyone could jump in the middle and generate a password with you, and then create a new session to the destination you thought you were connecting to.
Authentication uses asymmetric encryption and public key infrastructure to verify that the system you are connecting to is who you think they are and not someone else, thus preventing a man in the middle attack. No authentication, your encryption is as good as useless as it can easily be intercepted and broken over the wire without you noticing.
There is no other way to work on 'web scale' authentication of connections other than PKI. Its simply a distributed automated OFFLINE CAPABLE way of verifying authentication information. If the CA cache in your browser hasn't been compromised, the CRL url can actually disable invalid signatures as well if they've been leaked or compromised in some way.
The only 'flaw' is that you trust 3rd parties. Because you trust 3rd parties to do the verification for you, it is possible they might validate the authentication information of someone who is not who they claim (for any number of reasons ranging from hacked servers, malicious intent to court order for the NSA).
Show me a method of distributing authentication information to the entire world that works better. And no, you're silly manually verified web of trust is a stupid fucking idea, which is why no one, including firefox has implemented such a feature. Just because you're idea is stupid, doesn't mean Firefox is stupid for not implementing it.
Everytime someone says something like you, they talk about some retarded way of doing exactly what we're already doing, but requiring individual users to do 1000's of times more work.
Hell, I have at least 6 SSL certificates IN MY HOUSE accessed by probably 20 different devices. Fuck you if you think I'm going to manually input 20 digit (or longer) finger prints for all those certs on all those devices, then twice as many at work, and I haven't even started talking to Amazon and iTunes to buy shit yet.
The reason we're still using 1990s 'tech' (which it was old in the 90s btw) is because theres nothing better, contrary to what you think. Please to be shutting up until you actually understand what you're talking about. You really made it clear that you have no idea whats going on.
Re:Convergence and Perspectives (Score:4, Interesting)
Those central authorities are welcome to join in, and become highly valued nodes in the WoT.
Aha, now I get it... could it really be this simple? Are X.509 advocates merely bad at math? The terms in your risk assessment formula are wrong.
If a signer has a probability p of being accurate/trustworthy, then the chance of its attestation being correct, is p. That's how X.509 certs work and of course you understand that very well. Cool. With PGP, if signer1's probability of being accurate is p1, and signer2's probability of being accurate is p2, then the chances their joint attestation of an identity is accurate, is 1-((1-p1)*(1-p2)). Dude, that's a number which is greater than either p1 or p2.
For example, say you think it's 90% likely that Verisign is telling you the truth about a key belonging to a certain website. They're the one and only signer for some website (because one signature is all this shitty tech can handle), so you think it's about 90% likely you're talking to that site, and 10% likely you're talking to the NSA. If that's your estimate of Verisign's reliability/trustworthiness, then 90% is the best you can do with that tech.
Now let's say we upgrade from that garbage to 1991 technology: the PGP WoT. Suppose Verisign and CNNIC have both signed something, and you think Verisign is 90% reliable and CNNIC is 60% reliable. (Those sneaky Chinese bastards!)
You're 1-( (1-0.9)*(1-0.6) ) = 0.96 , that is, 96% confident that you're talking to the website you wanted to, and 4% worried that you're talking to someone who is involved in a join US-China conspiracy (which, now that you think of it, is less than 4% likely to really occur). You have just wiped the floor with X.509's security performance.
Suppose I signed it too. You don't know me. While it seems absurd at first that I'm less trustworthy than the Chinese government (they're known badguys; I'm merely some internet asshole) at least you know something of their loyalties or lack thereof, and very little of my competence and motivations. It's reasonable to assume I am probably more likely to conspire with your adversaries than they are. Some guy with US government might be holding a gun to my head, right now! So you decide to only trust me 1%. Ok. Guess what? You can work with that!
Now my super-weak signature is on there. You trust the identity 1-( (1-0.9)*(1-0.6)*(1-0.01) ) = 96.04%. My super-weak nearly-completely-untrusted attestation made it stronger.
This is why were totally wrong when you said one compromised CA is easier to deal with than a billion. A billion compromised CAs are easier to deal with than one. Distributed authentication is more fault-tolerant, and we're now in a situation where the mainstream finally "gets it" that the faults really do occur, rather than it simply being a tinfoil hat thing that cypherpunk SciFi authors pretend to worry about. X.509 is based on the idea that Verisign is telling you the truth 100% of the time, and cannot model the idea that you think they sometimes fail. PGP, on the other hand, is based on reality: that grey world where sometimes things work and sometimes they don't, where you sort of trust some people some of the time, etc. You know, that world that you actually live in.
Re:Revocation --- or Redundancy? (Score:4, Interesting)
In fact something like this exists and may even be supported by your browser, but isn't in wide deployment at the moment. The way it works is that example.com goes out and gets an SSL cert for example.com, signed by some reasonable CA. example.com also configures dnssec for their domain. When you go to https://example.com/ [example.com] your web browser does a DNS query against _443._tcp.example.com for TLSA records. If it finds any, it validates the cert it gets via TLS against the TLSA record; the TLSA record can specify what certs are valid, or it can specify what certificate authority key (trust anchor) is valid, and there are a few other modes. The basic principle is that you now have two paths for validating the TLS cert: the CA _and_ DNSSEC. If both validate, use the cert. If either fails, don't use it. You can read all about it here [ietf.org].
In addition, TLS provides for certificate revocation, so if someone generates a bogus cert and it is _detected_, the cert can be revoked, or if a key is compromised, the cert for that key can be revoked.
These mechanisms seem more likely to be useful than just requiring certs from two different CAs.