Eureka! Google breakthrough makes SSL less painful
Client-side change cuts latency by 30%
Google researchers say they've devised a way to significantly reduce the time it takes websites to establish encrypted connections with end-user browsers, a breakthrough that could make it less painful for many services to offer the security feature.
What's more, the technique known as False Start requires that only simple changes be made to a user's browser and appears to work with 99 percent of active sites that offer SSL, or secure sockets layer, protection.
"We implemented SSL False Start in Chrome 9, and the results are stunning, yielding a significant decrease in overall SSL connection setup times," Google software engineer Mike Belshe wrote in a blog post published Wednesday. "SSL False Start reduces the latency of a SSL handshake by 30%. That is a big number."
The finding should come as welcome news to those concerned about online privacy. With the notable exceptions of Twitter, Facebook, and a handful of Google services, many websites send the vast majority of traffic over unencrypted channels, making it easy for governments, administrators, and Wi-Fi hotspot providers to snoop or even modify potentially sensitive communications while in transit. Companies such as eBay have said it's too costly to offer always-on encryption.
The Firesheep extension introduced last year for the Firefox browser drove home just how menacing the risk of unencrypted websites can be.
False Start works by reducing the amount of data that must be exchanged when a webserver and browser are negotiating an SSL session. Under official SSL specifications, two round-trip passes of data must be exchanged before an encrypted tunnel is established. The requirement adds latency that can slow down the time it takes pages to load and increase the packets websites must process.
Latency "makes a difference in does it feel snappy or does it feel sluggish," said Marsh Ray, a researcher and software developer at two-factor authentication service PhoneFactor. False Start "certainly eliminates an objection that some people have for SSL, which is that it increases the load time."
False Start, as described in a proposal Google engineers submitted last year to the Internet Engineering Task Force, makes it possible to reduce the latency penalty of offering SSL to just a single round-trip pass. The technology does this by using an abbreviated handshake when negotiating the key and other variables used in the encrypted session.
Belshe said engineers tested False Start on a list of all known websites that offer SSL and got a 94.6 percent success rate. Almost all of the unsuccessful connections came from sites that were no longer available, leaving a true failure rate of just 0.4 percent. Those sites have now been compiled into a manageable list used to turn off False Start when they are accessed in Chrome.
"All of this represents a tremendous amount of work with a material gain for Chrome SSL users," Belshe said. "We hope that the data will be confirmed by other browser vendors and adopted more widely."
Of course, getting more websites to offer always-on SSL is just one step in better securing the web. Browser makers, certificate authorities and others must still overcome a bevy of other problems miring SSL. ®
PKI is not the same thing as SSL. You appear not to know the difference.
It's nonsense to say "PKI is broken to the degree that if 100% of the sites out their enforced SSL the data might as well be sent in the clear anyways."
If you work at an ISP, and I connect to gmail unencrypted, you can read my emails, if you so choose.
If you work at an ISP and i connect to gmail over SSL, you cannot read my emails.
Saying otherwise is simply untrue. Saying data sent in the clear is the same as data sent over SSL is equally insecure is just nonsense, and is either hyperbole, or you don't know what you're talking about.
"If it ain't broken..."
"...don't fix if".
I've got a bad feeling this may lead to significant increase in bugs allowing for session hijacking.
@Tom Chiverton 1
I'm sorry, but do you honestly believe that SSL cannot protect against a man-in-the-middle attack!? It's one of its main aims!
Your scenario fails because the ISP server cannot authenticate as my computer with the gmail server, nor as the gmail server with my computer. In other words, both my computer and the gmail server will know that someone has tampered with the communication.
For your own sake, please do some reading on the theory behind security protocols.