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