torservers.net: some exits became guards? (deanonymization risk)
Dear Torservers, are you aware that you have recently become a relay operator with end-to-end correlation (deanonymization) capabilities? (in fact you are the biggest known such operator) This is especially bad for tor clients because you are also one of the biggest tor exit operators. Some of your relays which used to be exits recently became guard-ony relays. https://nusenu.github.io/OrNetStats/endtoend-correlation-groups#httpswwwtors... Is there anything I can help you with to fix this and reduce the risk for tor clients? thanks, nusenu -- https://mastodon.social/@nusenu https://twitter.com/nusenu_
Hi Nusenu, On Thu, Jun 08, 2017 at 09:58:00AM +0000, nusenu wrote:
Dear Torservers,
are you aware that you have recently become a relay operator with end-to-end correlation (deanonymization) capabilities? (in fact you are the biggest known such operator) This is especially bad for tor clients because you are also one of the biggest tor exit operators.
Some of your relays which used to be exits recently became guard-ony relays. https://nusenu.github.io/OrNetStats/endtoend-correlation-groups#httpswwwtors...
Apologies if this is focusing on a minor point of your message or illuminates nothing but my general tiredness/distractedness, but I don't see how switching a relay from being an exit to being guard-only increases correlation risk from that relay. It shouldn't be possible to use the relay in both positions simultaneously. And even if it could serve as both guard and exit simultaneously, the route-selection algorithm would preclude it being used as both ends for any circuit. And if all torservers.net relays are properly indicated to be from the same family, they will never be selected for both ends of a circuit. Potentially, a client opening multiple circuits through multiple guards (so not using the current standard default of using a single guard) could have some guards and some exits of concurrent circuits run by torservers.net if they satisfy the /16 separation. But that is generally not what is meant by 'end-to-end correlation'. aloha, Paul
Hi Paul, Paul Syverson:
It shouldn't be possible to use the relay in both positions simultaneously. And even if it could serve as both guard and exit simultaneously, the route-selection algorithm would preclude it being used as both ends for any circuit. And if all torservers.net relays are properly indicated to be from the same family, they will never be selected for both ends of a circuit.
I'm well aware of how MyFamily works :) To quote the page I linked (OrNetStats):
Operators are only listed if they actually have a chance to do end-to-end correlation attacks, that is: their guard and exit probability is > 0% they did not properly configure MyFamily they run in more than a single /16 network block
For more context see: https://medium.com/@nusenu/some-tor-relays-you-might-want-to-avoid-5901597ad...
Potentially, a client opening multiple circuits through multiple guards (so not using the current standard default of using a single guard) could have some guards and some exits of concurrent circuits run by torservers.net if they satisfy the /16 separation. But that is generally not what is meant by 'end-to-end correlation'.
By end-to-end correlation I mean "a tor client has a chance to use torservers.net relays in their entry (guard) and exit position in a single circuit. -- https://mastodon.social/@nusenu https://twitter.com/nusenu_
On 08.06.2017 14:00, Paul Syverson wrote:
circuit. And if all torservers.net relays are properly indicated to be from the same family, they will never be selected for both ends of a circuit.
Which is sadly not the case. Our MyFamily statements are badly out of sync. Will fix this next week. We had to temporarily disable some of our exits due to ongoing negotiations with the provider. Thank you nusenu for watching out! -- Moritz Bartl https://www.torservers.net/
On Sat, Jun 10, 2017 at 10:39 AM, Moritz Bartl <moritz@torservers.net> wrote:
We had to temporarily disable some of our exits due to ongoing negotiations with the provider.
Will your provider allow BGP announcements of other IP space? Depending on how many exits we're talking about I (BrassHornCommunications / AS28715) will happily 'loan' you a /24 and a /48-/36 to route from which will remove the abuse complaints from your provider. (FWIW I'd rather not give up a /24 if you're happy using your providers v4 for general Tor routing and AS28715's IPv6 for exiting that'd be ideal). Alternatively I can sponsor your RIPE v6 PI application (subject to the new rules about having a 'contractual relationship yadda yadda) if you'd like to do that.
On 11.06.2017 00:38, Gareth Llewellyn wrote:
Will your provider allow BGP announcements of other IP space?
Yes. In fact, we're discussing abuse issues with our current source of IP space, not the datacenter, where we in theory could get 10GE of free bandwidth.
Depending on how many exits we're talking about I (BrassHornCommunications / AS28715) will happily 'loan' you a /24
This is a great offer, much appreciated! I don't want to lose our current IP space, though, so I will try to reach an agreement with the current provider first. If this does not move within the next few weeks, I definitely will take you up on that offer. We have our own AS and v6 space already (AS60729). -- Moritz Bartl https://www.torservers.net/
Moritz Bartl:
Which is sadly not the case. Our MyFamily statements are badly out of sync. Will fix this next week.
Looking forward to a safer tor network! -- https://mastodon.social/@nusenu https://twitter.com/nusenu_
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 06/08/2017 02:00 PM, Paul Syverson wrote:
It shouldn't be possible to use the relay in both positions simultaneously. As long as "MyFamily" is correctly set, yes IMO.
- -- Toralf PGP C4EACDDE 0076E94E -----BEGIN PGP SIGNATURE----- iI0EAREIADUWIQQaN2+ZSp0CbxPiTc/E6s3eAHbpTgUCWTvEYBccdG9yYWxmLmZv ZXJzdGVyQGdteC5kZQAKCRDE6s3eAHbpTr/kAPwNM8bukdZ6aRAfWgA9/uUbLeTj 75K6b/azt/k11t4dkwD/TrPBrlBNO9l2fY2YA1Bmugoja6IgakC4OiPT+EbyHUQ= =pK3A -----END PGP SIGNATURE-----
participants (5)
-
Gareth Llewellyn -
Moritz Bartl -
nusenu -
Paul Syverson -
Toralf Förster