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

Categories: Cryptography, Web Security

Comments (4)

  1. SJ
    1

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

  2. Ralph Dratman
    2

    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 ?

  3. Ralph Dratman
    3

    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 58775800862573103281586929495874683956436263435809876959559427036818854560806707448180999333806607037664820660661027855480614985095736759289615842304703561276472553562743737339238798519972174526395781986321996550284496848955869063047287975563934412652800831333891209667277165051.03 per picosecond.

    I worry that this change could result in a financial setback for my company.

  4. John Doe
    4

    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.

Comments are closed.