Google strengthens its SSL configuration against possible attacks
Google replaced the SSL certificates for its online services with new ones that use stronger, 2048-bit RSA keys, making encrypted connections to its sites safer against so-called brute-force attacks.
The company announced in May that it would increase the key length for its SSL certificates from 1024 bits to 2048 bits by the end of 2013.
“Coming in ahead of schedule, we have completed this process, which will allow the industry to start removing trust from weaker, 1024-bit keys next year,” Google security engineer Dan Dulay said Monday in a blog post.
Until not long ago 1024-bit RSA keys were considered sufficiently strong because cracking them using brute force by systematically trying all possible combinations was viewed as impractical due to the computing power and time required. However, following the recent revelations about the mass data collection programs of the U.S. National Security Agency and its investments in groundbreaking cryptanalysis, that’s no longer the case.
“After more revelations, and expert analysis, we still aren’t precisely sure what crypto the NSA can break,” Robert Graham, the CEO of security firm Errata Security, said in a blog post in September. “But everyone seems to agree that if anything, the NSA can break 1024 RSA/DH keys. Assuming no ‘breakthroughs,’ the NSA can spend 1ドル billion on custom chips that can break such a key in a few hours. We know the NSA builds custom chips, they’ve got fairly public deals with IBM foundries to build chips.”
Increasing the key length for SSL certificates is not a new development, as many certificate authorities have stopped issuing new certificates with 1024-bit keys for a while. The Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates, a set of guidelines published by the Certification Authority/Browser (CAB) Forum, states that all newly issued certificates that have a validity period ending after Dec. 31, 2013, should have 2048-bit RSA keys.
According to a November scan done by the SSL Pulse project, 96 percent of the Internet’s top 162,480 HTTPS-enabled sites already use SSL certificates with 2048-bit keys.
“The deprecation of 1024-bit RSA is an industry-wide effort that we’re happy to support, particularly in light of concerns about overbroad government surveillance and other forms of unwanted intrusion,” Dulay said.
Google didn’t rush to increase the key length earlier because its SSL configuration has been using the elliptic curve, ephemeral Diffie—Hellman (ECDHE) key-agreement protocol by default since 2011. This protocol has a property known as perfect forward secrecy (PFS) that makes it hard to decrypt previously captured traffic if the server’s private key is compromised.
During an SSL handshake, the client generates a key for encrypting the session traffic and sends it to the server after encrypting it with the server’s public key, which is available in the server’s SSL certificate. The server then decrypts the session key chosen by the client with its secret private key and starts using it. This is known as the key agreement, where the client and server agree on a shared key.
If non-PFS key-agreement protocols are used, an attacker who learns the server’s private key by brute force or other means can use it to decrypt the shared keys for any sessions captured in the past. In this configuration, the server’s private key is actually a master key for all previous communications.
PFS key-agreement protocols like ECDHE mitigate this master key vulnerability and force attackers to break separate private keys for every captured session if they want to learn their content, making the mass decryption of SSL traffic through brute force attacks a lot less practical.
Client-side support for key-agreement protocols with PFS is very good across the board, said Ivan Ristic, director of application security research at security firm Qualys, which runs the SSL Labs and SSL Pulse projects. Clients that don’t support this type of key exchange are likely very old and the amount of traffic they account for is small, he said.
Support for this feature on the server side is not as widespread. Forty-two percent of websites surveyed by SSL Pulse support some PFS cipher suites, but only around 3.7 percent actually use them with modern browsers.
According to Ristic, PFS makes passive attacks like decrypting a large amount of captured traffic much harder, but it doesn’t protect against active attacks. An attacker with access to the server’s private key and its SSL certificate could potentially launch man-in-the-middle attacks to impersonate the website to clients and intercept their data in real time.
Google revoked all of its 1024-bit certificates, but some browsers can be blocked by attackers from checking whether certificates have been revoked, and past research revealed that many non-browser applications don’t check for certificate revocation at all.
However, in addition to using PFS, Google probably used short-lived private keys limiting their potential value for man-in-the-middle attacks.
The company’s new certificates with 2048-bit keys will expire in four months and will be changed, which is probably what the company used to do with its 1024-bit certificates too, Ristic said. “In my experience, Google has had the best SSL configuration for some time now.”
The company is able to change public-private key pairs frequently because it operates its own intermediate CA called Google Internet Authority and can use it to issue new certificates to itself.
“The hardware security module (HSM) that contained our old, 1024-bit, intermediate certificate has served us well,” Dulay said. “Its final duty after all outstanding certificates were revoked, was to be carefully destroyed.”
“With the demolition of the HSM and revocation of the old certificates, Google Internet Authority G2 will issue 2048-bit certificates for Google websites and properties going forward,” he said.