Return-Path: Delivered-To: apmail-httpd-dev-archive@www.apache.org Received: (qmail 55287 invoked from network); 28 Jul 2007 19:29:36 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 28 Jul 2007 19:29:36 -0000 Received: (qmail 34424 invoked by uid 500); 28 Jul 2007 19:29:33 -0000 Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 34356 invoked by uid 500); 28 Jul 2007 19:29:33 -0000 Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: dev@httpd.apache.org list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list dev@httpd.apache.org Received: (qmail 34345 invoked by uid 99); 28 Jul 2007 19:29:33 -0000 Received: from Unknown (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 28 Jul 2007 12:29:33 -0700 X-ASF-Spam-Status: No, hits=3.8 required=10.0 tests=HTML_MESSAGE,MIME_QP_LONG_LINE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of TOKILEY@aol.com designates 64.12.137.1 as permitted sender) Received: from [64.12.137.1] (HELO imo-m20.mx.aol.com) (64.12.137.1) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 28 Jul 2007 19:29:23 +0000 Received: from TOKILEY@aol.com by imo-m20.mx.aol.com (mail_out_v38_r9.2.) id e.d5a.e8a3fde (65100); Sat, 28 Jul 2007 15:28:59 -0400 (EDT) From: TOKILEY@aol.com Message-ID: Date: Sat, 28 Jul 2007 15:28:57 EDT Subject: Re: Completely transform a request To: dev@httpd.apache.org CC: TOKILEY@aol.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-----------------------------1185650937" X-Mailer: 9.0 for Windows sub 5129 X-Virus-Checked: Checked by ClamAV on apache.org X-Old-Spam-Flag: NO -------------------------------1185650937 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit > 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 -------------------------------1185650937 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
> That's why I thought bringing the concept over here was a good ide= a.
> 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 regard= less
of what anyone thinks of your idea if you can't implement it easily rig= ht 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<= /DIV>
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 avoidin= g pgp from
> inside a browsers plugin, and just write a proxy that implements t= he 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 av= ailable
regardless of anything else you cook up.
 
Even if your "standards" are approved by all the various parties involv= ed
the horse has left the barn with clients and user-agents and even if th= ey
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<= /DIV>
RFCs alone, much less throw in something like this for them to implemen= t.
 
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 wo= rk 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 post= s 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 le= gacy HTTP
1.0 client and then you can get conflict errors trying to use other hea= ders.
 
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 al= l
fit into one buffer read on the Server side. If you can't get that work= ing then
all the chunking in the world isn't going to make any difference later.=
 
>...take into account I've already implemented reading and decryptin= g 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 an= d 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: SH= A512

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

Not really. I have many paths. One of the= m is almost fully avoiding pgp from inside a browsers
plugin, and just wr= ite a proxy that implements the required functionality, and the same in reve= rse
at the server side, so it's more easily plugged into any browser/http= d app.

In any case, Enigform, mod_openpgp, etc, are all things that h= elp 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 proble= m with an encrypted request is that, well, it doesn't work on chunks. I coul= d make it work
on chunks, but that would include LOTS of overhead to the=20= 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 fo= r every Navigation and then
> rewrites the request into a POST buffer=20= + encryption?

Not Netscape, but Mozilla Firefox.

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

That's why I though= t bringing the concept over here was a good idea. I'm finally getting someconstructive criticism!

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

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

TM: I under= stand you want it to become an accepted standard. How is the approval proces= s 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 I= ETF by July this year (2007). Hopefully, it can become an RFC.
That would= probably make Enigform and other plugins obsolete, because the browser itse= lf
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 decrypti= ng the request withing the
conn filter.

> If you don't care abo= ut intercepting the header's for your "Trojan"
> POST then a simple re= write 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
b= ody, it'd be quite easy. I need to take a request body, decrypt it, and use=20= that as the request.
It's another concept. I might not be clear at explai= ning it. See my other message, with the example
request.

> If y= ou really do need to "vanish" the entire original request including
>=20= the headers then you can still do that from within a non-connection
>=20= based filter but you are going to have to replace all the tables that
>= ; have already been created by Apache like request->headers_in
> wi= th your own tables.

Yes, I've thought about that, too. But how can I=20= 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<= BR>2: move headers from body to headers (in a post_read_request filter, mayb= e)
3: replace the "POST /HTTP_OPENPGP_DECRYPT" uri with the one that was=20= 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 apach= e at that stage, yet. Sounded logical. "Get a whole
request, decrypt it,=20= then rewrite original request using the now decrypted text".

> You= could also just create an entire new 'sub-request' the moment
> your=20= filter wakes up and discard the original but be advised that
> there a= re still some things that might not work as advertised for
> a 'sub-re= quest' that currenly work fine if the request is 'main'.
> There are s= till some bugs lurking in that area.

I thought about using sub-reques= ts, too. Didn't work out.

> Third alternative would be to look at=20= the legacy "mod_gzip" code
> for the Apache 1.3 series. It implements=20= a "connection filter" just
> like mod_ssl does but does NOT require EA= PI or any rewrites
> to standard Apache. The methods used in the legac= y mod_gzip
> will still work in the 2.0 series, if desired.

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

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


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Li= nux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGq4tQAlpOsGhXcE0RCmxdAJ9t+RLXiYxAWMMYV2yTc0vG+d36qgCfbKAH
3Yt+fZ= PDfOtFRNwmjmhiYDE=3D
=3D7J2O
-----END PGP SIGNATURE-----



Get a sneak peek of the all= -new AOL.com.
-------------------------------1185650937--