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 20:03:08 GMT
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

TOKILEY@aol.com wrote:
> 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.

I know, I really know! :) I was being thankful! :) I've been into development mailing lists
since I
was 14 years old. I started out with GNU/Linux in September 1994, back in the 1.x days. I've
been
contributing in many different ways (Nmap, Audacity, Samba-vscan, some translation work,
beta-testing, giving talks, even my rock band licenses music using the creative commons by-sa
license!).

> Ultimately, I think that's the way to go. You should have that setup
> available regardless of anything else you cook up.

Yes, I will do that. Definitely! Anyway, I really wanted to learn how to program Mozilla Firefox
extensions, and Apache modules. And I'm loving it.

> Even if your "standards" are approved by all the various parties involved
[...]
> out for all the clients, probably. That's just the way it is.

You're right. I need to provide solid tools in the meantime.

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

Yes, that's what I've understood. Thanks for taking the time to discuss this with me. I really
appreciate it.

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

I was able to read a whole "pgp-encrypted" request, even a large 12+MB one using my code.
I read the
content-length header, then read up to that quantity of bytes, saving the brigades to a context
brigade. Of course, I just DECLINE when the request is not a "POST /HTTP_OPENPGP_DECRYPT HTTP/1.1"
one.

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

Apache wants headers in their own bucket, and even in their own brigades. Each header. When
I create
a bucket containing the whole decrypted request (take into account I've destroyed all previous
brigades, clean-ed up the last one) into the last brigade I've get_brigaded()ed, it just doesn't
work.

So, I started making tests. Eat the whole encrypted request, replacing it with a simple "GET
/
HTTP/1.1\r\nHost: localhost\r\n\r\n" one. It didn't work. So I went piece by piece. One bucket
for
"GET / HTTP/1.1\r\n", another for "Host: localhost\r\n", then another for "\r\n". When I did
that, I
got this on the logs:

[Wed Jul 18 19:55:08 2007] [error] [client 127.0.0.1] request failed: error reading the headers

These are different tests:
127.0.0.1 - - [20/Jul/2007:18:16:15 -0300] "GET / HTTP/1.0\r\n" 400 293
127.0.0.1 - - [20/Jul/2007:18:16:48 -0300] "GET / HTTP/1.0" 400 293
127.0.0.1 - - [20/Jul/2007:18:24:42 -0300] "GET / HTTP/1.0\r\nHost: localhost\r\n" 400 293

> I think your problem at the moment might be in how you are implementing
> things on the CLIENT side.

For the moment, this is my client side code:

cat hand-crafted-encrypted-request | nc localhost 80

The hand-crafted request is the one I showed earlier (the one with HTTP/1.1, content-length,
host
and connection headers).

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

Privacy. I really want to put headers and URI, and body if applicable. That's why the special
POST
request URI I'm using has minimal headers. The real headers, the real body, the real URI is
inside
the encrypted body.

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

I thought about it, only encrypting the required headers, body, and maybe the  itself, or
the query
string if it is a GET request. But it would add LOTS of overhead. A simple 2 character string
could
become a 1024 bytes monster when using openpgp. Encrypting the whole request allows for less
overhead, more privacy, less CPU usage on both sides (less number of encryptions per request,
from
N-encryptions/req, to one e/req).

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

iD8DBQFGq6D7AlpOsGhXcE0RCrOeAJ9+N7tJ8DuJviZSGgmwp/oKrcI5wACeMGht
WdZHMCsnt9iHf7bkZevPbBw=
=0xVU
-----END PGP SIGNATURE-----

Mime
View raw message