[tor-relays] Publishing bridge contact information

[Karsten Loesing]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 528 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20180212/aa923384/attachment.sig>