> 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.
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?
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.
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.
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.
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.
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.
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.
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.
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).
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).
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:
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.
