Re: Completely transform a request

> 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"?