<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hi Peter & all<div class=""><br class=""></div><div class="">I’ve only been looking at stunnnel a short while but looking at a simple server setup it appears to do the following;</div><div class=""><br class=""></div><div class="">Scenario 1</div><div class="">Client connects on SSL - stream is forwarded as unencrypted</div><div class=""><br class=""></div><div class=""><div class="">Scenario 2</div><div class="">Client connects unencrypted and does / offers STARTTLS - stream is forwarded as unencrypted</div></div><div class=""><br class=""></div><div class="">Scenario 3</div><div class="">Client connects unencrypted and does NOT do or offer a STARTTLS - server disconnects</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Mark</div><div class=""><br class=""></div><div class=""><div><blockquote type="cite" class=""><div class="">On 3 Feb 2017, at 08:40, Peter Pentchev <<a href="mailto:roam@ringlet.net" class="">roam@ringlet.net</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">On Thu, Feb 02, 2017 at 09:54:38PM +0000, Mark Boyce wrote:<br class=""><blockquote type="cite" class="">Hi All<br class=""><br class="">Wondering if there’s a way to pass an unencrypted connections traffic to<br class="">an alternative location if a client does not SSL/TLS with the stunnel<br class="">server?<br class=""><br class="">So considering stunnel running as a server to wrap an unencrypted SMTP<br class="">server. If the SMTP client/server talks SSL/TLS all is good and as<br class="">expected. If the client tries to talk without encryption it gets<br class="">disconnect. <br class=""><br class="">Is there any way to send this traffic elsewhere rather than<br class="">disconnecting the client? So that stunnel is adding an SSL/TLS option<br class="">to a service rather than enforcing it. Splitting the traffic to<br class="">destination servers based on if the client was encrypted or not.<br class=""></blockquote><br class="">stunnel itself cannot do this; one might write a trivial wrapper to<br class="">do it, but I believe that there might be a larger problem here.<br class=""><br class="">You mention SMTP. Doesn't the SMTP protocol *require* the server to<br class="">send its banner (220 Hi there, I'm an SMTP server, who are you?) before<br class="">the client sends its first command? I think that there are servers<br class="">that actually enforce this requirement for spam control - some spambots<br class="">are dumb enough to just open a TCP connection and blast a series of<br class="">SMTP commands without waiting for the server's greeting (to save on<br class="">round-trip times and such), and some servers deliberately delay their<br class="">220 greeting for a little while and immediately reject the connection<br class="">if the client tries to talk to them before that.<br class=""><br class="">So, um, how does the redirector know whether this is an SSL/TLS client<br class="">or not if the server has to send its greeting first? :) Of course, one<br class="">could do something like "wait for a second or two, see if the client<br class="">starts an SSL/TLS session; if not, pass it on to the unencrypted server<br class="">thing", but this will fail badly if the connection has a really high<br class="">latency or the client machine is badly overloaded so that it doesn't<br class="">send its SSL/TLS Client Hello in time, and it would also enforce<br class="">an additional delay on *every* unencrypted connection.<br class=""><br class="">G'luck,<br class="">Peter<br class=""><br class="">-- <br class="">Peter Pentchev <a href="mailto:roam@ringlet.net" class="">roam@ringlet.net</a> <a href="mailto:roam@freebsd.org" class="">roam@FreeBSD.org</a> <a href="mailto:pp@storpool.com" class="">pp@storpool.com</a><br class="">PGP key: <a href="http://people.freebsd.org/~roam/roam.key.asc" class="">http://people.FreeBSD.org/~roam/roam.key.asc</a><br class="">Key fingerprint 2EE7 A7A5 17FC 124C F115 C354 651E EFB0 2527 DF13<br class=""></div></div></blockquote></div><br class=""><div class="">
<div class=""><div style="orphans: 2; widows: 2;" class="">Mark</div><div style="orphans: 2; widows: 2;" class="">-- </div><div style="orphans: 2; widows: 2;" class="">Mark Boyce</div><div style="orphans: 2; widows: 2;" class="">Dark Origins Ltd</div><div style="orphans: 2; widows: 2;" class="">e: <a href="mailto:mark@darkorigins.com" class="">mark@darkorigins.com</a></div><div style="orphans: 2; widows: 2;" class="">t: 0845 0043 043</div><div style="orphans: 2; widows: 2;" class="">f: 0845 0043 044</div></div>
</div>
<br class=""></div></body></html>