Encrypting TCP - A Closer Look
Problem Statement:
By default, TCP packets are not encrypted, which pose several potential security risks. Despite the growing adoption of TLS, a significant fraction of TCP traffic on the Internet remains unencrypted. This is because many legacy protocols lack the mechanism to communicate support for encryption and cannot be upgraded.
Securing data transfer within private networks is equally important. We must protect business-critical data from interception and modification within private networks to prevent a security incident with a high business impact. In a report published by McKinsey in September 2018, “Insider threat: The human element of Cyberrisk”, writes that insider threat via a company’s own employees (and contractors and vendors) is one of the largest unsolved issues in cybersecurity. It’s present in 50 percent of breaches reported in a recent study. They concluded their findings with insider threat being one of the largest problems in cybersecurity, representing a massive share of attacks and financial damage.
Proposed Solution:
The TCP Encryption Negotiation Option (TCP-ENO), RFC 8547 addresses both problems through a new TCP option providing an out-of-band, fully backward-compatible negotiation of encryption. TCP-ENO defines new parameters that can be used or configured by applications that intend to implement encryption at the transport layer. TCP-ENO provides a framework in which two endpoints can agree on a TCP encryption protocol (TEP).
TCP-ENO has been designed to achieve the following goals:
1) Enable endpoints to negotiate the use of a separately specified TCP encryption protocol (TEP) suitable for either “opportunistic security” of TCP communications or stronger security of applications willing to perform endpoint authentication.
Why is this a big deal?
Historically, Internet security protocols have “all or nothing” cryptographic protection against both passive and active attacks. The problem with this model is that such protocols will either achieve full protection or total failure to communicate. This results in security protocols being disabled and leading to cleartext communication. For example, current cryptographic protection uses common methods of authentication such as Certification Authority (CAs). Many organizations are not willing to trust every CA or they don’t have a mutually trusted CA. Today, one of the big challenges in the industry is expired SSL/TLS certificates, which usually lead to a communication failure. “Opportunistic Security” use encryption even when authentication is not available, and uses authentication when possible, removing barriers to traditional encryption.
2) Transparently fall back on unencrypted TCP when not supported by both endpoints. TCP-ENO uses an “option” in the TCP header - A SYN-form ENO option and a non-SYN-form ENO option. A host supporting TCP-ENO must send non-SYN-form ENO option in the third segment of a three-way handshake. The TCP connection will automatically fall back on unencrypted TCP if the first ACK received does not contain ENO option or SYN does not contain a valid TEP identifier (If TCP-ENO succeeds, it will negotiate a unique 7-bit TEP identifier) or a SYN is received with incompatible global sub-options. If a SYN segment contains over one TCP ENO option, it assumes the other end does not support encryption and falls back to clear text TCP connections.
3) TCP-ENO will provide out-of-band connections and improve authentication mechanisms in the presence of TCP-level encryption. TCP uses the URGENT flag to provide OOB (out-of-band) data. For example FTP, where the user may be in the middle of a large transfer but decides to abort. The abort is sent as OOB data, meaning the server and client will abort the connection without transmitting unprocessed data.
4) TCP-ENO defines roles for the two ends of a TCP connection for encryption or authentication purposes. TCP-ENO uses abstract roles called “A” and “B” to distinguish the two ends of a TCP connection. These roles are determined by the “b” bit in the global sub-option. A “b” bit can have a value of b=0 or b=1, 0 being active and 1 being passive. A normal TCP three-way handshake involves one active and one passive opener. To elaborate on active open and passive open, when a client attempts to connect with a server, the server must first bind to and listen at a port to open it up for connections: this is called a passive open. Once the passive open is established, a client may initiate an active open. Applications performing a simultaneous open that desire encryption using TCP=ENO, must ensure one endpoint sets option b=1 despite being an active opener. A and B roles help implement asymmetric behavior by the two hosts.
5) TCP-ENO defines a standard negotiation transcript that TEP can use to defend against tampering or man-in-the-middle attack. To prevent replay attacks and authenticated session IDs from being used out of context, unique session IDs are created. This prevents one end of the connection from maliciously manipulating the protocol to create duplicate session IDs. Session IDs are a minimum of 33 bytes long. Session IDs depend on negotiation transcript and depend upon public key cryptography such as Diffie-Hellman and other asymmetric cryptographic parameters. Application developers who want to use TCP-ENO must authenticate the TCP endpoints by incorporating the values of the session ID and TCP-ENO role (A or B) into higher-layer authentication mechanisms.
Conclusion:
TCP-ENO addresses several important security risks but the mere presence of TEP does not mean the connection is secure. “Opportunistic encryption” will not protect against eavesdropping by ISPs that terminate TCP connections and proxy them or downgrade connections to unencrypted). It will not protect against targeted attacks that use spoofing to redirect a connection leading to a man-in-the-middle attack. TCP-ENO recommends verifying session ID’s in achieving stronger security. Any application relying on ENO for communication security must implement session IDs into its endpoint authentication and must also take collision resistance of hash functions used for session IDs into account.
References:
?1) https://insights.sei.cmu.edu/insider-threat/2017/01/2016-us-state-of-cybercrime-highlights.html
2) https://tools.ietf.org/html/rfc8547#page-25