

False Start: Google proposal reduces SSL handshake to single round-trip - chrisaycock
http://www.theregister.co.uk/2011/05/19/google_ssl_breakthrough/

======
Matt_Cutts
I love this. More info in the Google blog post:
[http://blog.chromium.org/2011/05/ssl-falsestart-
performance-...](http://blog.chromium.org/2011/05/ssl-falsestart-performance-
results.html)

~~~
gwern
> 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
Very funky to have a list of "all known https sites"

------
emily37
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.

------
cagenut
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
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?

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

~~~
killerswan
No surprise there: the faster SSL gets, the more people will want to buy F5
and others to simplify deployment of it.

------
StavrosK
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
I thought that SSL latency (and additional server load) was due to encryption
overhead, not the handshake.

~~~
dangrossman
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.

~~~
smithian
Where in the world are you getting 1000 ms rtt's? Sat link?

~~~
rtomayko
Best case you have to do three RTs for a full SSL handshake (without false
start anyway), so a RTT of 300ms will bring you pretty close to that 1000ms.
We (github.com) certainly have average 1000ms SSL handshakes in Asia -- we're
5 RTs for an SSL handshake presently. It's extremely annoying.

~~~
smithian
Sure, I manage servers in the US, Japan and Australia so I'm well acquainted
with how latency sucks. I was questioning the idea that there was a
possibility of "an extra 100-1000 millisecond trip each way" - Taken
literally, this would mean up to a 2000ms RTT (1000 ms each way). I get ~230ms
RTT between Sydney and NYC, and 320 from Sydney to Hamburg going around the
wrong way. for reference, 2000 ms is 74% of the RTT to the moon.

~~~
phillmv
Oh, I would argue that latency often has no correlation to distance.

~~~
smithian
When you're talking about SSL handshakes, where else is the latency going to
come from?

~~~
TeMPOraL
Poor hardware.

<http://www.stuartcheshire.org/rants/Latency.html>

------
nessence
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.

------
JeffRodriguez
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...](http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html)

SSL everywhere!

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

~~~
jacques_chester
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.

~~~
tptacek
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.

~~~
jacques_chester
A wild security expert appears!

> This proposal overtly changes the security boundaries of that handshake.

Could you outline that in more detail?

~~~
tptacek
You're no longer waiting for both sides to confirm (cryptographically) that
they received the same handshake packets. A special mechanism (whitelisted
ciphersuites) has to be introduced to ensure that a downgrader adversary can't
trick a client into coughing up weakly-encrypted application data by mucking
with the handshake.

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

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

~~~
tptacek
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.

------
plasma
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?

~~~
JeffRodriguez
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.

~~~
TeHCrAzY
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.

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

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

