> Arturo wrote... > > Thanks for taking the time to discuss this with me. > I really appreciate it. > > I was able to read a whole "pgp-encrypted" request, > even a large 12+MB one using my code. I read the > content-length header, then read up to that quantity of > bytes, saving the brigades to a context brigade. > Of course, I just DECLINE when the request is not > a "POST /HTTP_OPENPGP_DECRYPT HTTP/1.1" one. That's all good news. You're almost there. >> Just send your headers normally, add the encrypted BODY, >> and let the Server side conn-filter do it's thing on >> the BODY data. >> >> Why isn't that "good enough?" > > Privacy. Ah... Ok... I get it now. You have the 'content' encryption/decryption part worked out but you want to also make sure no one between the client and the COS ( Content Origin Server ) can ever "see" where someone is going or what they are asking for. Your "POST /HTTP_OPENPGP_DECRYPT HTTP/1.1" approach will, of course, always reveal the actual server being contacted unless the target is just running as a portal in some "other" domain... so all you are really trying to mask is the actual DOCUMENT being requested and, perhaps, any associated QUERY parms. Right? > I really want to put headers and URI, and body if > applicable. That's why the special POST request URI > I'm using has minimal headers. The real headers, > the real body, the real URI is inside the > encrypted body. Ok... let's take a deep breath here. Let's define what you are really trying to do and maybe the reason you are having trouble implementing it in Apache will be a little clearer. The word for this is "tunnelling". You don't want to implement your own LOC ( Left of Colon ) protocol named "httpp" ( http + PGP ) like Secure Socket Layer does ( https = http + SSL ). You want to "tunnel" the real (encrypted) request through the non-secure HTTP protocol using a "fake" request that appears to be un-encrypted. The problem you are running into is that you want to let Apache's normal "http" protocol handler "answer the phone" and then "rip the rug out" and create the "real" request and discard the "dummy" one. It's classic tunnelling with a twist. You want to both "tunnel" and "redirect". No problem. You SHOULD be able to do this, if you want, however quirky some might think the approach is. By choosing to "tunnel", however, you are missing the opportunity to "answer the phone". Since the initial request appears to be a normal HTTP request then all of Apache's normal http input handlers are going to kick in right at the front door. I don't think just a simple "filter" is going to do all the job for you, in this case. Keep in mind that the first line of input for any HTTP server is not considered a "Header" at all. It is called the "HTTP method line" and by the time it is parsed by the server you have a whole bunch of server variables that have been intialized and the server now thinks it "knows where it's going". What FOLLOWS the "HTTP method line" are things called "input headers". So even if you figure out how to vaporize the inbound "fake" headers and replace the "buckets" with your own you are still going to have to do something else to pull off your "redirect" to the "secret URI" regardless of how you find out what it really is. Just to satisfy my own curiosity I worked up a module here that is, in fact, able to do this. It is by no means a working PGP demonstration but it does do a simple imitation of what you are trying to do. In other words, I posted myself some gobbly-gook which has an actual target URI in it and not only am I able to "filter" the gobbly-gook and turn it back into non-gobbly-gook I was able to simply do a standard "internal redirect" to the URI once I pulled it out of the non-gobbly-gook. It's called an "internal-redirect". Apache has been able to do this for a long time and you need to take a hard look at it and see if it will work for you. The trick is that you are going to have to do the same things that the existing Apache module mod_rewrite does. It's the same concept as mod_rewrite only it needs to happen a little later than usual. Take a close look at mod_rewrite to see all of the API calls it makes. You can make these same calls yourself from within your filter and make it appear as if mod_rewrite actually "ran" on your request. So I was able to send a "fake" (dummy) request into Apache, start filtering my posted "gobbly-gook", pull a real destination URI out of the "gobbly-gook" and then tell Apache to "redirect" to it. It seems to work fine. What this does NOT do is address your reported problem that you are having trouble vaporizing existing request HEADER buffers and then replacing them with your own. You may, in fact, have found a bug there but it may also simply be that you are "too late in the game" to pull this from within a BODY data input filter. So the vaporization of existing input request headers and replacing them with others from within filter code only ( and not a server hook ) is not something I have had a chance to look at yet. I will try to take a look at that issue as well. But if simple internal-redirect works to get you to your "secret" document and your existing filter is able to successfully decrypt the PGP payload... ...does THIS get you where you want to be? The content is secure and the actual document requested is invisible to everyone in-between the client and the actual Apache server being connected to. Why even bother trying to hide anything else from proxy servers? Wouldn't that meet just about anyone's definition of "Pretty Good Privacy"?
************************************** Get a sneak peek of the all-new AOL at http://discover.aol.com/memed/aolcom30tour
