Enable or Disable TCP Fast Open for Microsoft Edge  

    Enable or Disable TCP Fast Open for Microsoft Edge

    Enable or Disable TCP Fast Open for Microsoft Edge

    How to Enable or Disable TCP Fast Open for Microsoft Edge in Windows 10
    Published by Category: Browsers & Email
    12 Nov 2017
    Designer Media Ltd

    How to Enable or Disable TCP Fast Open for Microsoft Edge in Windows 10

    warning   Warning
    This tutorial is no longer valid in Windows 10 build 16299.15.
    information   Information
    Microsoft Edge is a new web browser that is available across the Windows 10 device family. It is designed for Windows 10 to be faster, safer, and compatible with the modern Web.

    TCP Fast Open, TLS False Start, and TLS 1.3 can improve both performance and security in Microsoft Edge.

    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.

    For more information, see: Building a faster and more secure web with TCP Fast Open, TLS False Start, and TLS 1.3 | Microsoft Edge Dev Blog

    This tutorial will show you how to enable or disable TCP Fast Open for a faster and more secure web in Microsoft Edge for your account in Windows 10.

    Here's How:

    1. Open the Microsoft Edge app.

    2. Type about:flags in the address bar, and press Enter. (see screenshot below)

    3. Check (enable) or uncheck (disable - default) Enable TCP Fast Open for what you want.

    4. Close and reopen Microsoft Edge to apply.

    Enable or Disable TCP Fast Open for Microsoft Edge-microsoft_edge_tcp_fast_open.png

    That's it,

  1. Posts : 30

    that is no any more in build 16299.19
      My Computer

  2. 910
    Posts : 3
    Windows 10 PRO x64

    same problem here
      My Computer

  3. Posts : 3
    Windows 10 Spyware Edition

    Performance yes, but TLS False start does not improve security, it does the opposite; Firefox Hardening Guide 2018

    Disable TLS False Start

    This is because it does not allow the client to fully complete its handshake before starting the actual session. There is more info here from the IETF: https://tools.ietf.org/html/rfc7918#section-4 (See section 5. Security Considerations)

    TCP fast open will also reduce privacy for the server and client will store cookies that can be used to link former and subsequent connections;

    5. TLS False State Security Considerations

    In a TLS handshake, the Finished messages serve to validate the
    entire handshake. These messages are based on a hash of the
    handshake so far processed by a Pseudorandom Function (PRF) keyed
    with the new master secret (serving as a Message Authentication Code
    (MAC)) and are also sent under the new Cipher Spec with its keyed
    MAC, where the MAC key again is derived from the master secret. The
    protocol design relies on the assumption that any server and/or
    client authentication done during the handshake carries over to this.
    While an attacker could, for example, have changed the cipher suite
    list sent by the client to the server and thus influenced cipher
    suite selection (presumably towards a less secure choice) or could
    have made other modifications to handshake messages in transmission,
    the attacker would not be able to round off the modified handshake
    with a valid Finished message: every TLS cipher suite is presumed to
    key the PRF appropriately to ensure unforgeability. Verifying the
    Finished messages validates the handshake and confirms that the
    handshake has not been tampered with; thus, secure encryption is
    bootstrapped from secure authentication.

    Langley, et al. Informational [Page 5]

    RFC 7918 TLS False Start August 2016

    Using False Start interferes with this approach of bootstrapping
    secure encryption from secure authentication, as application data may
    have already been sent before Finished validation confirms that the
    handshake has not been tampered with -- so there is generally no way
    to be sure that communication with the expected peer is indeed taking
    place during the False Start. Instead, the security goal is to
    ensure that if anyone at all can decrypt the application data sent in
    a False Start, it must be the legitimate peer. While an attacker
    could be influencing the handshake (restricting cipher suite
    selection, modifying key exchange messages, etc.), the attacker
    should not be able to benefit from this. The TLS protocol already
    relies on such a security property for authentication; with False
    Start, the same is needed for encryption. This motivates the rules
    put forth in the following subsections.

    It is prudent for applications to be even more restrictive. If
    heuristically a small list of cipher suites and a single protocol
    version is found to be sufficient for the majority of TLS handshakes
    in practice, it could make sense to forego False Start for any
    handshake that does not match this expected pattern, even if there is
    no concrete reason to assume a cryptographic weakness. Similarly, if
    handshakes almost always use ephemeral Elliptic Curve Diffie-Hellman
    (ECDH) over one of a few named curves, it could make sense to
    disallow False Start with any other supported curve.
      My Computer

  4. Posts : 3
    Windows 10 Spyware Edition

    TCP fast open is another security threat: TCP FastOpen Security : The Grumpy Troll
      My Computer


  Related Discussions
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 10:17.
Find Us

Windows 10 Forums