*** Patrick [2021-07-07 08:55]: >Or should we just run stunnel + telnetd?
Better is IPsec + telnetd (ESP + IKEv2). SSL/TLS has a very long history of awful and broken protocol design and its implementations. Only TLS 1.3 is good from cryptography point of view. Its huge complexity is overkill. IPsec from the very beginning has no any critical issues and even IKEv1 is pretty secure, however should be avoided, because of much simpler IKEv2. I have implemented TLS 1.3 and ESP+IKEv2 and the later ones has less lines of codes, however of course there was only a subset of all possible features. IPsec is transparent to any kind of transport protocol (with TLS I just can not simply secure my DNS traffic between resolver and local machine, because it is UDP (what? use completely another layer like DNSCrypt? I just add several lines to strongSwan configuration file to secure exact specified kind of traffic). It can have long lived connections, without necessity of regular handshakes. BTNS (better than nothing security https://datatracker.ietf.org/wg/btns/about/) produced RFCs with ability to use plain raw public key for the client, instead of some kind of X.509 certificate, making it some kind of anonymous and being able to use TLS-like mostly used use-case, where server is X.509-authenticated, but client is not. With setsockopt you can set your desired security level per-connection (literally per each UDP/TCP/SCTP/whatever connection) and ask for making IPsec-secured connection with specified IDr=some.bank.com (identity of responder). But all of that mostly requires you to use IPv6, where you get at least /64 subnet, no damned NATs, and you can use single ephemeral address for only single TCP connection, making it IPsec/IKE secured in transport mode with desired authentication. TLS becomes completely useless, because IPsec can take all TLS-related use-cases. -- Sergey Matveev (http://www.stargrave.org/) OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF