1.    15 Jun 2016 #1
    Join Date : Oct 2013
    Posts : 15,573
    64-bit Windows 10 Pro build 14951

    Building faster secure web w/ TCP Fast Open, TLS False Start, TLS 1.3

    Performance and security matter to everyone. Better page load performance improves the user’s experience and influences their choice over which web pages to use. At the same time, users just expect their browsing experience to be secure and private. With TCP Fast Open, TLS False Start, and TLS 1.3, we can improve both performance and security.

    Today, we’re introducing support for TCP Fast Open in Microsoft Edge behind an about:flags setting in Windows Insider Preview builds, starting with EdgeHTML 14.14361 and higher. Try it out and let us know what you think!

    The road to TLS 1.3

    We trust the internet with our most important information, including financial data. Ensuring the integrity and security of these transactions is critical to the entire community. More than half of web connections use TLS for securing the network traffic on the web, and this number grows every day. This is great for security and privacy, but we would like to deploy encryption without slowing down the web. Modern encryption itself is very fast, but requires negotiating keys to establish a connection before fetching page resources. Each extra exchange through the network delays the connection by one “round trip time” (RTT).

    With current standards, connections requiring TLS over TCP require round trips to the server (3-RTT) to negotiate—1 for TCP and 2 for TLS—before starting sending something useful, like the first HTTP GET command. This gets even more problematic when sites split content across multiple domains. In practice, adding encryption adds delays in the range of hundreds of milliseconds to the page load time. Research shows that even 250ms delay is enough for a user to consider trying another website.

    The good news is that a new standard, TLS 1.3, will allow developers to eliminate that delay in most cases while still encrypting content. That means delivering better performance and security in Microsoft Edge, using modern encryption on top of the continually improved TCP stack. TLS 1.3 is working through the standardization track now, and the IETF expects to publish it this summer. But even without TLS 1.3, we can combine TCP Fast Open and the TLS False Start option, and reduce the delay from 3-RTT to 1-RTT. Even reducing your page load time by an average of 50 milliseconds will contribute to a better browsing experience.

    Full handshake with TCP and TLS

    The current TCP and TLS standards require 3 roundtrips to the server (3-RTT). The first round trip is where we negotiate the TCP connection parameters. In the second roundtrip, the client and server exchange TLS messages starting with Client Hello and Server Hello to agree on parameters and keys of the connection. The last roundtrip includes the verification of the TLS handshake integrity through the Client and Server Finished messages.

    Full Handshake – TLS 1.0, 1.1, 1.2

    Achieving 1-RTT with TLS False Start and TCP Fast Open

    The first improvement comes from the TLS False Start option, which allows the client to start sending encrypted data immediately after the first TLS roundtrip. With that, we are down to 1-RTT for TLS, or 2-RTT if we count the TCP connection. We have already enabled TLS False Start in Microsoft Edge, with a set of strong cipher suites.

    TLS False Start – TLS 1.0, 1.1, 1.2

    The next improvement comes from the TCP Fast Open procedure, defined in RFC 7413. The RFC defines a new TCP option, containing a “Fast Open Cookie.” When a “Fast Open capable” client connects to a server for the first time, it inserts an empty cookie in the initial TCP SYN message, prompting the server to send back a valid cookie in the response. For the subsequent connections, the client copies the cookie in the TCP SYN message, and then sends data immediately. If the server recognizes the data as valid, it will accept the data and pass them to the application. When TCP Fast Open is enabled, data can be sent before the connection complete, and the responses will arrive immediately. When we combine TCP Fast Open and TLS False Start, the key negotiation is performed simultaneously with the initial TCP handshake. There is just 1-RTT before the HTTP traffic starts.

    TLS False Start with TCP Fast Open

    What’s next: 0-RTT with TLS 1.3

    TCP Fast Open is available behind an about:flags setting in Microsoft Edge in Windows Insider Preview builds 14352 and higher. You can manage the TCP Fast Open setting by navigating to about:flags in the address bar. For this build, we have enabled TCP Fast Open in Microsoft Edge for “HTTPS” connections by default in order to get more telemetry data.

    TCP Fast Open can be managed via about:flags in Microsoft Edge

    The next stage in our journey is to move from 1-RTT to 0-RTT using TLS 1.3. It turns out that doing 0-RTT safely is quite tricky—all 0-RTT solutions require sending key material and encrypted data from the client without waiting for any feedback from the sender. At a minimum, that means that adversaries can capture and replay the messages, which implies that the feature has to be used with great care. In addition to that, there are many potential pitfalls, such as compromising privacy by carrying identifiers in clear text in the Hello message, or risking future compromise if the initial encryption depends on a server public key. The IETF working group is working through these issues now, and as they are resolved we expect to see adoption calls this summer and publication of the standard a few months later.

    TLS 1.3 Session Resume combined with TCP Fast Open

    We know performance and security matter to our users and we’re committed to delivering a 0-RTT experience in Microsoft Edge through HTTP 2.0, TLS 1.3, TCP Fast Open, and TLS False Start. We’re also going to continue to work with industry leaders and experts in the standards bodies to build an interoperable TLS 1.3 solution for the web. You can try TCP Fast Open and TLS False Start on Windows Insider Preview builds today – let us know what you think!

    – Christian Huitema, Distinguished Engineer

    Source: Building a faster and more secure web with TCP Fast Open, TLS False Start, and TLS 1.3 | Microsoft Edge Dev Blog
      My System SpecsSystem Spec

  2.    16 Jun 2016 #2

    Be interesting to post some performance results for using the various techniques vis-a-vis the current default techniques for initiating the TCP handshake. Seems like either Fiddler or Wireshark should be able to provide some interesting insight here. Anybody up for an experiment?
      My System SpecsSystem Spec


Similar Threads
Thread Forum
False negative or false positive ?
Win 10 Home 10586.164 Did a Sfc /scannow. Result : found corrupted files but unable to repair some of them. Did a dism..../restorehealth. Result : Restore operation successful. Did a sfc /scannow right after dism. Result : found...
Performance & Maintenance
Solved Faster Fast Ring Builds - But How Fast?
Gabe said in the 11082 release announcement that starting January, Fast ring insiders would get builds "Faster". But how fast? A new build every 15 days or so?
Windows Insider
Upgrading to a Faster, More Secure Browsing Experience
Source: Upgrading to a Faster, More Secure Browsing Experience | Windows For Your Business
Windows 10 News
Solved Turning off secure boot/fast boot required?
As I get ready to do a clean install of 10074 I am curious about the need to disable secure boot and fast boot options. If I do disable secure boot do I need to enable legacy boot? I have had limited success with previous installs to a 2nd hard...
Installation and Setup
Our Sites
Site Links
About Us
Windows 10 Forums is an independent web site and has not been authorized, sponsored, or otherwise approved by Microsoft Corporation. "Windows 10" and related materials are trademarks of Microsoft Corp.

© Designer Media Ltd
All times are GMT -5. The time now is 11:00.
Find Us
Twitter Facebook Google+

Windows 10 Forums