Google Data

Posted by Stephen McHenry, Director of Information Security Engineering

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.