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 15:28:57 GMT
 
> That's why I thought bringing the concept over here was a good idea. 
> I'm finally getting some constructive criticism!

It's an interesting idea. There have been years of work put into making
HTTP and Apache "extensible" for ideas just such as this one and regardless
of what anyone thinks of your idea if you can't implement it easily right now
then the ball just isn't into the end-zone yet on the Server design.
 
People can get kinda short and blunt over here but be advised that the
only bad discussion about technology is not having one at all and,
in general, the "constructive criticism" is all well-intentioned.
 
> 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.
 
Ultimately, I think that's the way to go. You should have that setup available
regardless of anything else you cook up.
 
Even if your "standards" are approved by all the various parties involved
the horse has left the barn with clients and user-agents and even if they
wanted to implement your new scheme it would be years before it 
happened and then years after that before all the bugs were worked 
out for all the clients, probably. That's just the way it is.
 
It's still impossible to get all major clients up to speed on HTTP/1.1
RFCs alone, much less throw in something like this for them to implement.
 
I'm not trying to poo-poo your current plans.
 
Let's assume you just want to see it work the way you are going
and that it SHOULD be possible to do it with Apache's current design.
 
> The problem with an encrypted request is that, well, it doesn't work on 
chunks.
 
Well, if it's a request headed at an Apache server then sooner or later you 
are
going to have deal with 'chunking'. If you are going to allow HUGE posts up to
Apache with your OpenPGP then at some point it better be able to 'chunk'
or you'll have to force the Server to think you are, at all times, a legacy 
HTTP
1.0 client and then you can get conflict errors trying to use other headers.
 
But just for the sake of getting something to work... let's assume that you
are just trying to package simple, short HTTP requests and they will all
fit into one buffer read on the Server side. If you can't get that working 
then
all the chunking in the world isn't going to make any difference later.
 
>...take into account I've already implemented reading and decrypting the 
> request withing the conn filter.
 
Ok. So help me out here. Why isn't that enough?
 
I think your problem at the moment might be in how you are implementing
things on the CLIENT side.
 
If you are able to "run" the request in your Mozilla/Firefox plug-in and add
the encrypted POST data to the request then why do you need the 
"Trojan Horse" thing?
 
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?"
 
> If I had just to decrypt the body, it'd be quite easy. 
 
Yup. That's what filters are designed to do.
WHY do you need to encrypt the headers at all?
Help me understand.
 
If there is any piece of information outside the "BODY" that you
are trying to "hide" from normal view then why don't you just add
it to the normal request headers as an "encrypted field"... without
trying to encrypt ALL of the headers and create the "Trojan Horse"
scenario on the Server side?
 
Later...
Kevin Kiley



In a message dated 7/28/2007 11:31:33 AM Pacific Standard Time, 
buanzo@buanzo.com.ar writes:

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





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

Mime
View raw message