False Start: Google proposal reduces SSL handshake to single round-trip

http://www.theregister.co.uk/2011/05/19/google_ssl_breakthrough/

by chrisaycock • 15 years ago

118 41 15 years ago

theregister.co.uk

sbierwagen• 15 years ago

The RFC in question: https://tools.ietf.org/html/draft-bmoeller-tls-falsestart-00

jacques_chester2• 15 years ago

Quickly eyeballing that Internet-Draft, here's the core change:

> If certain conditions are met, application data can be sent when the handshake is only partially complete ...

I'm surprised this hasn't be done before -- spammers have used this idea with SMTP for years, for example. Well done Messrs Langley, Modadugu and Moeller.

tptacek3• 15 years ago

The integrity of the TLS handshake is one of the fundamental and most important promises the TLS protocol makes. This proposal overtly changes the security boundaries of that handshake. It is only because the shout-outs on this I-D are a who's-who of SSL/TLS design that this stands a decent chance at adoption.

TLS clients can do a bunch of different things, but, unlike in SMTP, where it's mostly reasonable to do whatever servers will let you get away with, both sides need to follow the protocol to the letter to make TLS do what it's supposed to do.

StavrosK• 15 years ago

This is potentially huge. SSL latency is a big issue when you want to make your site load faster, and this would basically eliminate the biggest reason to not turn SSL on. If this becomes standard, I can't see any of my sites, at least, using plain HTTP by default.

drivebyacct2• 15 years ago

I thought that SSL latency (and additional server load) was due to encryption overhead, not the handshake.

dangrossman2• 15 years ago

Compared to an extra 100-1000 millisecond trip each way to communicate between the browser and the server during the handshake, the CPU time to do the encryption is nothing.

brown9-2• 15 years ago

Take a look at this article which measures handshake latency versus encryption latency, it's very well-written: http://www.semicomplete.com/blog/geekery/ssl-latency.html :

Anyway. The point is, no matter how fast your SSL accelerators (hardware loadbalancer, etc), if your SSL end points aren't near the user, then your first connect will be slow. As shown above, 22ms for the crypto piece of SSL handshake, which means 300ms of the SSL portion above was likely network latency and some other overhead.

Once SSL is established, though, it switches to a block cipher (3DES, etc) which is much faster and the resource (network, cpu) overhead is pretty tiny by comparison.

Summarizing from above: Using SSL incurs a 3.5x latency overhead for each handshake, but afterwards it's generally fast like plain TCP. If you accept this conclusion, let's examine how this can affect website performance.

Matt_Cutts• 15 years ago

I love this. More info in the Google blog post: http://blog.chromium.org/2011/05/ssl-falsestart-performance-...

gwern• 15 years ago

> To answer this question, we compiled a list of all known https websites from the Google index, and tested SSL FalseStart with all of them. The result of that test was encouraging: 94.6% succeeded, 5% timed out, and 0.4% failed. The sites that timed out were verified to be sites that are no longer running, so we could ignore them.

It's nifty being a Googler.

pbiggar• 15 years ago

Very funky to have a list of "all known https sites"

plasma• 15 years ago

I thought SSL pages/resources aren't cached like they would be normally under regular HTTP, so there would still be extra latency (for repeat visits) if you ever visited a website that required SSL everywhere (like say Github).

Or is my assumption wrong here?

JeffRodriguez2• 15 years ago

It's a browser configuration thing, but I think you're right about the default.

Maybe a more intelligent approach would be to use "don't cache" if the server doesn't specify any caching headers. Otherwise, follow the server's recommendation.

TeHCrAzY2• 15 years ago

Its not something that could be changed from the current "default" without high risk of big impact.

There would be need to introduce a new header to trigger SSL based caching, and migrate towards simply not sending the old/normal cache header.

TeHCrAzY2• 15 years ago

You can see the direct result of that: lots of ajax'y functionality, and the reduction of full page refreshes.

briansmith• 15 years ago

This used to be true, but it isn't true any more on modern web browsers. In particular, Firefox improved its caching policies for HTTPS in version 4.

mike-cardwell• 15 years ago

https content is generally only cached in memory by the browser.

But if the response contains a Cache-Control header that explicitly specifies that the content is public, it can be cached to disk, just like http content. Eg:

Cache-Control: public, max-age=86400

cagenut2• 15 years ago

Hah, when they say "only a handful of vendors" that includes load balancer vendors like F5 and A10, which truckloads of ecommerce sites rely on for ssl offload. Its a simple code update to fix, but I remember doing a 4am loadbalancer reboot when my CTO's chrome auto-updated and all of a sudden he couldn't get to our https stuff (the important stuff).

illumin8• 15 years ago

Interesting - we use F5 load balancers for SSL offload, as do a huge percentage of the interwebs. If F5 didn't support False Start, I suspect a good deal more than 0.4% of the SSL websites would be affected.

Do you think maybe it's something like an older version of F5 BigIP firmware that doesn't support False Start?

cagenut2• 15 years ago

Yea thats what I meant by 'simple code update'. All the vendors have long since put out fixes.

Joakal• 15 years ago

Would this eliminate the need for SSL caches? [0]

[0] http://wiki.nginx.org/HttpSslModule

JeffRodriguez2• 15 years ago

Google's been doing a lot of work on SSL performance for a while now:

http://www.imperialviolet.org/2010/06/25/overclocking-ssl.ht...

SSL everywhere!

ivank• 15 years ago

The False Start blacklist, in case anyone else is curious: http://src.chromium.org/svn/trunk/src/net/base/ssl_false_sta... (about 4141 entries right now)

wmf• 15 years ago

Looks like Exchange and some SSL VPNs have a little standard compliance work to do.

tptacek3• 15 years ago

From the TLS 1.2 RFC:

  The Finished message is the first one protected with the just
  negotiated algorithms, keys, and secrets.  Recipients of Finished
  messages MUST verify that the contents are correct.  Once a side
  has sent its Finished message and received and validated the
  Finished message from its peer, it may begin to send and receive
  application data over the connection.

Hard to blame the servers for this.

nessence• 15 years ago

This doesn't help adoption like the article suggests; what it does do is shave a few milliseconds and overhead off the initial connection which is great for thin or long pipes (low bandwidth or high latency). Otherwise, in contrast to the article's statement about SSL not being implemented because of the encryption overhead, false start doesn't change much.

The bigger picture is that false-start will make google's upcoming SPDY handshake faster too; then, because SPDY is a more aggressive with the initial connection (CWND, push support), the packets saved by false start are used to push content. Without false-start, an initial SPDY connection would be encumbered.

emily37• 15 years ago

Google also has a proposal called Snap Start that reduces the handshake to zero round trips when the browser has performed a full handshake with the server in the past: http://tools.ietf.org/id/draft-agl-tls-snapstart-00.html. It's much more complex and requires adoption in both servers and browsers so I don't think they're working on it anymore, but maybe someday.

Certificate validation can be even more of a bottleneck than RTTs to the server; I worked on a paper that's in submission where we gathered OCSP response times in the wild, and median times for some responders were as high as 500ms.

False Start: Google proposal reduces SSL handshake to single round-trip

Related Stories