Re: [tor-dev] Can we stop sanitizing nicknames in bridge descriptors?

["Sebastian G. <bastik.tor>" <bastik.tor@xxxxxxxxxxxxxx>]

Karsten Loesing, 02.05.2012 14:30:

> we're discussing in #5684 whether we can stop sanitizing nicknames in
> the bridge descriptors that we publish

I don't mind, but...

> The reason was that "bridge nicknames might give hints on the location of
> the bridge if chosen without care; e.g. a bridge nickname might be very
> similar to the operators' relay nicknames which might be located on
> adjacent IP addresses."

That doesn't seem to have changed. Anyone can set up an relay and a
bridge on "adjacent IP addresses".

It's not recommend to set up bridge and relay on the same network. e.g.
1.2.3.4:443 and 1.2.3.4:444. Since most adversaries don't block 1.2.3.4
completely I wondered how much clients would have problems connecting to
such a bridge.

In the mentioned case (adjacent addresses like 1.2.3.4:443 and
1.2.3.5:443) it would be different. I assume it would be much better.

How much damage would be done if a certain percentage of bridges would
be (both at the same time)
a) named similar
b) and actually be closed together (based on IP)?

Do similar names actually mean that bridges are located where the relay
is? (Apparently you've got the data to see these correlations)

At any point and regardless how small the damage might be you (the Tor
people) should raise awareness to name the bridge in a way that it does
not reveal a adjacent IP.

> This was an easy decision back then, because we didn't use the nickname
> for anything.

"We don't need it, so better remove it." I really like that.

> This has changed with #5629 where we try to count EC2
> bridges which all have a similar nickname.  So, while we don't have that
> information, there'd now be a use for it.

As #5684 mentions there would be another way.

- Use the extra platform string. (Don't know how good that would work)

> Another advantage of having
> bridge nicknames would be that they're easier to look up in a status
> website like Atlas (which doesn't support searching for bridges yet).

That's of course something that's not possible with the platform string.

For me it would be nice to have, but could live without it, when it's
not safe enough. If there's a doubt about it's safety, I would stay away
from changing it.

> Regarding the reasoning above, couldn't an adversary just scan adjacent
> IP addresses of all known relays, not just the ones with similar
> nicknames?

As an adversary I would look up all known relays and scan for useful
services. When 1.2.3.4:80 hosts a website I whitelist it and block all
other 1.2.3.4:IPs, especially the ORport. If enough resource are
available I'd scan "adjacent addresses".

> And are we giving away anything else with the nicknames?

Maybe it's location ;)

As I read "hints on the location" for the first time; I though it would
mean that "TowerBridge" or "BridgeofLondon" would be bad since it could
hint to London.

> It would be great to get some feedback here whether leaving nicknames in
> the sanitized descriptors is a terrible idea, and if so, why.

Probably there are many unnamed bridges. Should someone find its bridge
named like its relay he still can rename them.

There's a goal (or some), so it would have a purpose.

> If nobody objects within the next, say, two weeks, I'm going to make an
> old tarball from 2008 available with original nicknames.

I don't object. As you have the tarballs available (in a safe and secure
place, I hope) you can see if there are relays and bridges which give
away anything, especially "adjacent addresses".

Since your message is older than five hours and I'm the only one that
replies to it so far (which makes me feel like I shouldn't have), I
assume that there is not so much to object.

I like that you wait....

Could it make sense to ask the same question on the tor-relay list? Here
you (the Tor people) have more data again and know who subscribed to
both lists. I for myself assume that relay and bridge operators, which
could object, because it's their naming scheme that could reveal
something, are more likely to be subscribed to tor-relays.

> And if nobody
> screams, I'll provide the remaining tarballs containing original
> nicknames another two weeks later.

Probably two weeks later, since unpacking, processing and re-packing
takes some time :) I know the sanitized ones are large when they are
unpacked. Windows needs some time to delete the extracted files.

> Thanks!
> Karsten

Thanks for your work.

Regards,
bastik_tor
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev