Google is upgrading the digital certificates used to secure its Gmail, Calendar, and Web search services. Beginning on August 1, the company will start upgrading the RSA keys used to encrypt Web traffic and authenticate to 2048-bits, twice as many as are used now.

The rollout affects the transport layer security (TLS) certificates that underpin HTTPS connections to Google properties. Sometimes involving the secure sockets layer (SSL) protocol, the technologies prevent attackers from reading the contents of traffic passing between end users and Google. They also provide a cryptographic assurance that servers claiming to be Google.com are in fact operated by Google, as opposed to being clones created by attackers exploiting age-old weaknesses in the way the Internet routes traffic.

There are good reasons for Google to upgrade the strength of these crucial digital keys. The weaker the key strength of an RSA key pair, the easier it is for anyone to mathematically derive the "private key." Such attacks work by taking the certificate's "public key" that's published on the website and factoring it to derive the two prime numbers that make up the private key. Once the private key for a Google certificate has been factored, the attacker can impersonate an HTTPS-protected Google server and provide the same indications of cryptographic security as the legitimate service. Someone who was able to derive the secret primes to Google's private key, for instance, would be able to create convincing attacks that would fool many browsers and e-mail clients.

The factors in private keys are extremely time-consuming to find, but increases in computing power are making the task gradually easier. In 2009, researchers were able to factor a 768-bit RSA key, according to Wikipedia. The online encyclopedia went on to say that a 1024-bit key has not yet been factored. While it may take years for that to happen, it's only a matter of time until it is. And of course, secretive agencies within powerful nation states may already have the ability to factor larger bit sizes.

Another type of attack used to defeat cryptographic certificates is known as a collision attack. Rather than deriving a private encryption key, it forges a digital key used to sign software. It works against hashing algorithms by finding two pieces of plaintext that generate the same cryptographic message digest. While it's extremely time-consuming to find such collisions, certain algorithms—particularly MD5—have known weaknesses that significantly reduce the requirements. The Flame espionage malware that targeted Iran wielded a never-before-seen collision attack to hijack Microsoft's Windows Update mechanism.

Researchers have estimated that the SHA1 algorithm, which is considered more resistant to collision attacks and underpin huge parts of Internet security, could fall by 2018.

The new certificates being rolled out by Google could create headaches for some software developers, particularly those whose code is embedded in certain types of phones, printers, set-top boxes, gaming consoles, cameras, and other types of devices. For those developers, Google provided the following advice:

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.

People using mainstream browsers and e-mail clients aren't likely to notice any difference at all.