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.
I am a little confused by your question. If you control the unencrypted side, you should be able to use Wireshark to sniff the connection between your network application's unencrypted channel to stunnel. Nothing really fancy. Off the top of my head, you could replay captured packets after you have modified them.
On Wed, Mar 26, 2014 at 8:05 AM, Michael Carlino (RIT Student) mac9951@rit.edu wrote:
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.
stunnel-users mailing list stunnel-users@stunnel.org https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users
Hi Brian, I am looking to have my two stunnel's (client and server) work together to determine if an SSL connection should be closed. The client stunnel will send some data to the server stunnel. The server stunnel will make the decision to close the session. I want to send the extra data in an HTTP GET method request, and I am thinking an additional HTTP request header should do the trick. If I had unlimited time I'd try to make these changes to the SSL code in my browser (Firefox) and the web server (Tomcat) and not use stunnel. I chose to work with stunnel because it's easier than trying to obtain and master the code used in Firefox and Tomcat.
The problem I am seeing is that stunnel is a "dumb" proxy, and as such works quite well with a lot of protocols, because it does not care about the protocol. Getting it to do some protocol specific work is the key.
Regards.
On Wed, Mar 26, 2014 at 8:13 AM, Brian Wilkins bwilkins@gmail.com wrote:
I am a little confused by your question. If you control the unencrypted side, you should be able to use Wireshark to sniff the connection between your network application's unencrypted channel to stunnel. Nothing really fancy. Off the top of my head, you could replay captured packets after you have modified them.
On Wed, Mar 26, 2014 at 8:05 AM, Michael Carlino (RIT Student) mac9951@rit.edu wrote:
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.
stunnel-users mailing list stunnel-users@stunnel.org https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users
On 26.03.2014 13:05, Michael Carlino (RIT Student) wrote:
In the client stunnel I need to make a small change to the HTTP packet. I need to add some data to it.
Then you *don't* want to manipulate *packets* (as in, using iptables, tcpdump, wireshark etc.). Adding data to a packet will mess up basic TCP/IP mechanisms like path MTU discovery real fierce.
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.
Is there a reason - apart from the "server-side stunnel might want to close the connection" you mentioned - not to leave stunnel to do what it strives to do, and insert one or two additional layers with some dedicated HTTP-munging software (say, privoxy) instead? Or, for that matter, a dedicated SSL sniffer (say, ssldump) if the server side needs only *read* access to the actual HTTP data?
Regards, J. Bern
Hi Jochen, You are correct, I do not want to manipulate a TCP/IP packet. I do want to add to the application level HTTP packet. That should be ok as long as I am careful, I think. Maybe I should say that I want to add to the HTTP request, and leave it at that.
Yes, there is a reason. stunnel *contains* the data I want to communicate from client stunnel to server stunnel, within an HTTP request.
I sense a real appreciation out there for how well stunnel does it's job, and within that a warning not to disturb it. I surely understand that. stunnel is a means to an end for me. I am not looking to extend it's capabilities in any way that would be incorporated into the code base.
Regards.
On Wed, Mar 26, 2014 at 8:36 AM, Jochen Bern Jochen.Bern@linworks.dewrote:
On 26.03.2014 13:05, Michael Carlino (RIT Student) wrote:
In the client stunnel I need to make a small change to the HTTP packet. I need to add some data to it.
Then you *don't* want to manipulate *packets* (as in, using iptables, tcpdump, wireshark etc.). Adding data to a packet will mess up basic TCP/IP mechanisms like path MTU discovery real fierce.
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.
Is there a reason - apart from the "server-side stunnel might want to close the connection" you mentioned - not to leave stunnel to do what it strives to do, and insert one or two additional layers with some dedicated HTTP-munging software (say, privoxy) instead? Or, for that matter, a dedicated SSL sniffer (say, ssldump) if the server side needs only *read* access to the actual HTTP data?
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
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
Thanks Jochen, 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.
Regards.
On Wed, Mar 26, 2014 at 10:41 AM, Jochen Bern Jochen.Bern@linworks.dewrote:
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 -- *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
Michael Carlino (RIT Student) wrote:
I just now pursued http://haproxy.1wt.eu/download/1.5/doc/proxy-protocol.txt [1], 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.
In fact what PROXY protocol provides is an elegant solution to achieve the same goal that used to be achieved with the ugly X-Forwarded-For hack. The PROXY protocol does not modify HTTP headers. In fact it can be used with protocols other than HTTP.
Mike
Hi Mike, Thanks, I will look into that. Now, given that I haven't read the Tarreau doc yet, you can tell me to "read the ... manual", but... does PROXY work entirely *within* stunnel? I don't have to add that proxy data in the program that connects to client stunnel, do I?
Work day is almost over and then I can "relax" with that PROXY document.
Regards.
On Wed, Mar 26, 2014 at 11:55 AM, Michal Trojnara Michal.Trojnara@mirt.netwrote:
Michael Carlino (RIT Student) wrote:
I just now pursued http://haproxy.1wt.eu/download/1.5/doc/proxy-protocol.txt [1], 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.
In fact what PROXY protocol provides is an elegant solution to achieve the same goal that used to be achieved with the ugly X-Forwarded-For hack. The PROXY protocol does not modify HTTP headers. In fact it can be used with protocols other than HTTP.
Mike
stunnel-users mailing list stunnel-users@stunnel.org https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users
-
Brian Wilkins -
Jochen Bern -
Michael Carlino (RIT Student) -
Michal Trojnara