-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 [EMAIL PROTECTED] 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 http://www.buanzo.com.ar/files/openpgp.conn.filter.in.c > 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 sender, of course, and signed with the server's key, so both server and client can privately communicate and also verify their identities. It's using PGP for HTTP. > Your "POST /HTTP_OPENPGP_DECRYPT HTTP/1.1" > 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 above. > 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. OK. > 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 request that holds the encrypted one IS valid HTTP and proxies will be able to read it, not decrypt the encapsulated request. Yes, this breaks a couple of things, but we don't proxy cache SSL, do we? I'm starting to feel I should develop httpp as you mentioned. Actually, it was my first damned idea. 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 I 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". OK. > 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 account that no user and password would be required to login to a site by using this, and that even the OpenPGP signed http request can go through SSL isntead of using OpenPGP encryption, makes it 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, then 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 "100% 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: apr_brigade_cleanup(bb); // 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); APR_BRIGADE_INSERT_HEAD(bb,e); 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: 127.0.0.1 - - [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 127.0.0.1] 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, without using an internal redirect. That's why I thought I was going the right road, and I was just hitting 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 over 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 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 iD8DBQFGrdTwAlpOsGhXcE0RCgsKAJsHlQ+4H36vbHskl4hSfsnWtJ1oNACfdGJr BfPQMYke2d9c5TlzikvDVlY= =hYMe -----END PGP SIGNATURE-----
