Obfsbridges should be able to "disable" their ORPort
In the future, we will want obfsbridges to only expose their obfsports and not their ORPort, otherwise an adversary can launch an active-scanning attack against the ORPort.
We should spec and implement a torrc option that hides the ORPort of obfsbridges.
Maybe it should make the ORPort bind on localhost. But what happens if the transport proxy is not on the same host as the ORPort?
Activity
changed milestone to %Tor: 0.4.5.x-final
Replying to asn:
In the future, we will want obfsbridges to only expose their obfsports and not their ORPort, otherwise an adversary can launch an active-scanning attack against the ORPort.
We should spec and implement a torrc option that hides the ORPort of obfsbridges.
Suggestions on what to call it?
Maybe it should make the ORPort bind on localhost. But what happens if the transport proxy is not on the same host as the ORPort?
I think "bind just to localhost" is a fine default. For people who put their transport somewhere else, they should be able to follow directions (as long as we write said directions and they're not too complex).
This config option should also disable the ORPort reachability testing.
-
Also also, Tonga only knows how to test ORPort reachability, and if the ORPort isn't reachable, the bridge won't get the Running line in the consensus that Tonga sends to bridgedb, so bridgedb won't give it out.
And as a third kicker, I expect many of these tools, possibly including Tor, behave poorly when they see a relay descriptor with an ORPort of 0.
This task is worthwhile to do, but it involves many subtasks.
Trac:
Type: task to project 
This should be ultra high priority since i am loosing bridge game with china firewall. They tend to detect obfs3 as suspicious traffic and then do scan on IP discovering tor bridge.
To make this reliable, not only disabling ORPort is needed but also make shared secret to work with bridgedb distributing it to clients.
As temporary workaround i suggest to make list of IPs which are used for running checks on bridge public, so we can allow them to connect into ORPort but drop other traffic.
Trac:
Username: hsn
phw suggests some other potential solutions/workarounds:
22:09 < phw> the bridgespa paper solves this on the transport layer: http://www.cypherpunks.ca/~iang/pubs/bridgespa-wpes.pdf however, it's platform dependent. 22:11 < phw> there's also the kernel patch of the TUM people which they wanted to get into upstream.Replying to elypter:
why not ditch the orport alltogether. if all relays communicate over pluggable transports then active probing will become obsolete.
This is about making the ORPort "ditchable". However, it is not about making bridges communicate to the next hop over PTs, since that would reveal that they are a bridge (and thus nullify most of the work I did for #7144 (moved)).
Adding over nine thousand points, meaning something like "The size of this ticket is large and will require more than one week of work."
In actuality, I estimate this will take a month (or possibly more) work, once the following (prerequisite) tasks are factored in:
- Discuss other ways for the BridgeAuth to conduct reachability testing (#5211 (moved), #13589 (moved)?; related to #7144 (moved) anti-enumeration defenses and prop!#188 (closed)).
- Write a proposal for this ticket.
- Probably deploy something like #6396 (moved) on BridgeDB or some other centralised system which reports to BridgeDB/BridgeAuth. We'd also need to be able to do bridge bandwidth testing over PTs, since the ORPort would be gone. (#17159 (moved))
- Hack on this ticket.
- Revise various specs/proposals.
- Review changes, rinse, repeat.
- Merge.
Trac:
Points: N/A to 9000+