Maybe this question is more appropriate for tor-dev mailing list?
How to submit a certain IP:Port to BridgeDB without using Tor?
-naif
-------- Original Message -------- Subject: Re: [tor-talk] Bridge: Why not just stateless TCP socket proxy / forwarders? Date: Mon, 16 Jan 2012 09:29:41 +0100 From: Fabio Pietrosanti (naif) lists@infosecurity.ch To: tor-talk@lists.torproject.org
On 1/15/12 11:54 PM, andrew@torproject.org wrote:
On Sun, Jan 15, 2012 at 04:58:56PM +0100, lists@infosecurity.ch wrote 0.3K bytes in 11 lines about: : does Bridge really need to be Tor Servers? : Why they can't be just be simpler TCP socket proxy?
We've been through this already. ;) No, a bridge is just a way to reach the tor network from a tor client, it can be any proxy or tcp forwarder. I refer you to https://blog.torproject.org/blog/strategies-getting-more-bridge-addresses again. Specifically, approach four and five.
So, if a third party would like independently to: - develop a TCP forwarder (very simple code) - submit to the BridgeDB - decide to which host to connect back
which would be the step do be done from technical standpoint of view?
Because that way it would be possible for a lot of third party to develop very lightweight "Tor TCP Proxy" that doesn't have inside other than the basic logic to do the TCP Proxy.
Is the availability for third party software/script for that goals considered?
Tnx!
-naif
On Mon, Jan 16, 2012 at 12:53:38PM +0100, Fabio Pietrosanti (naif) wrote:
So, if a third party would like independently to:
- develop a TCP forwarder (very simple code)
- submit to the BridgeDB
- decide to which host to connect back
which would be the step do be done from technical standpoint of view?
Because that way it would be possible for a lot of third party to develop very lightweight "Tor TCP Proxy" that doesn't have inside other than the basic logic to do the TCP Proxy.
Is the availability for third party software/script for that goals considered?
I know some research groups who are working on various parts of this problem. But one piece that I believe nobody is working on right now is a mechanism for having bridgedb hear about other addresses that it should give out as bridges.
Right now bridgedb only learns about bridges via the networkstatus and bridge descriptor files it imports from the bridge directory authority; and it also assumes that whenever it learns about a bridge it also learns the identity fingerprint for the bridge (so it can decide what distribution strategy bucket to put it in).
If somebody wants to grab this problem and brainstorm a todo list, maybe with the help of Aaron and Karsten (the last sighted bridgedb maintainers :), that'd be grand.
--Roger
-
Fabio Pietrosanti (naif) -
Roger Dingledine