The Google Chrome team released new statistics and implementation details on their proposed “False Start” abbreviated TLS handshake. Google claims the new handshake, introduced in version 9 of the Chrome browser in February, shaves an average of 120 milliseconds from a typical four-flight TLS handshake by accepting application data before both sides have communicated a “Finished” status. Chromium and its descendants such as Chrome can signal their acceptance of the abbreviated handshake protocol in the initial request for compatibility with 99.6% of known websites in the Google search index serving pages via the https scheme. Chromium flags incompatible sites in a blacklist text file bundled with the browser.
False Start is another example of the Chrome team speeding up the web by questioning existing protocols, introducing new ideas for how the Web could work enabled via a browser flag and possibly a server configuration, and defining a compatibility corpus based on the Web observed by Googlebot. SPDY is another good example. I like it.
Mike Belshe, an engineer on the Chrome team, has also been posting about unnecessarily long SSL certificate chains on large websites and the path to a short SSL chain including the competitive advantage of long-established certificate issuers. Good references for SSL/TLS behaviors behind the scenes that may be slowing down your websites and causing trust issues on mobile clients.