False Start: Google proposal reduces SSL handshake to single round-trip(theregister.co.uk)
theregister.co.uk
False Start: Google proposal reduces SSL handshake to single round-trip
http://www.theregister.co.uk/2011/05/19/google_ssl_breakthrough/
41 comments
I love this. More info in the Google blog post: http://blog.chromium.org/2011/05/ssl-falsestart-performance-...
> 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.
It's nifty being a Googler.
Very funky to have a list of "all known https sites"
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.
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.
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).
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?
Do you think maybe it's something like an older version of F5 BigIP firmware that doesn't support False Start?
Yea thats what I meant by 'simple code update'. All the vendors have long since put out fixes.
No surprise there: the faster SSL gets, the more people will want to buy F5 and others to simplify deployment of it.
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.
I thought that SSL latency (and additional server load) was due to encryption overhead, not the handshake.
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.
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.
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.
Where in the world are you getting 1000 ms rtt's? Sat link?
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.
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.
Oh, I would argue that latency often has no correlation to distance.
When you're talking about SSL handshakes, where else is the latency going to come from?
Poor hardware.
http://www.stuartcheshire.org/rants/Latency.html
http://www.stuartcheshire.org/rants/Latency.html
Not everyone lives within a few hundred miles of the web server they're using.
Not to mention the WildBlue etc satellite Internet often used in rural areas.
the ssl handshake latency isn't why sysadmins don't want to implement everything over https. the reason (or at least 5 years ago when sysadmin was my primary role) is because the additional cpu power it takes to encrypt all the data is huge.
That's not really true now. CPUs have gotten faster, the speed of light has remained the same, and actually with users on crappy wireless/cell connections (and, increasingly, international), network latency is even more of an issue now.
I don't think that's really the case anymore. CPUs have just gotten that much faster. I run a node.js server with https on Linode's cheapest VPS that handles hundreds of requests per second. The server load is at ~0.00 most of the day.
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.
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.
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!
http://www.imperialviolet.org/2010/06/25/overclocking-ssl.ht...
SSL everywhere!
The RFC in question: https://tools.ietf.org/html/draft-bmoeller-tls-falsestart-00
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.
> 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.
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.
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.
A wild security expert appears!
> This proposal overtly changes the security boundaries of that handshake.
Could you outline that in more detail?
> This proposal overtly changes the security boundaries of that handshake.
Could you outline that in more detail?
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.
The TLS handshake is to work out identities and exactly what type of encryption etc they want/support. Then before sending any actual data they encrypt a "Finished" message and both sides verify they can read the message. The server will only be able to create a correct "Finished" message if it has the private key to go along with the presented certificate.
It seems to me like the overt change in the handshake security boundary is that in a FalseStart handshake, a man-in-the-middle attacker can make the initiating side send application data encrypted with relatively arbitrary parameters (until the TLS implementation realizes it can't decrypt the final handshake message properly). There is a good chance this is just annoying (like, on a denial-of-service level of attack) but my intuition is there could be some application circumstances where this is a significant problem. Off the top of my head I can't come up with a specific example however - so I could just be imagining things :)
There are also operating system/application level architecture challenges as well. For example, I'm not sure the idea of FalseStart is compatible with the calling convention of Windows SSL/TLS (InitializeSecurityContext and AcceptSecurityContext) given the separation between transport layer and security context negotiation components. And because of that existing convention, the recommendation in sections 4 and 5 of the draft that "TLS implementations allow the application layer to query whether the handshake has completed" could be potentially tricky for applications using Schannel (Windows SSL/TLS).
"Creating an Schannel Security Context" : http://msdn.microsoft.com/en-us/library/aa374781(v=VS.85).as...
It seems to me like the overt change in the handshake security boundary is that in a FalseStart handshake, a man-in-the-middle attacker can make the initiating side send application data encrypted with relatively arbitrary parameters (until the TLS implementation realizes it can't decrypt the final handshake message properly). There is a good chance this is just annoying (like, on a denial-of-service level of attack) but my intuition is there could be some application circumstances where this is a significant problem. Off the top of my head I can't come up with a specific example however - so I could just be imagining things :)
There are also operating system/application level architecture challenges as well. For example, I'm not sure the idea of FalseStart is compatible with the calling convention of Windows SSL/TLS (InitializeSecurityContext and AcceptSecurityContext) given the separation between transport layer and security context negotiation components. And because of that existing convention, the recommendation in sections 4 and 5 of the draft that "TLS implementations allow the application layer to query whether the handshake has completed" could be potentially tricky for applications using Schannel (Windows SSL/TLS).
"Creating an Schannel Security Context" : http://msdn.microsoft.com/en-us/library/aa374781(v=VS.85).as...
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)
Looks like Exchange and some SSL VPNs have a little standard compliance work to do.
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.
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?
Or is my assumption wrong here?
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.
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
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
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.
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.
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.
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.
You can see the direct result of that: lots of ajax'y functionality, and the reduction of full page refreshes.
Would this eliminate the need for SSL caches? [0]
[0] http://wiki.nginx.org/HttpSslModule
[0] http://wiki.nginx.org/HttpSslModule