<div dir="ltr"><div><div><div><div>Hi Jochen,<br></div>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.<br>
<br></div>Yes, there is a reason. stunnel *contains* the data I want to communicate from client stunnel to server stunnel, within an HTTP request.<br><br></div>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.<br>
<br></div>Regards.<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Mar 26, 2014 at 8:36 AM, Jochen Bern <span dir="ltr"><<a href="mailto:Jochen.Bern@linworks.de" target="_blank">Jochen.Bern@linworks.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">On <a href="tel:26.03.2014%2013" value="+12603201413">26.03.2014 13</a>:05, Michael Carlino (RIT Student) wrote:<br>
> In the client stunnel I need to make a small change to the HTTP<br>
> packet. I need to add some data to it.<br>
<br>
</div>Then you *don't* want to manipulate *packets* (as in, using iptables,<br>
tcpdump, wireshark etc.). Adding data to a packet will mess up basic<br>
TCP/IP mechanisms like path MTU discovery real fierce.<br>
<div class=""><br>
> I know that as a proxy stunnel has to be and tries to be general in<br>
> nature. I am not concerned (right now) with developing a feature that will<br>
> become available to others later. I don't mind if my changes make my<br>
> development version of stunnel single-purpose. My work is academic and<br>
> proof-of-concept in it's nature.<br>
<br>
</div>Is there a reason - apart from the "server-side stunnel might want to<br>
close the connection" you mentioned - not to leave stunnel to do what it<br>
strives to do, and insert one or two additional layers with some<br>
dedicated HTTP-munging software (say, privoxy) instead? Or, for that<br>
matter, a dedicated SSL sniffer (say, ssldump) if the server side needs<br>
only *read* access to the actual HTTP data?<br>
<br>
Regards,<br>
J. Bern<br>
<span class="HOEnZb"><font color="#888888">--<br>
*NEU* - NEC IT-Infrastruktur-Produkte im <<a href="http://www.linworks-shop.de/" target="_blank">http://www.linworks-shop.de/</a>>:<br>
Server--Storage--Virtualisierung--Management SW--Passion for Performance<br>
Jochen Bern, Systemingenieur --- LINworks GmbH <<a href="http://www.LINworks.de/" target="_blank">http://www.LINworks.de/</a>><br>
Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt<br>
PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27<br>
Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202<br>
Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel<br>
</font></span></blockquote></div><br></div>