70

Firefox dev tools show that https://www.google.com is using a certificate signed with SHA-1. Why is Google doing this when they are phasing out the certificate themselves?

Shouldn't this only hurt Google's reputation and interests?

Bruno Rohée
  • 5,351
  • 28
  • 39
sgoblin
  • 733
  • 1
  • 5
  • 8
  • 16
    Perhaps you are not aware that Google is a huge company with lots of different departments? And that departments do not always properly talk to each other, let alone agree on things... It's not three guys in a garage running the whole shop any more... – Lightness Races in Orbit Jun 12 '15 at 13:20
  • 3
    Yes, but corporate does have some rules that the rest must follow. – sgoblin Jun 13 '15 at 22:37
  • FWIW Chrome now complains about an HTTPS connection to google.com being insecure, for precisely this reason. – David Z Feb 01 '17 at 01:26

3 Answers3

104

This may be a case of "do what I say, not what I do". Note that Chrome complains about use of SHA-1 for signing certificates whose validity extends beyond the end of year 2015. In this case, Google's certificate is short-lived (right now, the certificate they use was issued on June 3rd, 2015, and will expire on August 31st, 2015) and thus evades Chrome's vengeful anathema on SHA-1.

Using short-lived certificates is a good idea, because it allows for a lot of flexibility. For instance, Google can get away with using SHA-1 (despite Chrome's rigorous stance) because the algorithms used to guarantee the integrity of a certificate do not need to be robust beyond the certificate expiration; thus, they can use SHA-1 for certificates that live for three months as long as they believe that they will get at least a three-month prior notice when browsers decide that SHA-1 is definitely and definitively a tool of the Demon, to be shot on sight.

My guess as to why they still use SHA-1 is that they want to interoperate with some existing systems and browsers that do not support SHA-256 yet. Apart from pre-SP3 Windows XP systems (that should be taken off the Internet ASAP), one may expect that there still linger a number of existing firewalls and other intrusion detection systems that have trouble with SHA-256. By using a SHA-256-powered certificate, Google would incur the risk of making their site "broken" for some customers -- not by Google's fault, but customers are not always fair in their imprecations.

So Google's strategy would appear to be the following:

  • They configure Chrome to scream and wail when it sees a SHA-1 certificate that extends into 2016 or later.
  • Because of all the scary warnings, users of existing SSL servers (not Google's) begin to desert (e.g. they don't complete their online banking transactions, because they are afraid), forcing the server administrators to buy SHA-256 certificates.
  • Now these new certificates "break" these sites in the eyes of the poor people that must live with outdated browsers or firewalls. This ought to force people to upgrade these browsers and firewalls.
  • Meanwhile, Google's reputation is unscathed, because their site never trigger any warning or broke an old firewall -- since it still uses SHA-1 !
  • When the whole World has switched to SHA-256, and all firewalls have been updated, the path becomes clear for Google, and they can use SHA-256 for their new certificates.

It is a pretty smart (and somewhat evil) strategy, if they can pull it off (and, Google being Google, I believe they can).

Thomas Pornin
  • 322,884
  • 58
  • 787
  • 955
  • 1
    You wrote *"Google's certificate is short-lived"*. Yep. But it's also SHA2 as well. (Or at least the one my SSL Labs scan got was so.) So if they're afraid of breaking anything they don't gain anything by SHA2 on EE cert and SHA1 on intermediate cert. Instead it seems to be the worst of both worlds. Puzzles me. (Screenshot: see my answer below.) – StackzOfZtuff Jun 11 '15 at 21:05
  • 2
    I am not sure Google sends the same certificate to everybody. It is already known that under each name (e.g. `www.google.com`) they have many servers located in several places around the world. Maybe the certificate you see and the one I saw are not the same. (I should have made a screenshot.) – Thomas Pornin Jun 11 '15 at 22:08
  • 1
    I assume _short-lived_ is the important part. If you only change your certificates every few years, this involves a lot of reading, fiddling, testing, ... Google decided to do this every few months, so they have a button for it. My guess is, that google either has a button to switch their whole universe to better certificates, or they are building one right now. – linac Jun 12 '15 at 07:24
  • 2
    Seems pretty reasonable to me... "If your certificate expires after 2015, then presumably you plan to still be using that certificate then, so we'll warn you about it now. If, however, your certificate expires before then, then presumably you'll be replacing it with an updated certificate before that date anyway, so we don't need to warn you". – Ajedi32 Jun 12 '15 at 15:59
  • 29
    Nitpick: I don't think it's quite appropriate to call this even somewhat evil. Sure, Google is serving their own interests by doing this in the sense that they avoid getting a reputation for triggering certificate errors, but they're doing exactly what any responsible site admin team _should_ be doing, namely being proactive about security. And as a side effect, they push the rest of the web up to a more modern security standard. I don't see who undeservedly suffers as a result of this strategy. – David Z Jun 12 '15 at 17:13
  • 1
    Yeah I would not call this evil. They're taking a bit of unfair advantage for themselves in the process, but what they're doing is so incredibly important that I think it's fair they get something out of it for themselves. – R.. GitHub STOP HELPING ICE Jun 12 '15 at 22:41
  • 3
    Up until the somewhat evil comment, this answer was pretty much an unbiased, factual summary of what was going on, making it a pretty surprising way to end the post, which did not seem to be leading in that direction. I'd have no problem with the claim it's evil if that was explained a little more so I can understand that point of view. From my point of view, they set some rules, and they are playing by their own rules completely, which is quite fair. Adding an exemption to their rules for their domain, *that* would have been evil. – thomasrutter Jun 15 '15 at 06:31
19

Meta-answer/comment.

Re. Thomas' answer:
I just ran an SSL Labs scan on a Google.com server and it seems that the end entity cert is in fact SHA256withRSA. But the (single) intermediate is only SHA1withRSA. No idea why.

Screenshot: SSL Labs screenshot

StackzOfZtuff
  • 17,923
  • 1
  • 51
  • 86
5

As noted by StackzOfZtuff, the SHA1-signature is in the long-lived¹ intermediate CA «Google Internet Authority G2».

This key pair is stored in a FIPS 140-2 Level 3 certified Hardware Security Module, where it was generated.² The HSM itself is able to sign using SHA1, SHA-256, SHA-384 or SHA-512.³

However, the signature for the HSM certificate was done by GeoTrust -presumably in April 2013-, using their GeoTrust Global CA root, when it was common to use SHA-1 signatures. It would be possible to replace that signature with a SHA256 one by cross-signing by the SHA256 root and replacing the certificate sent by the server, but it hasn't been done.

Note that if an attacker was able to create a SHA-1 key colliding with Google Internet Authority, the old signature would still work,⁴ so the Intermediate CA key whould have to be revocated, and thus there may be little interest on that cross-signing path, waiting instead for the HSM replacement, which I guess is programmed to be performed within next 12 months.

¹ 05/04/2013 15:15:55 to 31/12/2016 23:59:59 GMT

² https://pki.google.com/GIAG2-CPS-1.2.pdf section 6.1.1

³ Per appendix B

⁴ Although all SHA-1 signing roots should be revoked when that becomes feasible…

Ángel
  • 18,188
  • 3
  • 26
  • 63