Changes to our SSL Certificates

Thursday, May 23, 2013 8:00 AM



Protecting the security and privacy of our users is one of our most important tasks at Google, which is why we utilize encryption on almost all connections made to Google.

This encryption needs to be updated at times to make it even stronger, so this year our SSL services will undergo a series of certificate upgrades—specifically, all of our SSL certificates will be upgraded to 2048-bit keys by the end of 2013. We will begin switching to the new 2048-bit certificates on August 1st, to ensure adequate time for a careful rollout before the end of the year. We’re also going to change the root certificate that signs all of our SSL certificates because it has a 1024-bit key.

Most client software won’t have any problems with either of these changes, but we know that some configurations will require some extra steps to avoid complications. This is more often true of client software embedded in devices such as certain types of phones, printers, set-top boxes, gaming consoles, and cameras.

For a smooth upgrade, client software that makes SSL connections to Google (e.g. HTTPS) must:
  • Perform normal validation of the certificate chain;
  • Include a properly extensive set of root certificates contained. We have an example set which should be sufficient for connecting to Google in our FAQ. (Note: the contents of this list may change over time, so clients should have a way to update themselves as changes occur);
  • Support Subject Alternative Names (SANs).
Also, clients should support the Server Name Indication (SNI) extension because clients may need to make an extra API call to set the hostname on an SSL connection. Any client unsure about SNI support can be tested against https://googlemail.com—this URL should only validate if you are sending SNI.

On the flip side, here are some examples of improper validation practices that could very well lead to the inability of client software to connect to Google using SSL after the upgrade:
  • Matching the leaf certificate exactly (e.g. by hashing it)
  • Matching any other certificate (e.g. Root or Intermediate signing certificate) exactly
  • Hard-coding the expected Root certificate, especially in firmware. This is sometimes done based on assumptions like the following:
    • The Root Certificate of our chain will not change on short notice.
    • Google will always use Thawte as its Root CA.
    • Google will always use Equifax as its Root CA.
    • Google will always use one of a small number of Root CAs.
    • The certificate will always contain exactly the expected hostname in the Common Name field and therefore clients do not need to worry about SANs.
    • The certificate will always contain exactly the expected hostname in a SAN and therefore clients don't need to worry about wildcards.
Any software that contains these improper validation practices should be changed. More detailed information can be found in this document, and you can also check out our FAQ if you have specific questions.
The comments you read here belong only to the person who posted them. We do, however, reserve the right to remove off-topic comments.

9 comments:

Chris Lockfort said...

With an apparent move to having a wide variety of CA vendors / leaf certs / etc, won't that make it harder for people to recognize when, for instance, a government forces a CA to issue valid certs for domains like gmail.com and intercepts what they presumed were private communications?

jethro inwald said...

Please use something stronger then 128 bit Rc4 for youtube's SSL as well.

Andreas Hallof said...

... and certainly you should use sha-256 instead of sha-1 in your certificates

The IT Solutions People said...

I think it will be completely safe. Private key's are not something that a CA has or ever should have possession of so unless Google themselves provide their private key's willingly to government's all information remains private.

The IT Solutions People said...

It is about time that Google moved to 2048 bit Roots and Keys. The continued use of the archaic Equifax Root signed hierarchy was a poor example to businesses and Enterprises on how to use SSL certificates to ensure the integrity of private and sensitive data and the legitimacy of the supposedly secured URL

SSL certificates are not used to protect Google themselves but the Public that interacts with Google, with the complete and unequivocal expectation that their Private and Sensitive data will remain just that.

Our core business principles are based on this message and this is the guidance that itsolutionspeople.com provide to its customers.

April Joy said...

Is there a list of SSL compliant vendors out there?

Kinan DeJon said...

To answer April Joy;
Symantec, GeoTrust, Thawte, Trustwave
http://goo.gl/RKaaVE

pseudo nym said...

Even with the expansion to 2048 bit keys, if the entropy generating the primes P and Q used for the encryption is too low, there are still issues. See the great research done by the University of Michigan about "minding your Ps and Qs" - one start point here - https://freedom-to-tinker.com/blog/nadiah/new-research-theres-no-need-panic-over-factorable-keys-just-mind-your-ps-and-qs/

So Google...do you have sufficient entropy? That's the real question. 1024 bit keys would theoretically have enough primes that there would never be an issue of duplicate keys, but poor random number generation and insufficient entropy led to the Michigan folks compromising about a half a percent of public keys. That is vastly more than predicted...

Chris Cooper said...

When can we expect to see updated Google applications that support these recommendations?

At this time, Google Drive's PC application does not support SNI and performs some degree of certificate pinning for transfers.