SSL and socat

2021/07/24

... a tiny extension to the article about self-signed certs.

socat is awesome.

You might know netcat, the tool that turns network connections into pipes. (... arguably, they should have been files anyway... see Plan 9. Sadly, they aren't.)

Meanwhile, there is SSH. Which is, thinking about it, a surprisingly anti-UNIX tool. Namely, it's this monolithic package of a port multiplexer, proxy server, and secure pipe implementation, the latter also handling authentication in various ways. In this article, we'll create a secure shell service that is... likely worse than SSH in every possible way, apart from UNIXyness.

We assume that we have a self-signed cert available... if not, go read the article on how to create one. This should produce a certificate (CRT) file, along with a private key (KEY).

You can then use socat to start our server:


~$ socat \
  openssl-listen:12347,reuseaddr,cert=the_one.crt,key=the_one.key,cafile=the_one.crt \
  system:bash,pty,stderr

What this does is create a server, one side of which is listening to SSL connections. Our certificate authority happens to be the same as the cert we're using; in practice, this could be something somewhat more sophisticated, with actually different keys on both sides. Meanwhile, we're launching a bash process on the other side every time someone connects.

To connect to this as a client, we can run


~ $ socat stdio \
  openssl:localhost:12347,cafile=the_one.crt,cert=the_one.crt,key=the_one.key

... to pipe what's coming out of the connection to stdout, and forwarding keyboard events to the remote process.

This, sadly, still only gives us a very low-quality terminal: no line editing, and it doesn't even really catch Ctrl-C properly... not to speak of how ugly htop looks like on it. We can make this better by using pseudoterminal devices... coming up in Part 2!

This is post no. 20 for Kev Quirk's #100DaysToOffload challenge.

... comments welcome, either in email or on the (eventual) Mastodon post on Fosstodon.