<div dir="ltr"><div><div>Thanks Jochen,<br></div><div>Your interpretation is spot on.<br><br></div>I cannot disagree with anything you said.  I do get the option to keep things as simple as possible, but all you said is a concern for me.<br>
<br></div>Regards.<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Mar 26, 2014 at 10:41 AM, Jochen Bern <span dir="ltr"><<a href="mailto:Jochen.Bern@linworks.de" target="_blank">Jochen.Bern@linworks.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On <a href="tel:26.03.2014%2013" value="+12603201413">26.03.2014 13</a>:55, Michael Carlino (RIT Student) wrote:<br>

> Yes, there is a reason.  stunnel *contains* the data I want to communicate<br>
> from client stunnel to server stunnel, within an HTTP request.<br>
<br>
</div>Hm. I shall interpret that as "the data is about the SSL connection<br>
itself (session key material?), and is not only unavailable outside<br>
stunnel (short of hacking a new API into that), but may not even *exist*<br>
until the moment stunnel starts pushing the altered HTTP request onto<br>
the wire".<br>
<div class=""><br>
> I sense a real appreciation out there for how well stunnel does it's job,<br>
> and within that a warning not to disturb it.<br>
<br>
</div>Not quite *my* drift at least. I was thinking about how much time you'll<br>
have to spend to get such a thing to *work* in the first place, what<br>
with no payload protocol parsing present+tested in stunnel, the<br>
possibilities of cached SSL sessions and/or connections muddying the<br>
recognition of single HTTP requests, yadda yadda, as opposed to using a<br>
FOSS which already deals with most of the protocol issues for a starting<br>
point.<br>
<br>
(For the records, I joined the list when I had a need to make a<br>
newly-developed non-SSL-aware HTTP client production platform ready<br>
mucho pronto, but have deployed socat more often since then, due to its<br>
capabilities to address Unix sockets etc. etc. as well. But I'm afraid<br>
that socat'ld be a *worse* basis for *your* project, since there's more<br>
"distance", in the software modularization sense, between its<br>
interconnect-management and SSL parts than in stunnel.)<br>
<div class="HOEnZb"><div class="h5"><br>
Regards,<br>
                                                                J. Bern<br>
--<br>
*NEU* - NEC IT-Infrastruktur-Produkte im <<a href="http://www.linworks-shop.de/" target="_blank">http://www.linworks-shop.de/</a>>:<br>
Server--Storage--Virtualisierung--Management SW--Passion for Performance<br>
Jochen Bern, Systemingenieur --- LINworks GmbH <<a href="http://www.LINworks.de/" target="_blank">http://www.LINworks.de/</a>><br>
Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt<br>
PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27<br>
Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202<br>
Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel<br>
</div></div></blockquote></div><br></div>