Best current practices for TCP-ENO configuration

The TCP Encryption Negotiation Option (TCP-ENO) permits hosts to negotiate encryption of a TCP connection. TCP-ENO is designed to fail by reverting to unencrypted TCP. Such behavior is necessary for incremental deployment, and is no worse than the status quo in which there is no TCP-layer encryption. However, one outcome worse than the status quo would be for TCP-ENO connections to fail completely where unencrypted connections would work. Fortunately, if TCP-ENO is not supported by both endpoints, or if middleboxes strip the ENO option from packets, then implementations simply revert to unencrypted TCP upon receiving a SYN or initial ACK segment without an ENO option. This fallback approach also applies to interception proxies , which typically terminate TCP connections and hence will not include ENO in their SYN segments if they do not know about it. However, given that the goal of TCP-ENO is to encrypt previously plaintext traffic, there is always the possibility that a middlebox performing deep packet inspection could shut down connections when the ciphertext does not resemble an expected higher-level application protocol such as HTTP. Such middleboxes would cause TCP-ENO connections to fail. This document describes a technique for probing the network so as to enable TCP-ENO only in places where middleboxes do not induce such failures. TCP-ENO configuration can then be used to avoid such failures.

Hosts can determine whether or not a network path breaks TCP-ENO with the help of an external server. A precedent for probing middlebox behavior is the STUN protocol , which applications use to characterize NAT. STUN relies on having a known, publicly-accessible server beyond any locally administered middleboxes. Like STUN, TCP-ENO probing requires a known external server running an agreed upon protocol. This should be done using HTTP as the protocol, and responding to the path /tcp-eno/session-id with a response of type text/plain. Upon successful TCP-ENO negotiation, servers should reply with the string "encrypted " followed by a lower-case hexadecimal encoding of the tcpcrypt session ID followed by a newline. For connections on which TCP-ENO fails, the same path should return the string "unencrypted\n" (with no session ID).

STUN is typically invoked by applications that require peer-to-peer communication to decide whether they can accept incoming connections. For TCP-ENO, which affects all TCP connections, it makes more sense to probe for network compatibility at the time network interfaces are configured by DHCP , stateless address autoconfiguration , or other mechanisms. Many DHCP implementation already provide hooks through which such probes can be configured. Upon interface configuration, a host should probe a known external server to request /tcp-enno/session-id. If the request works with TCP-ENO disabled but hangs or resets with TCP-ENO enabled, then TCP-ENO should be disabled for the host. Otherwise, if the probe succeeds, then even if it returns "unencrypted", TCP-ENO should be enabled (for the possible benefit of local connections), as middleboxes may simply be stripping off the option. Hosts should perform the above probe twice, using both port 80 and a different port, we suggest 8080, on the same server. Given the prevalence of interception proxies on port 80, port 80 may experience entirely different failure modes from other ports. If the port 80 probe fails, TCP-ENO should be disabled for port 80. If the other probe fails, TCP-ENO should be disabled entirely.

The proposed mechanism allows an attacker to convince hosts to disable TCP-ENO, which makes subsequent eavesdropping easier. However, this is but one of several ways attackers have to downgrade TCP-ENO connections. Until TCP-level encryption has been more widely deployed and applications authenticate the session ID, TCP-ENO's protection will primarily be against passive eavesdroppers anyway. Servers providing ENO path testing will have knowledge of where machines are using TCP-ENO, which has potential privacy implications.