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