Obfuscated TCP

Last updated

Obfuscated TCP (ObsTCP) was a proposal for a transport layer protocol which implements opportunistic encryption over Transmission Control Protocol (TCP). It was designed to prevent mass wiretapping and malicious corruption of TCP traffic on the Internet, with lower implementation cost and complexity than Transport Layer Security (TLS). In August 2008, IETF rejected the proposal for a TCP option, suggesting it be done on the application layer instead. [1] The project has been inactive since a few months later.

Contents

In 2010 June, a separate proposal called tcpcrypt has been submitted, which shares many of the goals of ObsTCP: being transparent to applications, opportunistic and low overhead. It requires even less configuration (no DNS entries or HTTP headers). Unlike ObsTCP, tcpcrypt also provides primitives down to the application to implement authentication and prevent man-in-the-middle attacks (MITM). [2]

Historical origin

ObsTCP was created by Adam Langley. The concept of obfuscating TCP communications using opportunistic encryption evolved through several iterations. The experimental iterations of ObsTCP used TCP options in 'SYN' packets to advertise support for ObsTCP, the server responding with a public key in the 'SYNACK'. An IETF draft protocol was first published in July 2008. Packets were encrypted with Salsa20/8, [3] and signed packets with MD5 checksums. [4]

The present (third) iteration uses special DNS records (or out of band methods) to advertise support and keys, without modifying the operation of the underlying TCP protocol. [5]

Encryption features

ObsTCP is a low cost protocol intended to protect TCP traffic, without requiring public key certificates, the services of Certificate Authorities, or a complex Public Key Infrastructure. It is intended to suppress the use of undirected surveillance to trawl unencrypted traffic, rather than protect against man in the middle attack.

The software presently supports the Salsa20/8 [3] stream cipher and Curve25519 [6] elliptic-curve Diffie Hellman function.

Comparison with TLS/SSL/HTTPS

FeatureObsTCPSSL/TLS/HTTPS
Public Key InfrastructureDoes not require a signed public key certificateRequires that a signed public key certificate is purchased (or self-signed certificate is used)
Web browser supportPatched versions of Firefox available [7] Widely supported by all popular web browsers
Web server supportRequires patches/server upgrades for lighttpd and Apache [8] Widely supported by popular web servers
Network latencyNil additional round trips per connection (though DNS lookup may be required to obtain key advertisement)One or two additional round trips per connection
Encryption speedVery fast cryptographySlower
TCP portCan use any TCP portTypically uses port 443, but can use any TCP port
Security characteristicsDoes not resist some man-in-the-middle attacksResists man-in-the-middle attacks

Connection establishment

A server using ObsTCP advertises a public key and a port number.

A DNS 'A record' may be used to advertise server support for ObsTCP (with a DNS 'CNAME record' providing a 'friendly' name). HTTP header records, or cached/out of band keyset information may also be used instead.

A client connecting to an ObsTCP server parses the DNS entries, uses HTTP header records, or uses cached/out of band data to obtain the public key and port number, before connecting to the server and encrypting traffic.

See also

Related Research Articles

The Domain Name System (DNS) is a hierarchical and distributed naming system for computers, services, and other resources in the Internet or other Internet Protocol (IP) networks. It associates various information with domain names assigned to each of the associated entities. Most prominently, it translates readily memorized domain names to the numerical IP addresses needed for locating and identifying computer services and devices with the underlying network protocols. The Domain Name System has been an essential component of the functionality of the Internet since 1985.

The Secure Shell Protocol (SSH) is a cryptographic network protocol for operating network services securely over an unsecured network. Its most notable applications are remote login and command-line execution.

The Transmission Control Protocol (TCP) is one of the main protocols of the Internet protocol suite. It originated in the initial network implementation in which it complemented the Internet Protocol (IP). Therefore, the entire suite is commonly referred to as TCP/IP. TCP provides reliable, ordered, and error-checked delivery of a stream of octets (bytes) between applications running on hosts communicating via an IP network. Major internet applications such as the World Wide Web, email, remote administration, and file transfer rely on TCP, which is part of the Transport Layer of the TCP/IP suite. SSL/TLS often runs on top of TCP.

In computing, Internet Protocol Security (IPsec) is a secure network protocol suite that authenticates and encrypts packets of data to provide secure encrypted communication between two computers over an Internet Protocol network. It is used in virtual private networks (VPNs).

<span class="mw-page-title-main">Network address translation</span> Protocol facilitating connection of one IP address space to another

Network address translation (NAT) is a method of mapping an IP address space into another by modifying network address information in the IP header of packets while they are in transit across a traffic routing device. The technique was originally used to bypass the need to assign a new address to every host when a network was moved, or when the upstream Internet service provider was replaced, but could not route the network's address space. It has become a popular and essential tool in conserving global address space in the face of IPv4 address exhaustion. One Internet-routable IP address of a NAT gateway can be used for an entire private network.

Transport Layer Security (TLS) is a cryptographic protocol designed to provide communications security over a computer network. The protocol is widely used in applications such as email, instant messaging, and voice over IP, but its use in securing HTTPS remains the most publicly visible.

<span class="mw-page-title-main">Daniel J. Bernstein</span> American mathematician, cryptologist and programmer

Daniel Julius Bernstein is an American German mathematician, cryptologist, and computer scientist. He is a visiting professor at CASA at Ruhr University Bochum, as well as a research professor of Computer Science at the University of Illinois at Chicago. Before this, he was a professor in the department of mathematics and computer science at the Eindhoven University of Technology.

Opportunistic encryption (OE) refers to any system that, when connecting to another system, attempts to encrypt communications channels, otherwise falling back to unencrypted communications. This method requires no pre-arrangement between the two systems.

Opportunistic TLS refers to extensions in plain text communication protocols, which offer a way to upgrade a plain text connection to an encrypted connection instead of using a separate port for encrypted communication. Several protocols use a command named "STARTTLS" for this purpose. It is a form of opportunistic encryption and is primarily intended as a countermeasure to passive monitoring.

Server Name Indication (SNI) is an extension to the Transport Layer Security (TLS) computer networking protocol by which a client indicates which hostname it is attempting to connect to at the start of the handshaking process. The extension allows a server to present one of multiple possible certificates on the same IP address and TCP port number and hence allows multiple secure (HTTPS) websites to be served by the same IP address without requiring all those sites to use the same certificate. It is the conceptual equivalent to HTTP/1.1 name-based virtual hosting, but for HTTPS. This also allows a proxy to forward client traffic to the right server during TLS/SSL handshake. The desired hostname is not encrypted in the original SNI extension, so an eavesdropper can see which site is being requested. The SNI extension was specified in 2003 in RFC3546.

In cryptography, Curve25519 is an elliptic curve used in elliptic-curve cryptography (ECC) offering 128 bits of security and designed for use with the elliptic curve Diffie–Hellman (ECDH) key agreement scheme. It is one of the fastest curves in ECC, and is not covered by any known patents. The reference implementation is public domain software.

DNSCurve is a proposed secure protocol for the Domain Name System (DNS), designed by Daniel J. Bernstein.

A cipher suite is a set of algorithms that help secure a network connection. Suites typically use Transport Layer Security (TLS) or its now-deprecated predecessor Secure Socket Layer (SSL). The set of algorithms that cipher suites usually contain include: a key exchange algorithm, a bulk encryption algorithm, and a message authentication code (MAC) algorithm.

In computer networking, tcpcrypt is a transport layer communication encryption protocol. Unlike prior protocols like TLS (SSL), tcpcrypt is implemented as a TCP extension. It was designed by a team of six security and networking experts: Andrea Bittau, Mike Hamburg, Mark Handley, David Mazières, Dan Boneh and Quinn Slack. Tcpcrypt has been published as an Internet Draft. Experimental user-space implementations are available for Linux, Mac OS X, FreeBSD and Windows. There is also a Linux kernel implementation.

DNSCrypt is a network protocol that authenticates and encrypts Domain Name System (DNS) traffic between the user's computer and recursive name servers. It was originally designed by Frank Denis and Yecheng Fu.

HTTP/2 is a major revision of the HTTP network protocol used by the World Wide Web. It was derived from the earlier experimental SPDY protocol, originally developed by Google. HTTP/2 was developed by the HTTP Working Group of the Internet Engineering Task Force (IETF). HTTP/2 is the first new version of HTTP since HTTP/1.1, which was standardized in RFC 2068 in 1997. The Working Group presented HTTP/2 to the Internet Engineering Steering Group (IESG) for consideration as a Proposed Standard in December 2014, and IESG approved it to publish as Proposed Standard on February 17, 2015. The HTTP/2 specification was published as RFC 7540 on May 14, 2015.

DNS-based Authentication of Named Entities (DANE) is an Internet security protocol to allow X.509 digital certificates, commonly used for Transport Layer Security (TLS), to be bound to domain names using Domain Name System Security Extensions (DNSSEC).

QUIC is a general-purpose transport layer network protocol initially designed by Jim Roskind at Google, implemented, and deployed in 2012, announced publicly in 2013 as experimentation broadened, and described at an IETF meeting. QUIC is used by more than half of all connections from the Chrome web browser to Google's servers. Microsoft Edge and Firefox support it. Safari implements the protocol, however it is not enabled by default.

Secure Reliable Transport (SRT) is an open source video transport protocol that utilises the UDP transport protocol.

Application Layer Transport Security (ALTS) is a Google-developed authentication and transport encryption system used for securing Remote Procedure Call (RPC) within Google machines. Google started its development in 2007, as a tailored modification of TLS.

References

  1. ↑ Adam Langley (2008-08-15). "Sorry folks, I think Obfuscated TCP died". Obfuscated TCP development blog.
  2. ↑ Andrea Bittau; et al. (2010-08-13). The case for ubiquitous transport-level encryption (PDF). 19th USENIX Security Symposium.
  3. 1 2 "Snuffle 2005". cr.yp.to. Retrieved 2009-05-08.
  4. ↑ Eddy, Wesley; Langley, Adam. "Extending the Space Available for TCP Options". IETF. Retrieved 2015-02-07.
  5. ↑ "Obfuscated TCP History". Google. Oct 2, 2008. Archived from the original on 2009-01-08. Retrieved 2009-05-08.
  6. ↑ "Curve25519: high-speed elliptic-curve cryptography". cr.yp.to. Retrieved 2009-05-08.
  7. ↑ "Obfuscated TCP Clients: Firefox". Google. Retrieved 2009-05-08.
  8. ↑ "Installing ObsTCP using the ObsTCP transport layer". Google. Retrieved 2009-05-08.
This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.