Jump to content

Google abandons attempt to make SSL faster


Recommended Posts


Posted Image

A comparison of the latency of normal SSL negotiations and those that use False Start.

Google is abandoning an SSL tweak that significantly reduces the time it takes websites to establish encrypted connections with end-user browsers because the experimental technique was causing problems with too many HTTPS servers.

Google security researcher Adam Langley, who announced False Start in 2010, said on Wednesday it would be disabled in version 20 of the company's Chrome browser. Although the technique reduced the latency of an SSL handshake by 30 percent and worked with the vast majority of websites, it remained incompatible with an unacceptably large number of them, mostly those that used dedicated hardware known as SSL terminators, which offload SSL processing from the servers.

"These hardware devices terminate SSL connections and proxy unencrypted data to backend HTTP servers," Langley wrote in a post titled False Start's Failure. "I believe that False Start intolerance is very simple to fix in the code and one vendor suggested that was the case. None the less, of the vendors who did issue an update, most failed to communicate that fact to their customers."

Langley went on to say he has experienced similar problems getting manufacturers of SSL products to make changes that protect against an exploit demonstrated in September known as BEAST, which can silently decrypt SSL-protected data that's passing between a webserver and an end-user browser.

False Start is largely controlled by the browser and works by reducing the two round-trip passes of data described in official SSL specifications to a single round-trip pass. It did this by instructing the client to send Finished and first ApplicationData messages in a single dispatch rather than putting them in two distinct packages and sending the second only after getting confirmation from the server. Google proposed False Start as an official standard to make SSL more palatable to websites that currently find it too expensive to offer. By abbreviating the handshake that negotiates the encryption key and other variables needed to protect data passing between the end user and website, False Start was intended to lower the performance penalty that many say comes from using the protocol.

Google has said that False Start was compatible with well over 99 percent of websites. To prevent problems with servers that did experience problems, Google engineers added a list of intolerant servers to Chrome so the browser would use traditional two-pass methods to negotiate an SSL session. Ultimately, Langley said, the engineers found that it wasn't as easy as they had expected to diagnose which sites would fail, so their confidence in the Chrome blacklist diminished.

The engineers also had difficulty working with the huge number of network administrators and hardware and software providers whose wares received the False Start instructions. In some cases, the difficulties were the result of language barriers, while in other cases the hardships stemmed from inertia on the part of hardware makers.

"One, fairly major, SSL terminator vendor refused to update to fix their False Start intolerance despite problems that their customers were having," Langley wrote. "I don't believe that this was done in bad faith, but rather a case of something much more mundane along the lines of 'the SSL guy left and nobody touches that code any more.' However, it did mean that there was no good answer for their customers who were experiencing problems."

Chrome will continue to use False Start with websites that have deployed Next Protocol Negotiation, another experimental TLS tweak devised by Google that's already available in NSS, TLSLite, and OpenSSL. NPN is just one of many changes proposed under SPDY, a broad set of experimental protocols intended to reduce the latency of webpages.

Although False Start will live on, Langley wasn't optimistic about its chances of wide-spread adoption, given the problems it's had over the past 18 months.

"In aggregate this led us to decide that False Start was causing more problems than it was worth," he wrote. "We will now limit it to sites that support the NPN extension. This unfortunately means that it'll be an arcane, unused optimisation for the most part: at least until SPDY takes over the world."

Posted Image View: Original Article

Link to comment
Share on other sites

  • Replies 0
  • Views 982
  • Created
  • Last Reply


This topic is now archived and is closed to further replies.

  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Create New...