Ask Slashdot: Has Gmail's SSL Certificate Changed, How Would We Know?

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?"

Comments

Google announced this

[supersat]

Back in May, Google announced that they would be making changes to their SSL/TLS certificates in the coming months: http://googleonlinesecurity.blogspot.com/2013/05/changes-to-our-ssl-certificates.html

If you use Chrome, Google's SSL certificates are pinned, so that gives you some additional assurance.

Re:Google announced this

[Trax3001BBS]

Back in May, Google announced that they would be making changes to their SSL/TLS certificates in the coming months: http://googleonlinesecurity.blogspot.com/2013/05/changes-to-our-ssl-certificates.html

Oh No's!
"Even in less-than-obvious places to look for information, such as Google's Online Security Blog, are silent."

To a non-story
"Back in May, Google announced..."

Thanks for that.

Re:Google announced this

[spottedkangaroo]

ECC keys are shorter than RSA keys. 256 ecc is like 3072 rsa bits.

Expiry

[jamesh]

Was the old cert due to expire? I have thought before that it would be nice if my browser etc gave me a warning like "Certificate has changed but wasn't due to expire for another 3 months". This still gives the bad guys a window where a subverted certificate could be slipped in without notice, but it closes the window a bit.

Also is it common to revoke the old certificate when replacing it, even if there is no reason to suspect the old certificate was compromised? If so that would be another warning that could be presented

Re:Expiry

[Anonymous Coward]

I use with Firefox the Certificate Patrol add-on for detecting, when the certificates are changed. At least then you know, when the certificate has been changed.

Convergence and Perspectives

[magic maverick]

From https://en.wikipedia.org/wiki/Convergence_%28SSL%29:

With Convergence, however, there is a level of redundancy, and no single point of failure. Several notaries can vouch for a single site. A user can choose to trust several notaries, most of which will vouch for the same sites. If the notaries disagree on whether a site's identity is correct, the user can choose to go with the majority vote, or err on the side of caution and demand that all notaries agree, or be content with a single notary (the voting method is controlled with a setting in the browser addon). If a user chooses to distrust a certain notary, a non-malicious site can still be trusted as long as the remaining trusted notaries trust it; thus there is no longer a single point of failure.

The Monkeysphere Project tries to solve the same problem by using the PGP web of trust model to assess the authenticity of https certificates.[8]

Now, everyone, let's use the tools available!

Detecting Certificate Change

[seawall]

Addons for web browsers (e,g. Certificate Patrol in Firefox, there are others) can clue you into certificate changes. Rather like Ghostery (which shows where stuff is loading from in a web page): it is an eye opener.

Certificate Transparency

[goddidit]

Certificate transparency is a new project initiated at least partly by Google's engineers, which intends to solve this problem with SSL trust model: http://www.certificate-transparency.org/
It uses an append only public log, similar to Bitcoin transaction log to make certificate information public.

Re:Why do we trust SSL?

[AK Marc]

And most commercial sites do the same. They call it "reverse-proxy) and is done because web server software sucks at encryption. So if you are mobing 10 Gbps of encrypted web traffic, you put an encrypting proxy 1RU above the server, and the server serves pages, and the proxy encrypts them. Well, it's usually a little more complicated than that, but that's the general idea. I've done it. It is that easy.

Re:Revocation --- or Redundancy?

[petermgreen]

Do you even know how PKI works?

Currently PKI works by having a large number of certification authorities (both roots installed in the browser and intermediates with delegated authority from those roots) any one of which can issue a certificate that will be trusted by the browser to identify a site. So if any one of those certification authorities is compromised by an attacker then the attacker can obtain a certificate with which they can MITM traffic to your site without generating any warnings.

AIUI What the GP is proposing is that multiple independent authorities would need to vouch for a "high security" site so that one compromised certification authority would not be sufficiant to perform a man in the middle attack. It's a nice idea in principle but there are several practical issues to deal with.

1: How do you define independent authority. I'm sure there are cases where multiple root certificates are controlled by the same entity.
2: How do you decide what sites it should apply to. One possibility would be to never allow the number of authorities for a site to go down so once a site had been seen with more than 1
3: How do we modify the protocols to support this.
4: How do we convince site operators to adopt this.

Re:Revocation

[Mr. Slippery]

I installed it when it was version 7 and it still is version ... (Checks version) ... How did it get to this version 23?

In case anyone doesn't know, you can turn that off. Also, I advise getting on the "extended service release" (ESR) track.