[stunnel-users] Access to Packet Content
Michael Carlino (RIT Student)
mac9951 at rit.edu
Wed Mar 26 15:57:24 CET 2014
Your interpretation is spot on.
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.
On Wed, Mar 26, 2014 at 10:41 AM, Jochen Bern <Jochen.Bern at linworks.de>wrote:
> On 26.03.2014 13:55, Michael Carlino (RIT Student) wrote:
> > Yes, there is a reason. stunnel *contains* the data I want to
> > from client stunnel to server stunnel, within an HTTP request.
> Hm. I shall interpret that as "the data is about the SSL connection
> 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".
> > I sense a real appreciation out there for how well stunnel does it's job,
> > and within that a warning not to disturb it.
> Not quite *my* drift at least. I was thinking about how much time you'll
> 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
> (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.)
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the stunnel-users