Re: [tor-dev] automatically detect many new identical/similar bridges
>> 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. signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] CollecTor: contactinfo sanitization on bridge descriptors (was: automatically detect many new identical/similar bridges)
Dear CollecTor devs, > https://collector.torproject.org/#bridge-descriptors >> 5. 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 :) signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] automatically detect many new identical/similar bridges
On Wed, Dec 14, 2016 at 10:09:00AM +, 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 > 5. Replace contact information: If there is contact information in a > descriptor, the contact line is changed to somebody. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Release: sandboxed-tor-browser 0.0.2
Roger Dingledine: > On Sat, Dec 10, 2016 at 08:52:47PM +, Yawning Angel wrote: >> I tagged sandboxed-tor-browser 0.0.2 (0.0.1 is also tagged, but it has >> a few issues), so this is the obligatory release announcement. >> >> Official binaries should be available sometime next week, so I strongly >> suggest that people wait till then, unless they feel confident in >> installing the build time dependencies, and building the binary. > > Thanks Yawning! > > I also look forward to the binaries that are coming this week. From now on the latest binaries we ship can easily be found on https://www.torproject.org/projects/torbrowser.html.en#downloads-sandbox Georg signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] automatically detect many new identical/similar bridges
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 signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
