Google Strengthening Keys on SSL Certificates to 2048 Bits

As attacks against cryptographic systems and the SSL infrastructure have advanced in recent years, experts have begun to fret about the future utility of the system. Companies that rely on the security of the SSL technology are beginning to take steps to address the issue, with the latest being Google, which is planning to change the length of the keys on all of its SSL certificates to 2048 bits.

SSL is the encryption system that’s used to secure Web transmissions betweens clients and servers. It’s used in a variety of applications, including online banking, shopping and other financial transactions. But it’s also used to secure connections for sensitive activities such as email, and Google offers SSL connections for most of its major online services.  The company gives users the option of making SSL connections the default choice for Gmail, for example, and users also can connect to Google search over HTTPS.

To help ensure the future security of these services, Google plans to move from 1024-bit keys to 2048-bit keys by the end of 2013. The change in key length makes it much harder for an attacker to use known methods to break the key. As part of the change, Google is trying to make users aware of some potential software conflicts that may occur as a result of the longer key length.

“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,” Stephen McHenry, Director of Information Security Engineering at Google, wrote in a blog post.

“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.”

Specifically, McHenry said that clients must have the ability to support the normal validation of a certificate chain, along with including a properly extensive set of root certificates. There are a number of things that could cause certificate validation issues after the change, McHenry said, including clients that use hashes to match certificates exactly. Also, clients with hard-coded root certificates, such as those with certificates embedded in firmware, may run into problems.

In recent years there have been a number of attacks against both SSL implementations and the certificate authority infrastructure itself. Most of these attacks, including the BEAST attack and CRIME attack and the compromises at CAs such as DigiNotar, have been on the implementation of SSL/TLS or on the CAs that sell certificates. Attacks on the protocol itself haven’t been as common, mainly because it’s much easier to find vulnerabilities in implementations or clients. Google’s move to lengthen the keys on its SSL certificates will make it even more difficult for attackers to break the keys and impersonate a valid Google SSL certificate.

Image from Flickr photostream of Alexandre Dulaunoy

Suggested articles

Lyceum APT Returns, This Time Targeting Tunisian Firms

The APT, which targets Middle-Eastern energy firms & telecoms, has been relatively quiet since its exposure but not entirely silent. It’s kept up attacks through 2021 and is working on retooling its arsenal yet again. 


  • SJ on

    And will google stop using the * wild card certificate? If they spread their cert private key on all the servers that use the * cert then how do they know it isn't compromised every time they have a breach?
  • Ralph Dratman on

    I really don't understand how this increase can be necessary. According to this information, soon my spy company will have to test 2^2048 possible keys... well, say half on average, only 2^2047 tests... because Google suspects we have been breezing right through the mere 2^1023 keys we have had to test until now? Oh dear, how shall we ever get through all those keys now, after this increase by a factor of 2^1024 in how many we must test? Does this mean my key-testers will have to work additional overtime testing possible keys, thus raising my labor costs in that group by a factor of 2^1024 ?
  • Ralph Dratman on

    Thanks to fast-working employees, last year my key-testing labor costs were only a billionth of a U.S. cent per year, which I felt ok about paying. But after this increase in the length of Google's SSL keys, my labor costs will rise to $US 587758008625731032815 869294958746839564362 634358098769595594270 368188545608067074481 809993338066070376648 206606610278554806149 8509573675928961584230 4703561276472553562743 7373392387985199721 745263957819863219 96550284496848955 869063047287975563 93441265280083133 3891209667277165051.03 per picosecond. I worry that this change could result in a financial setback for my company.
  • John Doe on

    Ralph, You are an idiot, please do 2 minutes of research before forming opinions. Cracking RSA does not require full brute force of the key. (No asymettric encyption comes close to approaching brute force difficulty. ECC requires ~2x key length for equal difficulty.) Case in point: A 768 bit RSA key was cracked in 2010 (taking 2.5 years of processing). NIST standards no longer allow usage of 1024 bit keys, and imply 2048 keys may be crackable around ~2030.

Subscribe to our newsletter, Threatpost Today!

Get the latest breaking news delivered daily to your inbox.