*** 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
Received on Wed Jul 07 2021 - 21:05:08 CEST