Re: [tor-relays] Become a Fallback Directory Mirror (deadline: July 23)
CE47F0356D86CF0A1A2008D97623216D560FB0A8 52BFADA8BEAA01BA46C8F767F83C18E2FE50C1B9 8CAA470B905758742203E3EB45941719FCA9FEEC 1AE039EE0B11DB79E4B4B29CBA9F752864A0259E 03C3069E814E296EB18776EB61B1ECB754ED89FE 7600680249A22080ECC6173FBBF64D6FCF330A61 F9246DEF2B653807236DA134F2AEAB103D58ABFE 0C475BA4D3AA3C289B716F95954CAD616E50C4E5 AE6A8C18E7499B586CD36246AC4BCAFFBBF93AB2 8FA37B93397015B2BC5A525C908485260BE9F422 2CE96A8A1DA032664C90F574AFFBECE18A6E8DFC 9F5068310818ED7C70B0BC4087AB55CB12CB4377 Am 08.07.2020 um 19:36 schrieb gus: Dear Relay Operators, Do you want your relay to be a Tor fallback directory mirror? Will it have the same address and port for the next 2 years? Just reply to this email with your relay's fingerprint. Important: you have until July 23 2020 to reply to this message to get in the fallback directory mirror list. If your relay is on the current fallback list, you don't need to do anything. If you're asking: Q: What's a fallback directory mirror? Fallback directory mirrors help Tor clients connect to the network. For more details, see [1]. Q: Is my relay on the current list? Search [2] and [3] for your relay fingerprint or IP address and port. [2] is the current list of fallbacks in Tor. [3] is used to create the next list of fallbacks. Q: What do I need to do if my relay is on the list? Keep the same IP address, keys, and ports. Email tor-relays if the relay's details change. Q: Can my relay be on the list next time? We need fast relays that will be on the same IP address and port for 2 years. Reply to this email to get on the list, or to update the details of your relay. Once or twice a year, we run a script to choose about 150-200 relays from the potential list [3] for the list in Tor [2]. Q: Why didn't my relay get on the list last time? We check a relay's uptime, flags, and speed [4]. Sometimes, a relay might be down when we check. That's ok, we will check it again next time. It's good to have some new relays on the list every release. That helps tor clients, because blocking a changing list is harder. cheers, Gus [1] https://gitlab.torproject.org/tpo/core/tor/-/wikis/NetworkTeam/FallbackDirectoryMirrors [2] https://gitweb.torproject.org/tor.git/tree/src/app/config/fallback_dirs.inc [3] https://gitweb.torproject.org/fallback-scripts.git/tree/fallback_offer_list [4] https://trac.torproject.org/projects/tor/attachment/ticket/21564/fallbacks_2017-05-16-0815-09cd78886.log ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays -- Cheers, Felix ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] tor relay - vps maintenance - what to do ?
On 7/12/20 11:12 PM, dluga...@protonmail.com wrote: > What should I do ? Consider to use offline keys - it is a good idea always. -- Toralf signature.asc Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] >23% Tor exit relay capacity found to be malicious - call for support for proposal to limit large scale attacks
On 7/12/20 2:40 PM, Charly Ghislain wrote: > There seems to be a consensus toward building a web of trust. > Thinking about it again, I don't like much the direction it is going. > +1 A Web of Trust does not mean that all have to trust a central instance. Similar to PGP where nobody relies on the key servers but on his own keyring. -- Toralf signature.asc Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] tor relay - vps maintenance - what to do ?
On Sun, 12 Jul 2020 21:12:31 +
dluga...@protonmail.com wrote:
> in the next three days, my VPS provider planning to shutdown
> ("maintenanance") for 6 hours my VPS where tor relay is running (with some
> services).
>
> I suspect that my VPS will be copied and reviewed (by not authorized persons)
> afterwards.
The provider can copy and examine disks of a running VPS even without shutting
it down. They might get a few filesystem errors, but most likely nothing major
and 99% of data will be there.
The only way to protect from that, is to set up Full-disk encryption (FDE) on
the VPS beforehand. But even then, it is challenging to make sure the
decryption key is not leaked to the provider (e.g. when entering it via their
"VNC Console", which can be keylogged).
If you do not set up FDE, you should assume all your data on any VPS is
accessible to the provider. Even RAM of a VPS can be copied without stopping
it, so running Tor in a RAM disk (tmpfs) is not an answer either.
For more privacy get a dedicated server rather than a VPS. At least a server
actually must be shut down to mess with its disks, and RAM is basically out of
reach. (I believe wiretapping SATA, let alone DDR, can be ruled out as
purely theoretical, in most cases :)
Make sure that backdoors such as Intel AMT are not active though, or get a
non-Intel server.
> What should I do ?
Do not get overly paranoid, most likely it's just a maintenance and has
nothing to do with your VPS or with Tor running on it. As said above, if they
wanted your VPS' contents, they can freely get it at any time without
attracting attention.
If it was a dedicated server, then yes, a cause for concern, as it's a plenty
of time to detach your disk and copy it. For a VPS, none of that downtime is
even needed for that in the first place.
--
With respect,
Roman
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] tor relay - vps maintenance - what to do ?
On Sun, Jul 12, 2020 at 09:12:31PM +, dluga...@protonmail.com wrote:
> in the next three days, my VPS provider planning to shutdown
> ("maintenanance") for 6 hours my VPS where tor relay is running (with some
> services). What should I do ?
>
> I suspect that my VPS will be copied and reviewed (by not authorized persons)
> afterwards. How do You react in such a situations ?
>
> I appreciate any advice.
The conservative choice would be to remove all the key material (that is,
delete the files in your DataDirectory/keys/ directory) before it shuts
down, and then start a fresh relay (with fresh keys) when it comes back.
It really comes down to how much you think they will mess with it (or
maybe even, why you think they've picked your VPS for maintenance at all).
Leaving it alone and not stressing about it, or rotating to fresh keys,
are both valid approaches. It depends how you want to approach it.
Hope that helps,
--Roger
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
