Opened 6 years ago

Closed 6 years ago

#9854 closed defect (fixed)

Removing or not sanitizing ContactInfo lines in bridge descriptors

Reported by: karsten Owned by:
Priority: Medium Milestone: Tor: 0.2.4.x-final
Component: Core Tor/Tor Version:
Severity: Keywords: tor-bridge
Cc: kostas@…, phw Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

There's an interesting question in the Tor StackExchange beta:

I'm guessing that a bridge uploads its ContactInfo to the bridge
authority, so there's a point of contact for the Tor project.

Is this information available to any other parties, i.e. users requesting
bridges, or people randomly connecting to IP addresses looking for Tor
installations?

In practice, users of a bridge will be able to learn the bridge's ContactInfo line, because they download the bridge's descriptor.

But Tor people will have a hard time to do that, because this line is removed from bridge descriptors in the sanitizing process. One needs access to the non-sanitized descriptors, which limits the set of people to maybe five. I don't remember a single time in the past couple of years when we tried to contact bridge operators using provided contact information.

This is rather unexpected for bridge operators, I'd think. I guess most bridge operators would expect their contact information to be known to Tor project people and used for debugging only.

Three options:

  1. We conclude we don't need the contact line for bridges, because we wouldn't contact the bridge operator anyway. Bridges should remove that line from their descriptor before uploading.
  2. We decide this information is important and that we should have it available more easily. We don't remove the ContactInfo line when we sanitize bridge descriptors.
  3. We don't change anything, because everything's fine as it is. At least now we know this information is theoretically available to a few Tor people and definitely available to bridge users.

Child Tickets

Change History (15)

comment:1 Changed 6 years ago by nickm

I'd suggest mentioning this ticket on tor-talk or tor-relays to ask what bridge operators would prefer it to do.

comment:2 Changed 6 years ago by wfn

At least as far I (as a very-small-time bridge operator, i.e.) am concerned, I'm fine with option 2, i.e.

We decide this information is important and that we should have it available more easily. We don't remove the ContactInfo line when we sanitize bridge descriptors.

Perhaps there's some critical vulnerability and all bridge operators should upgrade as soon as possible (they should of course follow Tor-vuln-related news anyway); etc.

I don't know what other bridge operators put in the ContactInfo; perhaps someone with access to non-sanitized descriptors could try and browse through a representative sample, to see if anyone is including any critical info (e.g. perhaps there are mail addresses with a domain that resolves to the IP address used by the bridge; someone could scrape over bridges from Onionoo / descriptors (when they include ContactInfo), and try extracting some exit IPs; probably highly unlikely though / doesn't sound plausible?)

Is any kind of harassment possible (someone extracts email addresses from sanitized bridge descriptors, etc.) - should bridge operators be left to be as anon as possible? (They should be ready for this kind of thing anyway, I suppose.) Many social impure parameters.

TL;DR option 2 is worth some discussion, IMHO.

comment:3 Changed 6 years ago by wfn

Cc: kostas@… added

comment:4 in reply to:  2 Changed 6 years ago by sysrqb

Replying to wfn:

I don't know what other bridge operators put in the ContactInfo; perhaps someone with access to non-sanitized descriptors could try and browse through a representative sample, to see if anyone is including any critical info

Over 90% contain email addresses. A few only contain handles, a small fraction contain openpgp short ids or fingerprints, some actually contain an entire public key. Some contain a URL. (These properties are not necessarily disjoint, e.g. some have email address and pgp short id).

comment:5 in reply to:  1 Changed 6 years ago by adietrich

Replying to nickm:

I'd suggest mentioning this ticket on tor-talk or tor-relays to ask what bridge operators would prefer it to do.

Personally, I expected the Tor project to have access to this information, but not bridge users. I hadn't read the Bridge Specification, though.

comment:6 Changed 6 years ago by karsten

Here's a crazy idea: should we extract email addresses from bridge operators and ask them what they expected when writing their email addresses there?

comment:7 in reply to:  description ; Changed 6 years ago by phw

Replying to karsten:

  1. We conclude we don't need the contact line for bridges, because we wouldn't contact the bridge operator anyway. Bridges should remove that line from their descriptor before uploading.

I don't think that's a good option. Especially with more and more pluggable transports emerging, it would certainly come in handy to be able to contact bridge operators.

  1. We decide this information is important and that we should have it available more easily. We don't remove the ContactInfo line when we sanitize bridge descriptors.

Personally, I'm leaning towards that option. It would be consistent with how we treat bridges, i.e., you don't get them easily but when you have one, it's almost like a relay. On the other hand, I have no strong feelings about this and there might be good arguments against it so the safe bet is probably option 3.

Here's a crazy idea: should we extract email addresses from bridge operators and ask them what they expected when writing their email addresses there?

That would make sense. After all, that's what the ContactInfo is for, isn't it? :)

comment:8 Changed 6 years ago by phw

Cc: phw added

comment:9 in reply to:  description ; Changed 6 years ago by rransom

Replying to karsten:

  1. We decide this information is important and that we should have it available more easily. We don't remove the ContactInfo line when we sanitize bridge descriptors.

I thought a bridge descriptor's contact line was removed for the same reason that its nickname is redacted -- to prevent an attacker from learning that the bridge may be ‘near’ one or more relays.

comment:10 in reply to:  9 Changed 6 years ago by karsten

Replying to rransom:

Replying to karsten:

  1. We decide this information is important and that we should have it available more easily. We don't remove the ContactInfo line when we sanitize bridge descriptors.

I thought a bridge descriptor's contact line was removed for the same reason that its nickname is redacted -- to prevent an attacker from learning that the bridge may be ‘near’ one or more relays.

There's this risk, yes. We decided for nicknames that finding bridges by nickname is more important than the potential of losing a bridge because it's located nearby a relay with similar nickname. #5684 has some parts of that discussion, and I remember there was some discussion on tor-dev@.

But you're right. If we want to stop sanitizing contact lines, we need to have a similar discussion on tor-dev@. The risk of finding bridges using similar contacts might even be higher than for nicknames.

comment:11 in reply to:  7 Changed 6 years ago by karsten

Replying to phw:

Replying to karsten:

Here's a crazy idea: should we extract email addresses from bridge operators and ask them what they expected when writing their email addresses there?

That would make sense. After all, that's what the ContactInfo is for, isn't it? :)

I just asked a random sample of 20 bridge operators what they think. Will post poll results here.

comment:12 Changed 6 years ago by karsten

Here's what I asked a random subset of 20 bridge operators:

What did you expect when adding your email address to your bridge's configuration, and what did you not expect? Can you pick one of the following three answers, please?

  1. "I didn't expect anyone to ever see that email address!"
  2. "I expected that only Tor people see that email address along with users of my bridge."
  3. "I'd actually be fine if anyone sees it, and I wouldn't mind if the address were contained in a public archive."

Note that there's no reply 1.5 "I expected that only Tor people see that email address, but users of my bridge should not see it." This isn't possible by design, because bridge users need your bridge's descriptor which contains your contact information. So, if this was what you had expected, please decide for either 1 or 2 above.

Here's how bridge operators replied:

  1. 1 person replied 1. The operator suspects that the provided email address was abused for spam, though I'm not convinced this is the really the case. Probably coincidence.
  2. Nobody replied 2.
  3. 5 people replied 3. One referred to the default torrc already containing a warning that Google indexes contact lines. Another one argued that contact information is already effectively public, but only to a class of people where they don't control membership in that class (bridge users), so they wouldn't mind to include everyone else, too.
  4. 14 people did not respond.

I'm leaning towards not sanitizing contact lines in bridge descriptors. But that requires a new discussion on tor-dev@, and it possibly requires re-processing the bridge descriptor archives. I currently lack the time for either, but maybe I'll open a new ticket for this in a few months.

For the moment, I'd like to make it clearer to bridge operators that their contact information is not kept secret. Users of a bridge already know it, and should we decide to stop sanitizing that information, the whole world will know.

How about we clarify the default torrc:

## Contact info to be published in the directory, so we can contact you
## if your relay or bridge is misconfigured or something else goes wrong.
## We archive all descriptors containing these lines, and Google indexes
## this, so spammers might also collect it.

comment:13 Changed 6 years ago by nickm

I think if we're clarifying that, we should also clarify it in the manpage. I'd be happy to take a patch for this.

comment:14 Changed 6 years ago by karsten

Made an attempt to clarify this in the man page and sample torrc here: https://gitweb.torproject.org/karsten/tor.git/shortlog/refs/heads/task-9854

comment:15 Changed 6 years ago by nickm

Milestone: Tor: unspecifiedTor: 0.2.4.x-final
Resolution: fixed
Status: newclosed

Thanks; cherry-picked onto 0.2.4 and merged forward.

Note: See TracTickets for help on using tickets.