Many bridges (22%) have nickname "ki"
This is a bit of a followup to my earlier post on obfs4 bridges with formulaic nicknames: https://lists.torproject.org/pipermail/tor-project/2016-November/000809.html Those bridges are still there, but today I noticed a new weirdness: 756 bridges all having the nickname "ki". 756 is 21.8% of the total number, 3464. At the moment, "ki" far outnumbers every other nickname, apart from "Unnamed": $ wget -O bridges.json https://onionoo.torproject.org/details?type=bridge $ ./nodeinfo < bridges.json | awk '{print $2}' | sort | uniq -c | sort -rn | head 1519 Unnamed 756 ki 16 UbuntuCore133 6 anonymous 5 hacktheplanet 4 ididnteditheconfig 3 default 3 CoolComputers 2 UbuntuCore95 2 masterFluellen All the "ki" bridges have other things in common: they run no pluggable transports and they have platform "Tor 0.2.8.10 on Linux". Their last_restarted time ranges from 2016-12-05 17:51:45 to 2016-12-13 15:34:06. Here is a sample of 20 of them. $ ./nodeinfo < bridges.json | awk '$2 == "ki" {print}' | sort -k 7 | head -n 20 hashed_fingerprint nickname first_seen last_seen last_restarted platform transports F69BE147A7CB0A1EDAE8A5E9EFF70E672CF117DF ki 1970-01-01 00:00:00 2016-12-06 17:41:03 2016-12-05 17:51:45 Tor 0.2.8.10 on Linux FA0F7052B6BB5572960BB08BD44C58A143F9B227 ki 1970-01-01 00:00:00 2016-12-06 17:41:03 2016-12-05 18:07:00 Tor 0.2.8.10 on Linux 1431FFE68CFC0383456619D87431AF23FFA2E183 ki 2016-12-05 18:41:03 2016-12-06 17:41:03 2016-12-05 18:21:30 Tor 0.2.8.10 on Linux 945B0892CADA14722EA3D28354995D5907CFB3AB ki 2016-12-05 18:41:03 2016-12-06 17:41:03 2016-12-05 18:34:04 Tor 0.2.8.10 on Linux DDB025FD0BC51FE5391D8A4F80E773334D2E523C ki 1970-01-01 00:00:00 2016-12-06 18:41:03 2016-12-05 18:52:16 Tor 0.2.8.10 on Linux DB4245D09CC3C705CAD292C398DDA1ABFB40DB52 ki 1970-01-01 00:00:00 2016-12-06 18:41:03 2016-12-05 19:07:01 Tor 0.2.8.10 on Linux 772D118449E0F938657BBD5F472088270D742F39 ki 2016-12-05 19:41:03 2016-12-06 18:41:03 2016-12-05 19:21:27 Tor 0.2.8.10 on Linux F8DE4C2595715190D69732FBB47EAA17255FCF3A ki 2016-12-05 19:41:03 2016-12-06 18:41:03 2016-12-05 19:34:00 Tor 0.2.8.10 on Linux CA7ACBB15A80381BB216939AA3D6345D4E2A6CE5 ki 1970-01-01 00:00:00 2016-12-06 19:41:03 2016-12-05 19:51:51 Tor 0.2.8.10 on Linux 60AE31B0D81ABE763264D442E0A8A48161ADCBD6 ki 1970-01-01 00:00:00 2016-12-06 19:41:03 2016-12-05 20:07:42 Tor 0.2.8.10 on Linux 0522394400AA8425445742828C577A560159AAC3 ki 2016-12-05 20:41:03 2016-12-06 19:41:03 2016-12-05 20:21:31 Tor 0.2.8.10 on Linux 8A9BFB4DABD6D4F0AD692C414FB3E75DC33ED47E ki 2016-12-05 20:41:03 2016-12-06 19:41:03 2016-12-05 20:34:01 Tor 0.2.8.10 on Linux F9AE2B2E26EACE32A6BA697118F73AC20DAA0A01 ki 1970-01-01 00:00:00 2016-12-06 20:41:03 2016-12-05 20:52:33 Tor 0.2.8.10 on Linux DAFFEED5B1268C8B7BEEA3AD411690E7C74024EB ki 1970-01-01 00:00:00 2016-12-06 20:41:03 2016-12-05 21:06:31 Tor 0.2.8.10 on Linux 7690F311EE18901A2C2B0353DF868C31C43746C7 ki 2016-12-05 21:41:03 2016-12-06 20:41:03 2016-12-05 21:21:29 Tor 0.2.8.10 on Linux C51B3FA6A60D116C84C867F2DC2AE0BE33CB117F ki 2016-12-05 21:41:03 2016-12-06 20:41:03 2016-12-05 21:34:00 Tor 0.2.8.10 on Linux 8F6C3F388EDD6D9400B5743AE29DE3AAB88E43E9 ki 1970-01-01 00:00:00 2016-12-06 21:41:03 2016-12-05 21:51:56 Tor 0.2.8.10 on Linux 0547724D0F88377D5A0F01D90B8BF523B869326A ki 1970-01-01 00:00:00 2016-12-06 21:41:03 2016-12-05 22:07:16 Tor 0.2.8.10 on Linux EE969338212C905E0425394B658FEDE1CF3BDE4E ki 2016-12-05 22:41:03 2016-12-06 21:41:03 2016-12-05 22:21:28 Tor 0.2.8.10 on Linux EFCD5C5E5A608DC017980A4F67CCDB51BBA50FD4 ki 2016-12-05 22:41:03 2016-12-06 21:41:03 2016-12-05 22:34:15 Tor 0.2.8.10 on Linux
On Tue, 13 Dec 2016 10:37:31 -0800 David Fifield <david@bamsoftware.com> wrote:
Should both groups be dropped at the BridgeAuth or what? As far as I am aware, there is nothing that is doing Sybil detection at the Bridge level, and I don't really think that's an arms race that's winnable (even at the standard relay level, it feels like an uphill battle). If I were to hypothesize, it's probably someone's botnet/malware or something (in both cases), but that's just a guess and it could be something either more nefarious, or more benign. Regards, -- Yawning Angel
Yawning Angel wrote:
Yeah, it's probably a good idea to drop all of the `ki` bridges until/unless a pattern appears. I'm curious whether it's a bunch of people using the same docker image or something, but that seems like quite a few bridges.... Of course, if they all die off once dropped from BridgeDB then that's an answer in its own right. ~Griffin -- Accept what you cannot change, and change what you cannot accept. PGP: 0x03cf4a0ab3c79a63
On Tue, 13 Dec 2016 16:26:02 -0500 David Goulet <dgoulet@ev0ke.net> wrote:
Looking forward... What are we going to do/can we do when the person wises up and changes the bridge naming scheme? IMO we *should* run as much of the sybil detection stuff that we can on bridges, but this relies on code that someone has to write, and infrastructure that someone has to set up, so my opinion probably doesn't count for much since I do not have the time to do either. Should our Bridge anomaly detector have access to unsanitized bridge descriptors? Does it need to? Regards, -- Yawning Angel
On 13 Dec (16:26:02), David Goulet wrote:
I want to bump this here btw.... I don't feel very comfortable with those bridge still around so we should REALLY block them soon. If I remember correctly, Roger told me on IRC that we either have to go through the BridgeAuth directly with reject rules (unconfirmed) or we block them on BridgeDB. I need someone with knowledge here and Isis needs to be in the loop as she basically run both service :). Thanks! David
On Tue, Dec 20, 2016 at 11:39:36AM -0500, David Goulet wrote:
Right. I think we'll be happier doing it on BridgeDB -- that way we still learn about all the bridges (they get collected on the bridge auth, they get into the metrics database, etc), but we don't give them out to users unless we want to. That said, doing it that way involves teaching bridgedb about some sort of blacklist mechanism, and that needs somebody to write the code. Whereas I think the Tor code should work as is on the bridge authority, with code like if (authdir_mode_handles_descs(options, -1)) { /* reload the approved-routers file */ if (dirserv_load_fingerprint_file() < 0) { it looks like it should all Just Work, and if it doesn't, that's a bug we should fix. In summary, we should find a strategy that Isis will actually do, rather than the ideal one that maybe she won't do. --Roger
David Goulet transcribed 3.0K bytes:
Hi! Sorry, I missed this thread and David kindly made me aware of it last Friday. I've patched BridgeDB (#21162) and added a file to blacklist these bridges by fingerprint. However, looking at the onionoo results which David original pasted, the IP addresses are all different (10.x.x.x) in onionoo for the ki bridges. Perhaps something is wrong with onionoo's hashed-IP file thing? However, looking at both the BridgeAuthority and BridgeDB, these bridges all share only 3 distinct IP addresses. This seems to suggest to me that only 6 of them would have made it into the BridgeAuthority networkstatus-bridges file, since tor only allows 2 instances from any given IP address. Looking at the networkstatus-bridges on BridgeDB, this appears to be the case, and grepping the logs I only see a couple instances of "ki" bridges being added to the database per hour (and each hour these are the same few) so it appears to be the case that nearly none of these were ever distributed. In any case, the few that made it into the database should now be blacklisted. Could I maybe request that, if there's something super important you want from me, that the subject be something like "ISIS DO THIS RIGHT NOW", please? I can't read every single mailing in any semblance of a timely fashion if something is actually urgent. Thanks. :) Best regards, -- ♥Ⓐ isis agora lovecruft _________________________________________________________ OpenPGP: 4096R/0A6A58A14B5946ABDE18E207A3ADB67A2CDB8B35 Current Keys: https://fyb.patternsinthevoid.net/isis.txt
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 09/01/17 21:59, isis agora lovecruft wrote:
Not a bug, a feature (https://collector.torproject.org/#bridge-descriptors):
All the best, Karsten -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBCAAGBQJYdJmpAAoJEC3ESO/4X7XBu6cIAIa4viKRAxGqxCE7wZBavfjT hZ+XfSkdC8MaEZsAy/cjYL0PAY6I1hmJV1epIZVgW1J72YGjRiaq+lXsRzeMC91H 1fx7p28OK4qEp4eTxaqTUQyZV2kdRtOnL60HCc4EhM2ayFTRwtvI5RRmFNitwt0E o5MQE1fF6OVMoQ6K9VYi9XRzusXsTLx6S/gGWnjjc7iBXDUyaJ9zeHK2HywUn2n+ SWVG05E9aLjj37sFz+FRouAkcl6+combaLGBC8qzCG03fjM7vInZyXRuB8Wh1f+E bXfK1dlWVN1uJcNQIUkOvg/4RsVUCjMxPqr1+1XwUZdOa+Epy4WVWvnBfPgWBH4= =Tclw -----END PGP SIGNATURE-----
Karsten Loesing transcribed 1.6K bytes:
Aha! Got it. So the sanitised IP addresses are dependent upon the bridge identity too, meaning that 3 distinct IP addresses running ~700 tor instances appear in onionoo on ~700 different IP addresses and 22% of the bridges, when in reality they're only 0.2%. Best, -- ♥Ⓐ isis agora lovecruft _________________________________________________________ OpenPGP: 4096R/0A6A58A14B5946ABDE18E207A3ADB67A2CDB8B35 Current Keys: https://fyb.patternsinthevoid.net/isis.txt
On Tue, Dec 13, 2016 at 09:11:17PM +0000, Yawning Angel wrote:
I would put my money on "somebody's research project, which aims to show how easy it is to do what they're doing." Then they'll tell everybody how broken the design is, without coming up with any helpful fixes or improvements. So not exactly malicious per se, but for sure indirectly harmful. If only we had so many hundreds of thousands of bridges that 700 were not a big deal. I agree with you that the Sybil arms race is tougher here compared to the public relays, because some of the characteristics we might use for correlation are weakened by the bridge anonymization process. I wouldn't object if somebody wants to try to fight the arms race, but if it leads to everything becoming more complicated and harder to use, I suspect I would call that a failure in fighting the arms race. I wonder if there are more systemic solutions we can consider, ranging from "just inform people that bridges from bridgedb are dangerous" to "we only give out bridges run by vetted people". --Roger
On Tue, 13 Dec 2016 17:14:49 -0500 Roger Dingledine <arma@mit.edu> wrote:
Now that you drive my thinking along those lines, we should have learned from past experience and taken aggressive action back in November when dcf first pointed them out because, it might be researchers from CERT (or the like) again. So, I'm more in favor of blacklisting them with extreme prejudice, and the sooner the better.
The first should happen regardless, because as much as I don't trust my guard, I trust Bridges less, and so should everyone else (the barrier to entry being lower would be the primary distinction here). I have mixed feelings regarding the latter. While I don't doubt that it would be effective, the general public being able to contribute capacity to the network is probably a good thing. Other ideas: 1) Impose similar requirements on uptime/stability/bandwidth before we give bridges out. Likely to be unpopular among the "I want to contribute to the network from a residential line" crowd, and trivial to game. 2) "Meek/webrtc is the way of the future.". Which in effect is "we only give out bridges run by vetted people". Regards, -- Yawning Angel
On Tue, Dec 13, 2016 at 10:37:31AM -0800, David Fifield wrote:
Upcoming research paper mentions the "ki" bridges, but still doesn't determine their purpose: https://software.imdea.org/~juanca/papers/torbridges_ndss17.pdf Section V-A The yellow middle bar represents a cluster of 3 bridges run by the same organization, that we call by their nickname, Ki, which change fingerprint up to once an hour (but keep their IP addresses stable, see Section VI). The Ki cluster produced a few dozen fingerprints in July 2012, jumped to a few hundreds in December 2012 and to a few thousands in February 2014. In March 2016, those 3 bridges are responsible for 32% of all fingerprints, corresponding to 7% of the active fingerprints and 68% of the inactive fingerprints, as most of their fingerprints do not live long enough to obtain the Running flag. After discounting those extraneous fingerprints, the number of active fingerprints in April 2016 is slightly over 5K. Section V-D Port 444 is a special case since in principle is associated to the Simple Network Paging Protocol (SNPP), a not so popular protocol. However, according to CollecTor data, roughly 3K active fingerprints are using it on April 2016. The reason for this is that this OR port is used by the Ki bridges that change fingerprint often, as introduced in Section V-A. Those Ki bridges artificially inflate the usage of this OR port, a behavior that does not manifest on other OR ports. Section VI-A Overall, 94.1% of the bridge IP addresses did not change fingerprint, 5.5% changed fingerprint once, and 0.4% changed fingerprint multiple times. The bridges with multiple fingerprint changes include the 3 Ki bridges, which present a different fingerprint every time we connect to them (on a closer look we find that they change fingerprint roughly every hour). Furthermore, we observe that over 70% of the IP addresses with fingerprint changes belong to 2 clusters of private bridges each using multiple nearby IP addresses. These IPs change fingerprint on the same dates, so it is possible that bridges in each cluster were reassigned IP addresses on those dates.
participants (7)
-
David Fifield -
David Goulet -
Griffin Boyce -
isis agora lovecruft -
Karsten Loesing -
Roger Dingledine -
Yawning Angel