On 2018-02-12 11:19, Alexander Dietrich wrote:
On 2018-02-11 00:43, nusenu wrote:
- we could tell operators that running obfs3 and obfs4 is a bad idea
Are you saying obfs3 and obfs4 shouldn't run simultaneously on the same bridge? That would be good to know indeed.
Citing from the IMDEA paper that was mentioned later on this thread:
"The combination of PTs with different security properties raises several security concerns, since the security of the bridge is only as strong as its weakest link. First, an adversary detecting the weakest transport and blocking the IP disables also stronger transports for free, e.g., for the nearly 100 bridges that offer obfs3 or obfs4 in combination with obfs2, which is deprecated and trivial to identify through traffic analysis. Second, it allows an adversary to confirm a bridge, even in presence of transports that implement reply protection. For example, for the most popular combination obfs3+obfs4+ScrambleSuit, offered by 524 bridges, an adversary can confirm a bridge, e.g., identified through traffic analysis [39], through a vertical scan using obfs3 on the candidate IP address."
https://software.imdea.org/~juanca/papers/torbridges_ndss17.pdf
- we could tell operator that exposing their vanilla ORPort is a bad idea
If you block the ORPort, won't the reachability check fail?
Fine question. At least this has been the case in the past, though I know there was discussion and maybe development to overcome this weakness. But even if it's not possible yet, having bridge contact information would allow us in the _future_ to reach out to bridge operators to inform them that they don't have to keep their OR port open anymore, and maybe even shouldn't.
I see how this doesn't fully answer your question. Maybe somebody else knows more about the current state of things.
Kind regards, Alexander
All the best, Karsten