Re: https proxy [was polipo]
On Sat, Aug 21, 2010 at 6:18 PM, grarpamp grarp...@gmail.com wrote: Nothing in the open source field can do so yet afaik. To do it, a shim needs to be coded and placed between the application and Tor. user - browser - [optional tool] - shim - tor:9050 The shim needs to listen on a proxy port (and or two configurable ports (for http and https)) and connect out to the world (or tor) to a proxy port (socks) (and or two other ports (for http and https or whatever port the input protocol used)). It would pass http unmodified. It would break end to end https. If the destination site had an invalid cert, it would present an invalid self-generated one to the client. If the destination site had a valid cert, it would present a self-generated and self-signed one to the client (which had obviously included the shim's root as a trusted cert), simply to signify to the client as to validity. Identity would be available from verbose logging in the shim and via an http[s] port on the shim itself. It could furthermore 'tee' off two output ports from it's bottom and receive two input ports from it's top. These would be a more general hook into 'optional toolchains' located in between the client and server side, decoding and shuffling the data stream in and out to a toolset at that point. It should have no 'censoring', caching or other features.. as that is what the optional toolsets do best. Note that 'browser' could be anything that can speak http[s], not just FF/MSIE. So 'plugins' are a non option. Very interesting idea. I am considering attempting this in an upcoming practicum term at school starting in January 2011. I wonder if you could help me a bit further by providing a list of advantages this shim would/could provide. I can see it could provide some protection against ssl/ssh mitm attacks. It could better protect the browser (or other app) by moving some of the ssl/tls/cert logic out to an open source proxy of sorts. It could better protect users against ssl/tls/cert vulnerabilities in both open source and proprietary apps. But I confess to not being sufficiently capable yet on this issue, so any input by any other readers here would be greatly appreciated. -- Julie
Re: https proxy [was polipo]
I can see it could provide some protection against ssl/ssh mitm attacks. No. Why do you think it could? It could better protect the browser (or other app) by moving some of the ssl/tls/cert logic out to an open source proxy of sorts. Protect? Of what? How? It could better protect users against ssl/tls/cert vulnerabilities in both open source and proprietary apps. Explain, please Best regards, morphium *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: https proxy [was polipo]
I can see it could provide some protection against... No. Why do you think it could? - because by default - lots of additional reasons... The shim was just supposed to be a tool so you could hook into an http[s] stream and do whatever with it, or nothing at all. For instance, I've always wanted to cache static images and pages coming in over https via Tor/Inet. Can't do that yet. Throw this shim between your browser and your gateway, tee it off into squid and you could save some significant bandwidth. With https becoming ever more popular and likely to be everywhere soon, I'm sure someone will write the shim sooner or later. (Tahoe LAFS / encrypted $cloud storage for your dig :) *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: https proxy [was polipo]
https://anonymous-proxy-servers.net/en/anontest As I understand it, Polipo can't scrub the headers of an HTTPS request, Nothing in the open source field can do so yet afaik. To do it, a shim needs to be coded and placed between the application and Tor. user - browser - [optional tool] - shim - tor:9050 The shim needs to listen on a proxy port (and or two configurable ports (for http and https)) and connect out to the world (or tor) to a proxy port (socks) (and or two other ports (for http and https or whatever port the input protocol used)). It would pass http unmodified. It would break end to end https. If the destination site had an invalid cert, it would present an invalid self-generated one to the client. If the destination site had a valid cert, it would present a self-generated and self-signed one to the client (which had obviously included the shim's root as a trusted cert), simply to signify to the client as to validity. Identity would be available from verbose logging in the shim and via an http[s] port on the shim itself. It could furthermore 'tee' off two output ports from it's bottom and receive two input ports from it's top. These would be a more general hook into 'optional toolchains' located in between the client and server side, decoding and shuffling the data stream in and out to a toolset at that point. It should have no 'censoring', caching or other features.. as that is what the optional toolsets do best. Note that 'browser' could be anything that can speak http[s], not just FF/MSIE. So 'plugins' are a non option. And that the 'optional tool' might be squid or polipo or whatever. And lastly, erasing your OS and other info from your headers makes you stand out as an obvious eraser. It's better to use a dead common and up to date os and browser and then mind your sessions properly. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
