If you really want to use true telnet over TLS on the registered port of 992, then get a regular telnet client and telnet to a custom port on local host.
On that custom port, run stunnel in client mode. You can run this either in an inetd/socket activation setup, or in daemon mode that actively calls listen()
That stunnel should be configured to point at your telnet-ssl server (on port 992 if you want it accurately fingerprinted).
That telnet-ssl server should also be stunnel, and it should be configured to run telnetd in inetd mode.
That is the correct way to implement telnet-ssl. I would not trust any telnet client or server that was linked directly to a TLS library.
You must specify the options `-verify_return_error -verify_hostname <hostname>` to get even a semblance of security; however I don't know if they are sufficient, and the fact that they are not enabled by default is a massive red flag that tells you this tool was not designed to be secure.
As an alternative, I suggest using `gnutls-cli <host>[:<port>]` or `socat - SSL:<host>:<port>` (if they are installed; unfortunately they are not common). They pass the "Certificate" tests on https://badssl.com/ except for "pinning-test".
I mean, I assume at least once since you know about it. But for me, I don’t think I’ve ever typed a singular capital R anywhere on purpose.
It’s like nc on steroids. TLS, Unix sockets, and just about anything else that involves a digital cable connecting two streams of data.
When in doubt, just add more forking and socat!