We get stuck opening the socket

tailscale.com
5 min read
fairly easy
I have a soft spot for the Unix sockets API. Yes, it is clunky to get started and has grown some odd options over the decades. It is usually buried now under higher level programming layers. But at the heart of it is a small and versatile interface that is easy to build on and easy to recreate:
read(socket, bytes)

write(socket, bytes)

What bytes, how many bytes, and in what order are up to you. Under the hood TCP gives you reliable transmission. It is a quick and fun way to write a network program.

Streams of bytes can contain discrete request-response messages, be used as a message bus, A/V streams, they can be multiplexed and demultiplexed… there are many ways to use them. As a bonus, most programming languages can represent streams of bytes efficiently, so sockets make for good protocol boundaries. It also has the great benefit of being a stable technology. I first bound a socket in the mid-90s, and the same code works today.

Unfortunately, the OS socket API has become less useful as the internet has become ubiquitous. There are several culprits.

The first problem is addressing asymmetry. Most devices are buried behind NAT today, meaning that only an ever-smaller set of "servers" can listen on a socket others can connect to. That's fine for some programs, but breaks other programs. (It's especially unfortunate for some of the more fun games you can play where, as part of a protocol you create new temporary sockets.)

The second problem is the lack of good authorization and authentication in the fundamental mechanisms used to create sockets. The core addressing scheme for network sockets is an IP address, port number pair. We have DNS to give nice names to the IP addresses, and some (inflexible) protocol conventions for picking port numbers. Neither IP addresses nor domain names on the public internet are adequate to ensure who you are connecting to is who you think you are connecting to. The converse problem holds: when a server receives a connection, who connected to it? On corporate or university networks of the 90s, you could trust the intermediaries and use IP addresses for this security. That simply does not hold on the internet today.

The third problem today is that communication should be end-to-end encrypted. The result is anything can…
Tailscale
Read full article