If you added 15 relays on 2017-02-24 (yesterday) on AS38478, please consider setting ContactInfo and MyFamily in your torrc (and maybe a more recent tor version).
thanks
ornetradar@riseup.net:
Looks like the same operator to me:
+ 11 relays added on 2017-02-25 on Linode AS:
1 | 0 |12:00:37| 45.79.99.148 | us | 9001 | 9051 |0.2.8.9 | None | chop | 1 1 | 0 |13:06:09| 45.79.107.155 | us | 9001 | 9051 |0.2.8.9 | None | salad | 1 1 | 0 |13:11:00| 139.162.72.106 | jp | 9001 | 9051 |0.2.8.9 | None | prawn | 1 1 | 0 |13:31:02| 139.162.114.105 | jp | 9001 | 9051 |0.2.8.9 | None | lemon | 1 1 | 0 |14:10:53| 139.162.24.203 | sg | 9001 | 9051 |0.2.8.9 | None | pepper | 1 1 | 0 |14:16:09| 139.162.59.229 | sg | 9001 | 9051 |0.2.8.9 | None | chilli | 1 1 | 0 |14:49:54| 139.162.196.127 | gb | 9001 | 9051 |0.2.8.9 | None | paste | 1 1 | 0 |15:03:08| 139.162.204.227 | gb | 9001 | 9051 |0.2.8.9 | None | noise | 1 1 | 0 |15:13:18| 139.162.170.175 | de | 9001 | 9051 |0.2.8.9 | None | without | 1 1 | 0 |15:34:14| 45.33.29.170 | us | 9001 | 9051 |0.2.8.9 | None | gas | 1 1 | 0 |15:38:32| 139.162.173.102 | de | 9001 | 9051 |0.2.8.9 | None | reason | 1
nusenu:
This group is still growing.
Note that the following table is _not_ sorted by FP.
The FP links these relays even across ISP, and given the FP column pattern it might be obvious what they are after.
They do not have the hsdir flag yet.
https://raw.githubusercontent.com/nusenu/tor-network-observations/master/201...
Is there a tool out there that tells me which HSDir is/will probably be responsible for a given onion address (and at what time)?
thanks, nusenu
There's no tool, unless you can reverse SHA1. (Or brute-force a set of popular onion addresses.)
In short, it's the first 3 fingerprints following descriptor-id:
permanent-id = H(public-key)[:10] descriptor-id = H(permanent-id | H(time-period | descriptor-cookie | replica)) where H is SHA1.
The spec is: https://gitweb.torproject.org/torspec.git/tree/rend-spec.txt#n222 https://gitweb.torproject.org/torspec.git/tree/rend-spec.txt#n505
The implementation is: https://gitweb.torproject.org/tor.git/tree/src/or/rendcommon.c#n127
As an aside, this attack is not possible with next-generation hidden services, because the HSDir identities are hashed with the daily shared random value: https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-ng.tx...
T
-- Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org ------------------------------------------------------------------------
I probably was not very clear in my question. I'm not aiming for the reverse path, just the normal calculation a tor client does given an onion address but instead of just calculating the current descriptor-id, print descriptor-ids for the future N days for onion address M (for the pre-prop224 world).
nusenu:
For the "current-only" case you might use stem: https://gist.github.com/nusenu/8339cfd5351b64c47676241a40ee2942
On Tue, Feb 28, 2017 at 02:09:00AM +0000, nusenu wrote:
FYI https://gist.github.com/nogoegst/895dde228496e04f409fc6d160a5de5a
$ go run onion-desc-advance.go -time 1488288001 yrcfcqhja2ide7yh
prints descriptor IDs for the given time for replica #1 and #2.
HTH -- Ivan Markin
Ivan Markin:
Thanks for this.
Shouldn't the first 2 or 3 hex digits of your output (after converting them to hex) without time option and the actual intro point FPs match when run at roughly the same time?
example for duckduckgo:
./get-intro-points.py 3g2upl4pq6kufc4m [1] 3g2upl4pq6kufc4m:56782537778BEFC5A48080B58BE01E814AF9B5D3 3g2upl4pq6kufc4m:769DBA4C0C992FCEA080618833FD7BF5AC1F4F41 3g2upl4pq6kufc4m:744B753C7F5E0C6BDD240EE5D879A36C650D2B00
go run descriptor-id-calc.go 3g2upl4pq6kufc4m replica #0: sv5uuknuqvjgquf4hu4m6tvcyuyiyvw7 -> hex: 957B4A29B485526850BC3D38CF4EA2C5308C56DF
replica #1: crpc4lkarusgflm5nblslpopg5qpvw7i -> hex: 145E2E2D408D2462AD9D685725BDCF3760FADBE8
they start with 95.. and 14.. but the actual intro points start with 56.., 76.. and 74.. ?
thanks
[1] https://gist.github.com/nusenu/8339cfd5351b64c47676241a40ee2942
On Thu, Mar 02, 2017 at 01:11:00PM +0000, nusenu wrote:
tldr: HSDir != IntroPoint.
Introduction points are chosen by random by an onion service and unknown in advance. What is known in advance is only the onion address. Descriptor ID determines which HSDirs are responsible for storing corresponding descriptor. List of the current IntroPoints are embedded into descriptor (that's the reason we have descriptor thing in the first place).
-- Ivan Markin
nusenu:
Nusenu, thank you for reporting these relay. They are now in the process of being removed from the network.
I really appreciate the careful attention that you pay to the Tor network. Many thanks for keeping users safe.
Donncha O'Cearbhaill:
Thanks for letting us know.
It would be nice if you could share:
- if you reached out to the operator (via abuse contacts) - removal reason - what was removed - method (by FP, IP, IP-range, ...) - how long they will be blacklisted - time of removal
thanks, nusenu
On 28 Feb (02:09:00), nusenu wrote:
Hello!
I'll try to help out as much as I can here.
We do that if a valid contact address is present. In this case, we had only one I believe and still no response. Email was sent yesterday ~afternoon EST.
Proximity of fingerprint indicates a clear attempt at insertion in the hashring for an (some) onion address. We are *always* better safe than sorry with bad relays so even without a 100% confirmation, we go ahead.
That, we don't disclose for obvious reasons that if the attackers can see what we removed and when, it makes it easier for them to just adapt in time. Only subscribers to bad-relays@ can know this.
However, those reject/badexit entries at the directory authority level expire after a time period and when they do, they become public here in this DocTor script that monitors any relay that we've expired and will be there for a 6 months period:
https://gitweb.torproject.org/doctor.git/tree/data/tracked_relays.cfg
After that 6 months, you can find commit like this that removes a bunch of them:
https://gitweb.torproject.org/doctor.git/commit/data?id=f89e3dca452a0d776eed...
We always reject both FP and IP. Sometimes, it can be a full network range. Depends on the attack.
The standard time period is 90 days *but* it's still a human that does that so it goes beyond that time period sometimes. *HUGE* network block though, we are more careful at not extending too much the reject time.
We don't disclose that for now. Only subscribers to bad-relays@ can know this.
There has been *MANY* discussions about having this reject list public and everything in the open. I believe it wasn't full agreement in the end but for now it went towards keeping it close.
Thanks! David
thanks, nusenu
David Goulet:
Are you also trying to find the matching onion address(es) that the given relay IDs would become HSDirs due to their position on the ring?
Out of curiosity (which onions were they after?) I generated the descriptor-ids for ~180 onions for the coming 90 days and searched the prefixes (3 and 4 chars) of the removed relays in the output and got some hits and although there is a minor concentration about one topic on these onions I'm not sure it actually means these relays tried to become HSDirs for these onions (could be pure coincidence and the concentration around a topic might be caused by a biased onion input list).
interesting, thanks.
tor-relays@lists.torproject.org
-
David Goulet -
Donncha O'Cearbhaill -
Ivan Markin -
nusenu -
teor