Hi,
in the context of [1] I'm wondering if it makes sense to add bridge support to ornetradar.
If there is any value to automatically detect multiple new bridges:
- Do bridges publish ContactInfo in their descriptor? If not: Why not? (it shouldn't disclose their bridge location)
another raw idea:
- would the bridge auth be willing to publish a randomly generated AS identifier (regenerated daily) that allows new bridges added on the same day to be grouped by that identifier without directly disclosing the AS itself.
Note: This introduces a confirmation opportunity, where attackers can learn the AS in which a new bridge is added if they added a bridge in the same AS on the same day. To reduce this problem it could be a hourly generated identifier.
regards, nusenu
[1] https://lists.torproject.org/pipermail/tor-project/2016-December/000851.html
On 14 Dec. 2016, at 21:09, nusenu nusenu@openmailbox.org wrote:
another raw idea:
- would the bridge auth be willing to publish a randomly generated AS
identifier (regenerated daily) that allows new bridges added on the same day to be grouped by that identifier without directly disclosing the AS itself.
Bridges don't necessarily contact the bridge auth before producing their descriptors. So we'd need a protocol change to do this.
Note: This introduces a confirmation opportunity, where attackers can learn the AS in which a new bridge is added if they added a bridge in the same AS on the same day. To reduce this problem it could be a hourly generated identifier.
How could we avoid an adversary brute-forcing all the possible ASs and days/hours?
We can use the shared random value in the consensus to prevent relays knowing their position on the hidden service hash ring in advance, but there's nothing stopping someone brute-forcing it in arrears.
So we'd need a concrete protocol that would allow correlation, but not be able to be brute-forced. And we'd need something that doesn't have a single point of failure (if only we had two bridge authorities, they could do the shared random protocol).
Hmm, still worth thinking about...
T
another raw idea:
- would the bridge auth be willing to publish a randomly generated AS
identifier (regenerated daily) that allows new bridges added on the same day to be grouped by that identifier without directly disclosing the AS itself.
Bridges don't necessarily contact the bridge auth before producing their descriptors. So we'd need a protocol change to do this.
All that is needed is the IP address and fingerprint of the bridge and that is known by the bridge auth. There should not be any requirement to involve the bridges themself?
How could we avoid an adversary brute-forcing all the possible ASs and days/hours?
I'm not sure I understand what you mean by brute-forcing in this case since I would not suggest any deterministic algorithm (like a hash) that takes an ASname and a timestamp and produces a string but just a AS number -> random id mapping, stored for a day or an hour and deleted after that.
Another way an attacker could take advantage of this: unique AS sign-up rate patterns "everyday there are about x new bridges in AS y" so it doesn't help much if we change the random AS id daily.
Anyway I do not think anything like that will be implemented and very simple detection based on first_seen, nickname, platform, .. is already possible without AS level information.
David, I'm glad you asked about first_seen=1970-01-01 on metrics-team@, I was wondering about the same thing. A bug affecting that timestamp would certainly be rather bad for anything using first_seen as a grouping data point.
On 15 Dec. 2016, at 06:01, nusenu nusenu@openmailbox.org wrote:
How could we avoid an adversary brute-forcing all the possible ASs and days/hours?
I'm not sure I understand what you mean by brute-forcing in this case since I would not suggest any deterministic algorithm (like a hash) that takes an ASname and a timestamp and produces a string but just a AS number -> random id mapping, stored for a day or an hour and deleted after that.
Another way an attacker could take advantage of this: unique AS sign-up rate patterns "everyday there are about x new bridges in AS y" so it doesn't help much if we change the random AS id daily.
If an adversary submits a bridge descriptor from every (popular) AS (in every hour of) every day, they know which AS each bridge is from.
Or, alternately, if they submit a bridge descriptor from an AS they are watching, then they know all the bridges in that AS.
And they don't actually need to be in the AS to submit a descriptor with an IP address from that AS.
T
I'm not sure I understand what you mean by brute-forcing in this case since I would not suggest any deterministic algorithm (like a hash) that takes an ASname and a timestamp and produces a string but just a AS number -> random id mapping, stored for a day or an hour and deleted after that.
Another way an attacker could take advantage of this: unique AS sign-up rate patterns "everyday there are about x new bridges in AS y" so it doesn't help much if we change the random AS id daily.
If an adversary submits a bridge descriptor from every (popular) AS (in every hour of) every day, they know which AS each bridge is from.
Understood, that is what I meant with:
Note: This introduces a confirmation opportunity, where attackers can learn the AS in which a new bridge is added if they added a bridge in the same AS on the same day. To reduce this problem it could be a hourly generated identifier.
Or, alternately, if they submit a bridge descriptor from an AS they are watching, then they know all the bridges in that AS.
And they don't actually need to be in the AS to submit a descriptor with an IP address from that AS.
Ok that makes it bad to a point where it is pointless. I'm surprised that you can get bridge auth to distribute fake bridges for arbitrary IPs - I assume that is not actually the case.
Anyway as I said, no need to pursue this any further, but thanks for the explaination.
nusenu transcribed 3.9K bytes:
Or, alternately, if they submit a bridge descriptor from an AS they are watching, then they know all the bridges in that AS.
And they don't actually need to be in the AS to submit a descriptor with an IP address from that AS.
Ok that makes it bad to a point where it is pointless. I'm surprised that you can get bridge auth to distribute fake bridges for arbitrary IPs - I assume that is not actually the case.
Hi nusenu!
Right, these bridges do not actually get distributed.
The BridgeAuthority accepts the descriptor, and, assuming it can't open a connection to the bridge on the IP:port within the signed bridge descriptor, it doesn't mark the bridge with the "Running" flag. Later, BridgeDB receives a tarball of all the new descriptors from the BridgeAuthority, and BridgeDB chucks out the bridges without the Running flag (i.e. they don't get added to the hashring). [0]
[0]: https://gitweb.torproject.org/user/isis/bridgedb.git/tree/bridgedb/Bridges.p...
Best regards,
On Wed, Dec 14, 2016 at 10:09:00AM +0000, nusenu wrote:
in the context of [1] I'm wondering if it makes sense to add bridge support to ornetradar.
If there is any value to automatically detect multiple new bridges:
- Do bridges publish ContactInfo in their descriptor? If not: Why not?
(it shouldn't disclose their bridge location)
From my understanding, bridge descriptors may include ContactInfo, but
Collector removes it before publishing. So you can distinguish descriptors that originally had ContactInfo set from those that did not, but you can't tell what the ContactInfo was.
https://collector.torproject.org/#bridge-descriptors
- Replace contact information: If there is contact information in a
descriptor, the contact line is changed to somebody.
Dear CollecTor devs,
https://collector.torproject.org/#bridge-descriptors
- Replace contact information: If there is contact information in a
descriptor, the contact line is changed to somebody.
would you be willing to change this to allow 1:1 mapping (one way but not a hash) from the actual contactInfo to a random id of your choosing to allow for grouping of bridges based on that string? If you like the random id could be rotated daily but since it is likely a static contactinfo this might be pointless.
And if this is something you would consider (I would file a trac ticket then), the next point would be to add it to onionoo :)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 12/14/2016 08:30 PM, nusenu wrote:
Dear CollecTor devs,
Hi nusenu!
https://collector.torproject.org/#bridge-descriptors
- Replace contact information: If there is contact information in a
descriptor, the contact line is changed to somebody.
would you be willing to change this to allow 1:1 mapping (one way but not a hash) from the actual contactInfo to a random id of your choosing to allow for grouping of bridges based on that string? If you like the random id could be rotated daily but since it is likely a static contactinfo this might be pointless.
Something like that is done monthly for bridge ports: '4. Replace TCP port with TCP port hash ...'
And if this is something you would consider (I would file a trac ticket then), the next point would be to add it to onionoo :)
Please, open a trac ticket for discussing and analyzing this.
Thanks!
Kind regards, iwakeh
-
David Fifield -
isis agora lovecruft -
iwakeh -
nusenu -
teor