On 12/2/20 9:43 PM, VanguardLH wrote:
> sTunnel does not support SMTP, IMAP, POP, Exchange, Gmail API, FTP,
> Gopher, NTP, Telnet, DNS, HTTP/S, NNTP, or any other inter-process
> communication protocol. sTunnel is only to establish a connection
> between endpoints to establish an encrypted session (aka pipe).
That's what I originally thought too.
Then persuant to Tekkie's comments, I checked stunnel's manual page and
found that stunnel does support enough of (at least) the following
application layer protocols to be able to establish the TLS tunnel.
E.g. speak enough SMTP to send an EHLO and STARTTLS. To quote the man page:
protocol = PROTO
application protocol to negotiate TLS
This option enables initial, protocol-specific negotiation of TLS
encryption. The protocol option should not be used with TLS encryption
on a separate port.
Currently supported protocols:
This tells me that stunnel knows how to present an unencrypted SMTP port
to a client and connect it to an SMTP server that requires STARTLS on
port 25 or 587.
> The communication protocol goes over that encrypted session, and can
> be any protocol. sTunnel is a TLS/SSL *tunneling* service that runs
> as a proxy on your host (or a host in your intranet if sharing it).
> That's it!
But, as described above, there is some limited application layer
protocol knowledge and support to be able to establish the tunnel.
E.g. you can't connect to an SMTP server on ports 25 or 587 and
immediately start speaking TLS. You *MUST* speak enough SMTP to be able
to transition from unencrypted to encrypted connection.
> Once the endpoints establish an encrypted session, the clients using
> that tunneling use whatever protocol (command set) they want.
The operative phrase being "Once the endpoints establish an encrypted
session...". The application specific protocol is required on some
ports to be able to do that.
> Likewise, your e-mail client will be sending the same command set to
> the server whether the connection is encrypted or not.
Not quite. It depends if stunnel is in the mix or not. It depends if
your client is trying to negotiate encryption or not. E.g. your client
won't use STARTTLS (for SMTP) if you don't tell it to do encryption or
if stunnel does the encryption for you. Conversely your email client
will use STARTTLS if you tell it to use encryption on ports 25 or 587.
> Whether your e-mail client establishes a non-encrypted or encrypted
> session with the server, the same set of commands get used for whatever
> protocol you configured for use by an account defined within that
> e-mail client.
Nope. Having the client do the encryption (vs stunnel) requires a
superset of commands compared to what is used for unencrypted
connections. Specifically "STARTTLS", which is used by the client to
establish encryption to ports 25 and 587, is decidedly NOT used for
unencrypted communications. Ergo "the same set of commands get used for
whatever protocol you configured" is factually incorrect.
There is also the problem that SMTP, IMAP, and POP3 all use different
commands. So your "the same set of commands get used for whatever
protocol..." statement is tenuous at best or misleading if not wrong.
> The communication protocol doesn't change because the session is
If something other than stunnel does the encryption, yes it does.
> sTunnel is NOT an e-mail client issuing commands to an e-mail server.
That can't possibly be correct. stunnel does (and will if told to do
so) issue just enough application specific protocol to establish the
secure connections. E.g. "EHLO" & "STARTTLS" for SMTP.
> sTunnel is just the pipe for encrypting the traffic between endpoints.
Yes. But stunnel must use the absolute minimum application protocol to
be able to establish said pipe.
> It doesn't support the IMAP, POP, SMTP, Exchange, Gmail API, or other
> e-mail protocols.
Per the manual page, yes, stunnel does support IMAP, POP3, SMTP.
Aside: Exchange can be it's own proprietary protocol or the
aforementioned IMAP, POP3, and SMTP.
> That's not its purpose. You will never see sTunnel listed as an
> alternative e-mail client or server.
On the contrary, speaking an absolute minimum to establish the encrypted
connection via the application specific protocols to enable encrypted
connections *IS* stunnel's purpose.
I just confirmed with the following (redacted) configuration that /yes/
*stunnel* is speaking SMTP specific commands.
foreground = yes
client = yes
accept = 127.0.0.1:2525
connect = REDACTED:587
protocol = smtp
1) started stunnel in the first window
2) started tcpdump to sniff the traffic to the host and port in the
3) telneted to 127.0.0.1 port 2525 in a third window and spoke smtp
I can confirm that stunnel did in fact issue the following SMTP "EHLO
localhost" and "STARTTLS". /I/ did *NOT* issue these commands.
/stunnel/ *did* issue these commands.
This proves beyond a shadow of a doubt that stunnel does have limited
support for application protocols that require this type of behavior to
establish an encrypted connection.
> You define in sTunnel its listening ports (input and output). The
> "[smtp]", "[imap]", "[pops]" and so on are just labels. You could call
> them "[george]", "[Gmail-poppy]", "[lalaland]", or whatever you want.
> The labels have nothing to do with whichever protocols are used through
> that proxy across those ports. A self-stick tag stuck to your shirt at
> a seminar does not force you to communicate using a specific language.
However the "protocol = smtp" statement (in whatever label you happen to
use) /does/ mean that stunnel will speak the absolute minimum SMTP to
establish the encrypted connection, which is then presented as clear
text to the client connecting to the port from accept parameter.