Re: Default passthrough to different destination?

Peter Pentchev <[email protected]> Fri, 3 Feb 2017 10:40:57 +0200
Newsgroups	gmane.network.stunnel.user
Message-ID	<[email protected]>
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

_______________________________________________
stunnel-users mailing list
[email protected]
https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users
signature.asc (application/pgp-signature, 833 B)