[stunnel-users] Access to Packet Content

Wed Mar 26 13:05:43 CET 2014

Hello stunnel users,
I am working with what seems to be the standard stunnel HTTPS
configuration.  I have two instances of stunnel, one as a client and one as
a server.  The client accepts connections from a browser.  The server sits
in front of tomcat.  If works like a charm (of course!).

What I need to do seems simple, and I will try to keep my description of it
generic.  In the client stunnel I need to make a small change to the HTTP
packet.  I need to add some data to it.  At the server side I need to
access that added data.  The server stunnel may close the SSL session based
on that data.

So, my question is: can I obtain access to the packet before it's encrypted
and sent out over SSL?  Can I get access to the decrypted packet before
it's sent on to tomcat?

I know that as a proxy stunnel has to be and tries to be general in
nature.  I am not concerned (right now) with developing a feature that will
become available to others later.  I don't mind if my changes make my
development version of stunnel single-purpose.  My work is academic and
proof-of-concept in it's nature.

I have collected references and a text book (Network Security with OpenSSL
by Viega et al).  I will continue to walk through and explore the code.
Are there any programmer resources I can obtain?  I see the occasional URL
in the stunnel source code.  I will have to check these URLs.

---

I just now pursued http://haproxy.1wt.eu/download/1.5/doc/proxy-protocol.txt,
and I see that there is a patch that allows stunnel to do an initial
modification to the HTTP request to insert a X-Forwarded-For header.  This
sounds like what I need to do!  I am going to look for that patch.  I hope
the source code for the patch is available.

Please, if anyone has any advice, war stories, criticism, whatever... I
would very much appreciate it.

Regards.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.stunnel.org/pipermail/stunnel-users/attachments/20140326/3f1c5204/attachment.html>