On 26.03.2014 13:55, Michael Carlino (RIT Student) wrote:
Yes, there is a reason. stunnel *contains* the data I want to communicate 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 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