httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Arturo 'Buanzo' Busleiman <>
Subject Re: Completely transform a request
Date Mon, 30 Jul 2007 12:09:20 GMT
Hash: SHA512 wrote:
> That's all good news. You're almost there.

In case you want to take a look, you can check out the filter function from

> You have the 'content' encryption/decryption part
> worked out but you want to also make sure no one
> between the client and the COS ( Content Origin Server )
> can ever "see" where someone is going or what they
> are asking for.

That's why it is encrypted, yes. It comes out from the browser (or local pgp-http proxy, as
we were
discussing earlier), passess through any proxy because it is still valid HTTP 1.1, and when
it gets
to the server, even before virtual host processing (so the unecrnypted Host: header can say
anything, as long as it reaches the "correct" server to which the request was encrypted to),
it gets
decrypted, "replaced", and then processed, and served. The answer will be encrypted to the
of course, and signed with the server's key, so both server and client can privately communicate
also verify their identities. It's using PGP for HTTP.

> approach will, of course, always reveal the actual server

Well, no, the encrypted Host: header might point the server to one of its virtual hosts. See

> Let's define what you are really trying to do and
> maybe the reason you are having trouble implementing
> it in Apache will be a little clearer.


> The word for this is "tunnelling".

I was pretty sure tunneling, when talking about HTTP, had to do with the CONNECT method. But,
if you
are applying it here to simplify my concept, then, yes, I could accept it. Yes, as the HTTP
 that holds the encrypted one IS valid HTTP and proxies will be able to read it, not decrypt
encapsulated request. Yes, this breaks a couple of things, but we don't proxy cache SSL, do

I'm starting to feel I should develop httpp as you mentioned. Actually, it was my first damned
I've been reanalyzing this all over the past year and a half.

So, we are tunneling an encrypted request using a capsule request.

> You want to "tunnel" the real (encrypted) request
> through the non-secure HTTP protocol using a
> "fake" request that appears to be un-encrypted.

I dropped that idea because writing a mozilla firefox addon to handle that was too big a pain
in the
back just to get a Proof of Concept application working. If the http experts here really consider
should be using a brand new "httpp" LOC, then I'll analyze, further discuss, and finally (probably)
go for it.

> It's classic tunnelling with a twist.
> You want to both "tunnel" and "redirect".


> You SHOULD be able to do this, if you want, however
> quirky some might think the approach is.

I'm open to suggestions on how to properly implement an OpenPGP encryption/decryption layer
to HTTP.
I really am. I don't want to have all the answers. I had an idea, with benefits and disadvantages
over SSL, that uses OpenPGP. I believe it is a good thing, and I'm open to any suggestions
on how to
correctly/properly implement it, because it might be useful to some, like banks. Take into
that no user and password would be required to login to a site by using this, and that even
OpenPGP signed http request can go through SSL isntead of using OpenPGP encryption, makes
flexible enough, and secure enough, to make things like phishing disappear.

> By choosing to "tunnel", however, you are missing
> the opportunity to "answer the phone".

I don't agree. The request gets to Apache. Apache decrypts it, and answers the phone on the
encapsulated request. If an input filter can't get me there then I have to 1) implement this
using a
different approach, or 2) make it a horrible hack to make it work in Apache, 3) drop Apache
and use
a proxy in front of apache that decrypts the request, then gives the unencrypted one to apache
to serve.

I'd really like to have 1 (and 3, because it would work for pre 2.0 Apache and other webservers).
- From what you say, I CAN do 1 (mod-rewrite stuff, internal redirect, etc) easily. But the
fact that
a connection input filter can't COMPLETELY transform a request, INCLUDING the method line,
serve this new, transformed, request, sounds weird to me.

> Since the initial request appears to be a normal
> HTTP request then all of Apache's normal http input
> handlers are going to kick in right at the front door.

> Keep in mind that the first line of input for any
> HTTP server is not considered a "Header" at all.
> It is called the "HTTP method line" and by the time
> it is parsed by the server you have a whole bunch
> of server variables that have been intialized and
> the server now thinks it "knows where it's going".
> What FOLLOWS the "HTTP method line" are things
> called "input headers".

Quoting Nick's book:

? AP_FTYPE_CONNECTION filters operate on connections, at the TCP level
  (HTTP requests no longer exist). Apache (mod_ssl) uses it for SSL encoding.
  Another application is throttling and bandwidth control.

"HTTP requests no longer exist", that's why I chose a connection input filter to apply the
transformation, including method line" at.

- From what you say, should I be at the PROTOCOL level, then? Before all of Apache's normal
http input
handlers kick in?

> Just to satisfy my own curiosity I worked up
> a module here that is, in fact, able to do this.

Great, is it open source? Can I take a look? That'd be cool.

 > It's the same concept as mod_rewrite only it needs
> to happen a little later than usual.

Even though the decryption happens quite a bit earlier?

> What this does NOT do is address your reported
> problem that you are having trouble vaporizing
> existing request HEADER buffers and then replacing
> them with your own.

I had no trouble to vaporize anything, because I'm consumming all bucket brigades, EXCEPT
the last
one, which is where I intented to put the decrypted request into:

I've just got the last brigade for this request:

// Replace request with a "GET /" request instead of the decrypted one, for testing purposes
e = apr_bucket_immortal_create("GET / HTTP/1.0" CRLF "Host: localhost" CRLF CRLF,33,c->bucket_alloc);

I go and try to send the encrypted pgp request that I showed you earlier, using NetCat

cat encryptedrequest | nc localhost 80

My conn input filter gets it correctly, even decrypts it, but I get this: - - [29/Jul/2007:21:43:06 -0300] "GET / HTTP/1.0\r\nHost: localhost" 400 293
[Sun Jul 29 21:43:12 2007] [error] [client] request failed: error reading the headers

When I press ctrl+c in netcat.

And I attempted putting each LINE on it's own bucket, still doesn't work. But as you can see,
I got
Apache to show something different than "POST /HTTP_OPENPGP_DECRYPT 1.1" on the access_log,
using an internal redirect. That's why I thought I was going the right road, and I was just
a bug, or even incredibly stupid about some assumption :)

> You may, in fact, have found a bug there but it
> may also simply be that you are "too late in the
> game" to pull this from within a BODY data
> input filter.

Might sound like it.

> But if simple internal-redirect works to get you
> to your "secret" document and your existing filter
> is able to successfully decrypt the PGP payload...
> ...does THIS get you where you want to be?

As soon as the access_log shows only the secret document uri, and not a bunch of "POST
/HTTP_OPENPGP_DECRYPT HTTP/1.1" stuff (or worse, both items), then YES, it would get me where
I want to.

I don't want to break statistics software, just keep 3rd parties out of sniffing me or taking
my identity.

- --
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 - Punk Rock Melodico

Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla -


View raw message