Re: [tor-relays] [OrNetRadar] AS: "EDIS GmbH" - Linux (15)
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:
2017-02-24 ----------------------------------------------------------------------------------------------------------------------- Up|Ext|JoinTime| IP | CC | ORp | Dirp |Version | ContactInfo | Nickname | eFamlen ----------------------------------------------------------------------------------------------------------------------- 1 | 0 |15:31:23| 124.248.229.138 | hk | 9001 | 9051 |0.2.8.9 | None | coast | 1 1 | 0 |15:33:47| 124.248.229.140 | hk | 9001 | 9051 |0.2.8.9 | None | crop | 1 1 | 0 |15:35:17| 124.248.238.194 | hk | 9001 | 9051 |0.2.8.9 | None | beach | 1 1 | 0 |15:39:10| 124.248.238.197 | hk | 9001 | 9051 |0.2.8.9 | None | queen | 1 1 | 0 |15:51:44| 124.248.229.142 | hk | 9001 | 9051 |0.2.8.9 | None | castle | 1 1 | 0 |17:27:16| 103.44.66.2 | None | 9001 | 9051 |0.2.8.9 | None | tennis | 1 1 | 0 |17:39:25| 103.27.126.28 | hk | 9001 | 9051 |0.2.8.9 | None | court | 1 1 | 0 |17:48:57| 103.44.66.4 | None | 9001 | 9051 |0.2.8.9 | None | waterfall | 1 1 | 0 |17:58:26| 103.44.66.5 | None | 9001 | 9051 |0.2.8.9 | None | camp | 1 1 | 0 |18:06:15| 103.27.126.27 | hk | 9001 | 9051 |0.2.8.9 | None | fighter | 1 1 | 0 |18:25:53| 43.242.174.35 | hk | 9001 | 9051 |0.2.8.9 | None | burn | 1 1 | 0 |18:38:11| 43.242.174.36 | hk | 9001 | 9051 |0.2.8.9 | None | leisure | 1 1 | 0 |18:46:30| 43.242.174.37 | hk | 9001 | 9051 |0.2.8.9 | None | clerk | 1 1 | 0 |18:55:48| 150.107.44.3 | hk | 9001 | 9051 |0.2.8.9 | None | servant | 1 1 | 0 |19:00:45| 150.107.44.2 | hk | 9001 | 9051 |0.2.8.9 | None | mankind | 1 Fingerprints: 25214D40CD1747A06FA2E695E48AED0E988ABA61,25214D43D1FDAF97EBCB68C282D7AA247A1BC487,25214D43CF6621FD4FBEB6FC654A29702965094D,25214D42EC6083C31E1709D86CEBEFFCD4BE1958,7053866617EA5FD3AC0B5D4EB8CE6EC792F99AF5,AB559BE305A7A63962944D32A69AEB2AF9EAC7DC,AB559BE25926F720890BDAE88407E1A676883304,AB559BE2CA986C0EDEFBD78B48621DD36C349AD4,AB559BE02A323465AB8C3D0BB18EA04A1F13E32F,203281E1A349FAA241B6A66456A5AFD1C5B49410,203281E3EBC4E8AB7F040AD8A86B8767A5F6F849,203281E0784DE0DFB5C39C714BBBBA39E76AAA61,203281E37E44A5ABCEA7880DA47895197E92D546,203281E1226E3C1EEBA522409109C847AB14A2B9,203281E27627443DB6FE5E06250DDDB6D9718A0C
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:
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:
2017-02-24 ----------------------------------------------------------------------------------------------------------------------- Up|Ext|JoinTime| IP | CC | ORp | Dirp |Version | ContactInfo | Nickname | eFamlen ----------------------------------------------------------------------------------------------------------------------- 1 | 0 |15:31:23| 124.248.229.138 | hk | 9001 | 9051 |0.2.8.9 | None | coast | 1 1 | 0 |15:33:47| 124.248.229.140 | hk | 9001 | 9051 |0.2.8.9 | None | crop | 1 1 | 0 |15:35:17| 124.248.238.194 | hk | 9001 | 9051 |0.2.8.9 | None | beach | 1 1 | 0 |15:39:10| 124.248.238.197 | hk | 9001 | 9051 |0.2.8.9 | None | queen | 1 1 | 0 |15:51:44| 124.248.229.142 | hk | 9001 | 9051 |0.2.8.9 | None | castle | 1 1 | 0 |17:27:16| 103.44.66.2 | None | 9001 | 9051 |0.2.8.9 | None | tennis | 1 1 | 0 |17:39:25| 103.27.126.28 | hk | 9001 | 9051 |0.2.8.9 | None | court | 1 1 | 0 |17:48:57| 103.44.66.4 | None | 9001 | 9051 |0.2.8.9 | None | waterfall | 1 1 | 0 |17:58:26| 103.44.66.5 | None | 9001 | 9051 |0.2.8.9 | None | camp | 1 1 | 0 |18:06:15| 103.27.126.27 | hk | 9001 | 9051 |0.2.8.9 | None | fighter | 1 1 | 0 |18:25:53| 43.242.174.35 | hk | 9001 | 9051 |0.2.8.9 | None | burn | 1 1 | 0 |18:38:11| 43.242.174.36 | hk | 9001 | 9051 |0.2.8.9 | None | leisure | 1 1 | 0 |18:46:30| 43.242.174.37 | hk | 9001 | 9051 |0.2.8.9 | None | clerk | 1 1 | 0 |18:55:48| 150.107.44.3 | hk | 9001 | 9051 |0.2.8.9 | None | servant | 1 1 | 0 |19:00:45| 150.107.44.2 | hk | 9001 | 9051 |0.2.8.9 | None | mankind | 1 Fingerprints: 25214D40CD1747A06FA2E695E48AED0E988ABA61,25214D43D1FDAF97EBCB68C282D7AA247A1BC487,25214D43CF6621FD4FBEB6FC654A29702965094D,25214D42EC6083C31E1709D86CEBEFFCD4BE1958,7053866617EA5FD3AC0B5D4EB8CE6EC792F99AF5,AB559BE305A7A63962944D32A69AEB2AF9EAC7DC,AB559BE25926F720890BDAE88407E1A676883304,AB559BE2CA986C0EDEFBD78B48621DD36C349AD4,AB559BE02A323465AB8C3D0BB18EA04A1F13E32F,203281E1A349FAA241B6A66456A5AFD1C5B49410,203281E3EBC4E8AB7F040AD8A86B8767A5F6F849,203281E0784DE0DFB5C39C714BBBBA39E76AAA61,203281E37E44A5ABCEA7880DA47895197E92D546,203281E1226E3C1EEBA522409109C847AB14A2B9,203281E27627443DB6FE5E06250DDDB6D9718A0C
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
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
On 27 Feb 2017, at 23:48, nusenu <nusenu@openmailbox.org> wrote:
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)?
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 ------------------------------------------------------------------------
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)?
There's no tool, unless you can reverse SHA1. (Or brute-force a set of popular onion addresses.)
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).
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
nusenu:
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)?
There's no tool, unless you can reverse SHA1. (Or brute-force a set of popular onion addresses.)
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).
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:
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)?
There's no tool, unless you can reverse SHA1. (Or brute-force a set of popular onion addresses.)
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).
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:
On Tue, Feb 28, 2017 at 02:09:00AM +0000, nusenu wrote:
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)?
There's no tool, unless you can reverse SHA1. (Or brute-force a set of popular onion addresses.)
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).
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.
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
nusenu:
Ivan Markin:
On Tue, Feb 28, 2017 at 02:09:00AM +0000, nusenu wrote:
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)?
There's no tool, unless you can reverse SHA1. (Or brute-force a set of popular onion addresses.)
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).
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.
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.. ?
I probably misunderstood how the design works. The introduction points are not chosen by calculating the descriptor-id and finding the 3 HSDirs next to it (by sorted fingerprint).
On Thu, Mar 02, 2017 at 01:11:00PM +0000, nusenu wrote:
nusenu:
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.. ?
I probably misunderstood how the design works.
The introduction points are not chosen by calculating the descriptor-id and finding the 3 HSDirs next to it (by sorted fingerprint).
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
The introduction points are not chosen by calculating the descriptor-id and finding the 3 HSDirs next to it (by sorted fingerprint).
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).
Thanks for confirming! (running an adhoc tor client in at 'info' log level was useful since it outputs descriptor-id and actual hsdir it is contacting)
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...
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.
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
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Donncha O'Cearbhaill:
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...
Nusenu, thank you for reporting these relay. They are now in the process of being removed from the network.
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:
Donncha O'Cearbhaill:
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...
Nusenu, thank you for reporting these relay. They are now in the process of being removed from the network.
Thanks for letting us know.
It would be nice if you could share:
Hello! I'll try to help out as much as I can here.
- if you reached out to the operator (via abuse contacts)
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.
- removal reason
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.
- what was removed
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...
- method (by FP, IP, IP-range, ...)
We always reject both FP and IP. Sometimes, it can be a full network range. Depends on the attack.
- how long they will be blacklisted
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.
- time of removal
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
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
-- F7k4dGBiwJmiegoPb+2QbzdAVSSAfb5AitHDxdxsEV8=
David Goulet:
- removal reason Proximity of fingerprint indicates a clear attempt at insertion in the hashring for an (some) onion address.
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).
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...
interesting, thanks.
participants (5)
-
David Goulet -
Donncha O'Cearbhaill -
Ivan Markin -
nusenu -
teor