Hi Peter & all

I’ve only been looking at stunnnel a short while but looking at a simple server setup it appears to do the following;

Scenario 1
Client connects on SSL - stream is forwarded as unencrypted

Scenario 2
Client connects unencrypted and does / offers STARTTLS - stream is forwarded as unencrypted

Scenario 3
Client connects unencrypted and does NOT do or offer a STARTTLS - server disconnects


Scenario 1 & 2 work with stunnel as intended.  What I’m looking to do is make scenario 3 connect to an alternative location rather than disconnect.



So looking at SMTP the disconnection seems to be when a client connects unencrypted and does a helo/ehelo which doesn’t end in STARTTLS.


What I’ve not managed to find yet is the point in the code where stunnel establishes the connection to the real server and if that is already connected by the time stunnel makes its disconnection decision.

Mark

On 3 Feb 2017, at 08:40, Peter Pentchev <[email protected]> wrote:

On Thu, Feb 02, 2017 at 09:54:38PM +0000, Mark Boyce wrote:
Hi All

Wondering if there’s a way to pass an unencrypted connections traffic to
an alternative location if a client does not SSL/TLS with the stunnel
server?

So considering stunnel running as a server to wrap an unencrypted SMTP
server.  If the SMTP client/server talks SSL/TLS all is good and as
expected.  If the client tries to talk without encryption it gets
disconnect.

Is there any way to send this traffic elsewhere rather than
disconnecting the client?  So that stunnel is adding an SSL/TLS option
to a service rather than enforcing it. Splitting the traffic to
destination servers based on if the client was encrypted or not.

stunnel itself cannot do this; one might write a trivial wrapper to
do it, but I believe that there might be a larger problem here.

You mention SMTP.  Doesn't the SMTP protocol *require* the server to
send its banner (220 Hi there, I'm an SMTP server, who are you?) before
the client sends its first command?  I think that there are servers
that actually enforce this requirement for spam control - some spambots
are dumb enough to just open a TCP connection and blast a series of
SMTP commands without waiting for the server's greeting (to save on
round-trip times and such), and some servers deliberately delay their
220 greeting for a little while and immediately reject the connection
if the client tries to talk to them before that.

So, um, how does the redirector know whether this is an SSL/TLS client
or not if the server has to send its greeting first? :)  Of course, one
could do something like "wait for a second or two, see if the client
starts an SSL/TLS session; if not, pass it on to the unencrypted server
thing", but this will fail badly if the connection has a really high
latency or the client machine is badly overloaded so that it doesn't
send its SSL/TLS Client Hello in time, and it would also enforce
an additional delay on *every* unencrypted connection.

G'luck,
Peter

--
Peter Pentchev  [email protected] [email protected] [email protected]
PGP key:        http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13

Mark
-- 
Mark Boyce
Dark Origins Ltd
e: [email protected]
t: 0845 0043 043
f: 0845 0043 044