httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Arturo 'Buanzo' Busleiman <bua...@buanzo.com.ar>
Subject Re: Completely transform a request
Date Sat, 28 Jul 2007 18:30:40 GMT
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

TOKILEY@aol.com wrote:
> Is this the way you actually plan on implementing "OpenPGP"?

Not really. I have many paths. One of them is almost fully avoiding pgp from inside a browsers
plugin, and just write a proxy that implements the required functionality, and the same in
reverse
at the server side, so it's more easily plugged into any browser/httpd app.

In any case, Enigform, mod_openpgp, etc, are all things that help me find a solid base for
implementing Openpgp into http. For example, the way request signing was implement is quite
straight
forward and http compliant. (see http://freshmeat.net/articles/view/2599).

The problem with an encrypted request is that, well, it doesn't work on chunks. I could make
it work
on chunks, but that would include LOTS of overhead to the request. And I mean LOTS. Are you
a GnuPG
user? You probably know what I'm talking about if you are.

> The Nestcape plugin just wakes up for every Navigation and then
> rewrites the request into a POST buffer + encryption?

Not Netscape, but Mozilla Firefox.

> I really don't think that's going to fly in the long run.

That's why I thought bringing the concept over here was a good idea. I'm finally getting some
constructive criticism!

> Even if you go this route... is it only going to work with Nestsape,
> or something? That's not much of an "Open standard".

Well, the browsers should implement the openpgp extensions, not a plugin, see this quote form
an
interview:

TM: I understand you want it to become an accepted standard. How is the approval process going?

Some guys from the IETF OpenPGP Working Group are helping me with some procedural details,
but I
expect to have it submitted to the IETF by July this year (2007). Hopefully, it can become
an RFC.
That would probably make Enigform and other plugins obsolete, because the browser itself
could/should support it. I?d love to focus on the server-side, really.

(taken from http://www.freesoftwaremagazine.com/blogs/interview_with_arturo_busleiman)

> If you need to get in there BEFORE the intial headers are processed
> look at the mod_ssl code. It does the job.

OK, but take into account I've already implemented reading and decrypting the request withing
the
conn filter.

> 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.

mod_deflate deflates the body, not the headers. That's not what I need. If I had just to decrypt
the
body, it'd be quite easy. I need to take a request body, decrypt it, and use that as the request.
It's another concept. I might not be clear at explaining it. See my other message, with the
example
request.

> 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.

Yes, I've thought about that, too. But how can I change to which real URI the request was
targeted
to? I think I could use something like:

1: decrypt_body in conn filter, and tag the request
2: move headers from body to headers (in a post_read_request filter, maybe)
3: replace the "POST /HTTP_OPENPGP_DECRYPT" uri with the one that was included in the decrypted
body.
4: finally, process this new request.

I wanted to avoid all that, and just completely transform the request at the connection input
filter
stage, because no HTTP is processed by apache at that stage, yet. Sounded logical. "Get a
whole
request, decrypt it, then rewrite original request using the now decrypted text".

> 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.

I thought about using sub-requests, too. Didn't work out.

> 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.

I'll take a good look at that. Thanks for the suggestion.

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

iD8DBQFGq4tQAlpOsGhXcE0RCmxdAJ9t+RLXiYxAWMMYV2yTc0vG+d36qgCfbKAH
3Yt+fZPDfOtFRNwmjmhiYDE=
=7J2O
-----END PGP SIGNATURE-----

Mime
View raw message