Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I would like to test client connections with IMAP over SSL, HTTPS, and other secure text-based Internet protocols over SSL/TLS, the same way I would using Telnet or Netcat if they were not tunneled over a secure protocol. Is there a way to get Telnet or Netcat to go through SSL/TLS such as with a pipe or alternate program?

share|improve this question
Same on serverfault: serverfault.com/questions/102032/… –  Ciro Santilli 六四事件 法轮功 Dec 8 '14 at 23:18

4 Answers 4

First, there is no Telnet/Netcat client – they are two separate programs. Second, there is no "the" – there exist at least 10 different Telnet clients and at least 6 different Netcat versions (original netcat, GNU netcat, OpenBSD netcat, nmap's ncat; forgot the rest)

  • GnuTLS has a TLS client tool on Linux:

    gnutls-cli imap.gmail.com -p 993

    Use -s for STARTTLS; you will need to manually enter the necessary protocol commands and press CtrlD when ready.

    Note that GnuTLS verifies the server certificate by default, but other tools below do not.

  • OpenSSL has a TLS client tool:

    openssl s_client -connect imap.gmail.com:993

    This is available for all operating systems. STARTTLS is supported via -starttls imap or -starttls smtp options, and the program will automatically negotiate it.

  • socat:

    socat openssl:imap.gmail.com:993 stdio

    readline mode can be used for convenience:

    socat ssl:imap.gmail.com:993 readline

    STARTTLS is not supported.

  • ncat from nmap supports TLS (but not STARTTLS):

    ncat --ssl imap.gmail.com 993
  • Some Telnet clients, such as the telnet-ssl package on Debian, also support TLS:

    telnet-ssl -z ssl imap.gmail.com 993

    STARTTLS can be activated using starttls from the Ctrl ] escape menu.

share|improve this answer
I wish I could simply favorite your answer instead of the question that the asker didn't even bother marking as accepted. –  Sammitch Nov 19 '14 at 22:54

In case you do not trust your SSL implementation (heartbleed), you can use GnuPG for encryption in combination with the traditional netcat.

On the receiving side, execute

netcat -l -p 12345 | gpg -d | ...

and on the sending side, execute

... | gpg -c | netcat destination.example.com 12345

Parameters for netcat depend on which implementation you use. For GnuPG, arguments -c and -d are used for symmetric encryption/decryption and you have to enter the same password on both sides to pipe data through gpg.

Pro tip: pipe your data through a stream compressor like gzip/gunzip or xz/unxz (compress before encryption, decompress after decryption) if you have "more" CPU power than bandwidth.

share|improve this answer
Sorry but that's not even useful for this question. GnuPG cannot talk to existing TLS-capable servers, nor easily do bidirectional communication. As for compression, it might be a bad idea for network streams (see BEAST attack); however, GnuPG will gzip data automatically, as it's meant for storage. –  grawity Apr 14 at 12:17
that's an interesting alternative to ssl! –  barlop Apr 14 at 12:23

Yeah there's a program called stunnel

it has a configuration file,

you tell it what port to listen on, what port to forward to.

it works for client side, or server side, or both.

so it can turn a server that doesn't support ssl, into effectively one that does.

or a client that doesn't support ssl, effectively into one that does.

or make both a client and server have an ssl connection.

share|improve this answer

You may want to look at openssl s_client, e.g.

# openssl s_client -connect https://dummy.com:8443
share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.