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.
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.
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.
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. TCP Fast Open is currently off by default in Microsoft Edge, but we may adjust this in future preview builds in order to get more telemetry data.
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 server. 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.
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