-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 [EMAIL PROTECTED] 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-----
