Page 1 of 1

Bitproxy - experimental local .bit proxy with TLS

Posted: Wed Oct 14, 2015 9:55 am
by phelix
https://github.com/phelix/bitproxy

Already quite a while ago I played with pymiproxy. With knowledge gained from discussions about NMControl with Domob and particularly Biolizard I thought I would give it another shot.

Installing the local root cert is cumbersome. Biolizard is working on solving this automatically, maybe this could be used for Bitproxy.

Comments appreciated.

Re: Bitproxy - experimental local .bit proxy with TLS

Posted: Sun Oct 18, 2015 6:27 am
by biolizard89
phelix wrote:https://github.com/phelix/bitproxy

Already quite a while ago I played with pymiproxy. With knowledge gained from discussions about NMControl with Domob and particularly Biolizard I thought I would give it another shot.

Installing the local root cert is cumbersome. Biolizard is working on solving this automatically, maybe this could be used for Bitproxy.

Comments appreciated.
My opinion is that pymiproxy's lack of maintenance is concerning. mitmproxy has much more active development. A while back I rigged NMControl to use mitmproxy, although I never got around to doing custom certificate validation. The flip side is that mitmproxy's codebase is larger, so potentially more attack surface. However, with the "tcp" flag I don't think most of their code is actually called at all.

I don't think proxies are a great way to implement .bit, given that for both TLS validation and Tor support there are better, safer ways of doing it. However, if there's interest, I can publish the mitmproxy NMControl code that I have, as long as it's 100% clear that I don't endorse its usage in anything serious.

Re: Bitproxy - experimental local .bit proxy with TLS

Posted: Mon Oct 19, 2015 8:57 am
by phelix
biolizard89 wrote:
phelix wrote:https://github.com/phelix/bitproxy

Already quite a while ago I played with pymiproxy. With knowledge gained from discussions about NMControl with Domob and particularly Biolizard I thought I would give it another shot.

Installing the local root cert is cumbersome. Biolizard is working on solving this automatically, maybe this could be used for Bitproxy.

Comments appreciated.
My opinion is that pymiproxy's lack of maintenance is concerning. mitmproxy has much more active development. A while back I rigged NMControl to use mitmproxy, although I never got around to doing custom certificate validation. The flip side is that mitmproxy's codebase is larger, so potentially more attack surface. However, with the "tcp" flag I don't think most of their code is actually called at all.
There are versions of pymiproxy being (actively?) used by the internet archive. They seem better maintained. It should be relatively easy to rebase:
https://github.com/ikreymer/certauth
https://github.com/internetarchive/warc ... tmproxy.py (unfortunately the name is confusing, this is pymiproxy without the certauth class)

mitmproxy really looks huge, probably overkill for this purpose. The relevant pymiproxy code is only a little more than 300 lines!
I don't think proxies are a great way to implement .bit, given that for both TLS validation and Tor support there are better, safer ways of doing it.
Yet there has not come up a single specific argument: https://forum.namecoin.info/viewtopic.php?f=5&t=2425

Re: Bitproxy - experimental local .bit proxy with TLS

Posted: Tue Oct 20, 2015 2:57 am
by biolizard89
mitmproxy is big, but we would only be using libmproxy, rather than the full mitmdump or mitmproxy UI's. Furthermore, we would be using "tcp" mode, which disables all of libmproxy's HTTP protocol parsing. So while it's still bigger than pymiproxy, it's not as big as it looks. I was actually unaware of the newer pymiproxy fork by IA; that's interesting.

I've replied in the linked thread about TLS applications. For Tor applications, we would probably want to either use Yawning's SOCKS proxy, or fork Jesse Victors's OnioNS. Trying to use a proxy that's not carefully designed for Tor will subtly break anonymity, e.g. it will break stream isolation.