httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From TOKI...@aol.com
Subject Re: Completely transform a request
Date Sat, 28 Jul 2007 14:01:11 GMT
 
> I wrote about this last week, on dev@httpd.apache.org, with a thread whose 
subject 
> was "Introducing mod_openpgp":
 
Yes, I saw that.
 
It was your new question about "Posting" a "Secret" request and then trying
to re-dump it into Apache as a "Trojan Horse" that had me confused.
 
Is this the way you actually plan on implementing "OpenPGP"?
 
The Nestcape plugin just wakes up for every Navigation and then
rewrites the request into a POST buffer + encryption?
 
I really don't think that's going to fly in the long run.
 
Even if you go this route... is it only going to work with Nestsape,
or something? That's not much of an "Open standard".
 
As to your last question... Nick Kew's post is on the mark.
Look hard and long at mod_ssl and mod_deflate.
 
If you need to get in there BEFORE the intial headers are processed
look at the mod_ssl code. It does the job.
 
If you don't care about intercepting the header's for your "Trojan"
POST then a simple rewrite of mod_deflate should do the job.
If it can't then there's still something essentially wrong with
the Apache 2.0 filtering design and it would be interesting to
find out.
 
If you really do need to "vanish" the entire original request including
the headers then you can still do that from within a non-connection
based filter but you are going to have to replace all the tables that
have already been created by Apache like request->headers_in 
with your own tables. The memory isn't protected at that point 
and it's no problem to do this, but I can't think of any existing
( public ) Apache filter that does this yet.
 
You could also just create an entire new 'sub-request' the moment
your filter wakes up and discard the original but be advised that
there are still some things that might not work as advertised for
a 'sub-request' that currenly work fine if the request is 'main'.
There are still some bugs lurking in that area.
 
Third alternative would be to look at the legacy "mod_gzip" code
for the Apache 1.3 series. It implements a "connection filter" just
like mod_ssl does but does NOT require EAPI or any rewrites
to standard Apache. The methods used in the legacy mod_gzip
will still work in the 2.0 series, if desired.
 
Later...
Kevin
 

In a message dated 7/28/2007 10:03:27 AM Pacific Standard Time, 
buanzo@buanzo.com.ar writes:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

TOKILEY@aol.com wrote:
> It is, in fact, possible to do what you are trying to do but before
> anyone tells you how, in public, do you mind expaining, in public,
> what the heck you are actually trying to do here?

Hi :)

I'm writing a draft on OpenPGP extensions to the HTTP Protocol.

So far, I've implemented request signing, which enables apache to verify a 
request using openpgp.

http://freshmeat.net/articles/view/2599

I plan on implementing encrypted requests, too. I'm also currently writing a 
session management
extension. All client-side stuff is contained in a Firefox extension called 
Enigform.

I wrote about this last week, on dev@httpd.apache.org, with a thread whose 
subject was "Introducing
mod_openpgp":

http://www.gossamer-threads.com/lists/apache/dev/333889

I hope the answer to "what the heck" is now clear.

- --
Arturo "Buanzo" Busleiman - Consultor Independiente en Seguridad Informatica
SHOW DE FUTURABANDA - Sabado 18 de Agosto 2007 (Speed King, Capital Federal)
Entradas anticipadas a traves de www.futurabanda.com.ar - Punk Rock Melodico


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGq3agAlpOsGhXcE0RCoxwAJ9KClqBRMRG3+2ASQXZ9uxUt5vC/gCfQAh6
YMYGFold1eI9tU+vsFHJc+Q=
=lgFi
-----END PGP SIGNATURE-----





************************************** Get a sneak peek of the all-new AOL at 
http://discover.aol.com/memed/aolcom30tour

Mime
View raw message