[stunnel-users] Default passthrough to different destination?

Fri Feb 3 10:47:10 CET 2017

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 <roam at ringlet.net> 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  roam at ringlet.net roam at FreeBSD.org pp at storpool.com
> 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: mark at darkorigins.com <mailto:mark at darkorigins.com>
t: 0845 0043 043
f: 0845 0043 044

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.stunnel.org/pipermail/stunnel-users/attachments/20170203/c6bd1af0/attachment.html>