Why aren't TCP sockets encrypted by default?

Question

I've been wondering this for as long as I've been programming, Why aren't TCP sockets encrypted by default? Everyone always says that using raw sockets is dangerous as all packets sent are susceptible to packet sniffing.

So why didn't the original implementation of TCP sockets include a basic form of encrypion. What I've noticed so far, is that most languages either don't provide a built in implementation which forces you to use a third party library or make it so hard for 'noobies' to implement SSL over all sockets, that most don't even bother to do so in the first place.

Even simple self signed certificates would suffice for the most basic form of protection, which could be abstracted away for new developers.

Answer 1

Modern networking follows the Seven-layer OSI model which is successful due to the principle of separation of concerns.

The value of separation of concerns is simplifying development and maintenance of computer programs. When concerns are well-separated, individual sections can be reused, as well as developed and updated independently. Of special value is the ability to later improve or modify one section of code without having to know the details of other sections, and without having to make corresponding changes to those sections.

TCP/IP is layer 4 ("Transport")

The transport layer provides the functional and procedural means of transferring variable-length data sequences from a source to a destination host via one or more networks, while maintaining the quality of service functions.

SSL/TLS is layer 6 ("Presentation")

This layer provides independence from data representation (e.g., encryption) by translating between application and network formats. The presentation layer transforms data into the form that the application accepts. This layer formats and encrypts data to be sent across a network. It is sometimes called the syntax layer.

In other words, it is a conscious design choice.

Also, TCP predates SSL by several decades. To wit, SLL keeps changing because weaknesses are found; meanwhile, TCP has remained mostly the same. The OSI model allows easier adoption of changes by keeping some things constant while varying others. If we built encryption into TCP, then it would be a far less stable protocol.

Answer 2

Why doesn't snail mail come with builtin encryption?

A socket is a simple concept which is used to make communication between multiple parties possible, i.e. just transfer messages. Insofar it is similar to snail mail, i.e. you have some sender and recipient and the message and you might have some minimal protection (envelope) which can easily be bypassed. Protecting communication against sniffing and tampering is a way more complex concept and which kind of protection is actually needed depends on the specific use case. For example sending messages to another process on the local system needs different protection than sending messages to another host in a local network or to some party on the other side of the planet where some of the routers in between are controlled by government organizations.

Therefore it makes only sense to handle the exchange of messages separate from the protection of messages to simplify communication and be flexible in the kind of protection actually needed.

Some examples of the different use cases should make it more clear why separating these concepts make sense:

• UNIX domain sockets don't need encryption because you would need to have kernel permissions to actually sniff the data, in which case you could also grab the data before encryption.
• If you are in a network with a full IPSec rollout all communication between the parties in the network is already encrypted so you don't need to add another encryption on top.
• Encryption on the internet like HTTPS needs to first have a PKI infrastructure rolled out with local trust anchors so that you could actually authenticate the peer before sending messages.
• Hop by hop encryption like you have with SMTP (mail delivery) does not protect the message against sniffing on the hops, so you additionally need end to end encryption (i.e. PGP, S/MIME).
• Unidirectional or multicast communication cannot have the kind of key exchange you have with TLS because this requires bidirectional communication.

Answer 3

Performance overhead

Encryption takes much more effort than basic networking. First, it takes computational power - running all traffic through a SSL-like channel in 1980s, when TCP gained large scale adoption, would not be practical as the processors were so much slower than currently.

However, an even larger issue is the network overhead of the SSL handshake for small requests. For small messages, the handshake to establish the encryption keys can easily be multiple times larger than the actual message, and requires more round-trips and can double the latency. This is a reason why even if the standards were redesigned today, it would make sense to have the basic network socket layers without encryption.