- tor-relays - lists.torproject.org

Re: [tor-relays] How to Limit Bridge Traffic
by entensaison＠use.startmail.com 06 Mar '20

06 Mar '20

Hi, On Thursday, March 5, 2020 at 8:24 PM, Imre Jonk <imre(a)imrejonk.nl> wrote: > Hi Eddie, > > On Wed, 2020-03-04 at 12:34 -0800, Eddie wrote: >> Does BandwidthRate apply to bridges. I can (hopefully) guess that >> RelayBandwidth doesn't. >> Does the AccountingMax apply. > I am almost certain that all three options apply to bridges as well. > Note that BandwidthRate applies to all TCP data (not the TCP headers > or > DNS traffic), while RelayBandwidth* applies to the _relayed traffic_ > only. > >> I noticed the following in the manual: >> >> If you have bandwidth cost issues, enabling hibernation is >> preferable >> to setting a low bandwidth, since it provides users with a >> collection >> of fast servers that are up some of the time, which is more useful >> than a set of slow servers that are always "available". >> >> Does that advice apply equally to bridges, assuming that the >> Accounting options do apply. Or would it more advantageous for a >> bridge to be constantly available, as switching bridges isn't as >> seamless as switching relays. > That's an interesting question. Bridges are required to provide at > least 1 Mbit/s bandwidth, but I can't find anything related to uptime > requirements (except for the two hours a day minimum). I'd say that > the > advice therefore also applies to bridges. The Tor client software can > be configured to use multiple bridges. I would say the recommendation to use AccountingMax does not apply for bridges. It's just a subjective impression but there are often people complaining that most bridges they get handed out don't work or stop working after a short time. Some of these people end up believing that they are unable to use Tor at all from their location, because their adversary successfully detected the bridge. (Which might be true in some cases.) In order to avoid confusion for people who depend on using bridges it seems to make more sense to limit the bandwith instead.

1 0

How to Limit Bridge Traffic
by Eddie 05 Mar '20

05 Mar '20

Hi, I'm quite happy to continue to run a couple of bridges on my VPC, but I need to understand how to manage the bandwidth so I'm not being charged for exceeding it's monthly allocation. Does BandwidthRate apply to bridges. I can (hopefully) guess that RelayBandwidth doesn't. Does the AccountingMax apply. I noticed the following in the manual: If you have bandwidth cost issues, enabling hibernation is preferable to setting a low bandwidth, since it provides users with a collection of fast servers that are up some of the time, which is more useful than a set of slow servers that are always "available". Does that advice apply equally to bridges, assuming that the Accounting options do apply. Or would it more advantageous for a bridge to be constantly available, as switching bridges isn't as seamless as switching relays. Cheers.

2 1

playing around with relay flags?
by Basajauntxo 05 Mar '20

05 Mar '20

My relay, 83A802311F37647C243CF06970BA111E0E543CCE has been changing flags from "fast, running. stable", to "none" without and apparent reasong to trigger such changes. It can take up to 2 Mb/s connections and traffic up tp 6GB daily. The thing runs on a metered connection. If for some reason these specs have become too low please specify. Sent with [ProtonMail](https://protonmail.com) Secure Email.

2 2

Should new exit relays be probed for public DNS resolvers
by Nathaniel Suchy 05 Mar '20

05 Mar '20

There has been discussion over the past several years that the Tor network should not use public DNS resolver as it has security implications on the Tor network (https://medium.com/@nusenu/who-controls-tors-dns-traffic-a74a7632e8ca) Should new Tor Exit Relays be probed and not included in the consensus until they're running their own DNS resolver and not relying on a public one?

4 6

Dirport9030
by Nuno Rego 04 Mar '20

04 Mar '20

I have a problem. I am learning, and I have 4 active relays. I used the same configuration on the 4. Recently 2 of them lost the Guard, HSdir and V2Dir flags. On the page https://metrics.torproject.org/rs.html#search/TugaOnion I see that DirPort is 0 instead of 9030. I haven't changed anything, and in the relay configuration there is 9030. Any suggestions on how to solve the problem ? Cumprimentos; -- Securely sent with Tutanota. Get your own encrypted, ad-free mailbox: https://tutanota.com

1 0

Stable flag not appearing on my bridge.
by Keifer Bly 01 Mar '20

01 Mar '20

Hi all, So my bridge at https://metrics.torproject.org/rs.html#details/386E99371B8CD938248940B754F1… Is not getting the stable flag despite being running for several weeks with only minor interruption in between. Is the stable flag no longer used for bridges? Thank you. -- --Keifer

2 1

So here is my working script of automatically starting windows tor relays bridges when windows starts, and trying to write script to auto update.
by Keifer Bly 28 Feb '20

28 Feb '20

Hi all, So here is my script for automatically starting a Windows (Expert bundle based) relay or bridge when windows starts. Open a new notepad document. Then add the following to it: Cd c:/pathwheretorexpertbundleisindtalled tor.exe -f torrc.txt (assuming your torrc is a text file). Then save this file as batch file in the “startup” folder which should be at C:\ProgramData\Microsoft\*Windows*\Start Menu\Programs\*Startup* *What this does is it creates a script for windows to automatically run at startup that tells the os to point to the directory tor expert bundle is installed in and launch tor.exe and read the configuration file. This is tested and working for me. But I am still trying to write a script to automatically download and install the newest tor version when released as well as obfs4, proving difficult as the url changes with each version. Any thoughts are appreciated, thx very much.* -- --Keifer

1 0

Why MyFamily?
by [REDACTED] 27 Feb '20

27 Feb '20

Last week i got an email with a warning that some of my relays are missing the correct MyFamily setup and that i am a risk to do end-to-end correlation attacks together with a list of all relays i operate plus one relay which uses the same name than i use but is not operated by me. I already knew that not all of my relays have a correct MyFamily setup because as long as i am not sure if they will stay i usually dont include them in MyFamily because it is a pain to edit every torrc if they anyway will disappear again soon. I did it that way with all relays before and when i am sure that the hoster is okay with me and that i am okay with the hoster i always included them in MyFamily. In the received email nothing was written that someone might expect an answer from me so i deleted that email and to not trigger that warning again i deleted the contact info from these specific relays for now. A few days later i got a message that some of my relays will soon get rejected because i did not responded to the previous email. I explained why i do not have a correct MyFamily setup and i explained that one of these relays is not operated by me even if it has the same name than one of my relays. The answer of the bad-relays mailing list was that its important for them to know that one of the relays tried to look like me and that i can use a third-party tool for setting up the MyFamily and that further discussion about the MyFamily is more suitable for the relays mailinglist. What i learned from that: - The bad-relays team expect an answer to their emails even if they do not tell you that in the first email and rather send you a second email that they will soon reject your relays if you dont answer them. - I could do an end-to-end correlation attack (I knew that already and would not use the same name and contact info on my relays if i would like to do that) - It is possible for them to pin relays to specific operators without relying on the contact info or MyFamily entrys (I assume they guess that by looking at the relays names because otherwise they hadn't put a relay which is not operated by me into my warning message) - If setting up the MyFamily option is too painful for you then you can use a third party tool which is not part of the torproject - Relays names are free to choose and double entrys are okay but if someone operates an relay with a name you choosed before then you can report that operator to the bad-relays list because that operator might be malicious (Thankfully my relays are not called "Unnamed") So for what reason do i set the MyFamily option beside making a Hidden Service Guard discovery attack more easy?

6 7

DNSEL (exit relays list) service changes
by Iain Learmonth 27 Feb '20

27 Feb '20

Hi, In order to simplify the operation of the Tor DNS exit list service, which is used to identify if a connection is from a Tor exit relay, I am planning to remove the features that filter by exit policy. We recommend that if you are running an exit relay then you should dedicate an IP address to that and not be using it for other activities. As such, I do not think this is going to affect exit relay operators as exit relays are unlikely to be talking to services that their exit policy does not allow talking to anyway. Still I am asking here to make sure that this change isn't going to have any serious negative effects. Has any operator deliberately excluded anything from their exit policy in order to have TorDNSEL report to service operators that the connection is not from an exit relay? Thanks, Iain.

1 0

Re: [tor-relays] Why MyFamily?
by [REDACTED] 23 Feb '20

23 Feb '20

Hi nusenu Am Fr., 21. Feb. 2020 um 22:24 Uhr schrieb nusenu <nusenu-lists(a)riseup.net>: > Hi [REDACTED], > > > Last week i got an email with a warning that some of my relays are > > missing the correct MyFamily setup and that i am a risk to do > > end-to-end correlation attacks together with a list of all relays i > > operate plus one relay which uses the same name than i use but is not > > operated by me. > > the email [REDACTED] is referring to for the interested readers: [1] > > > I already knew that not all of my relays have a correct MyFamily setup > > because as long as i am not sure if they will stay i usually dont > > include them in MyFamily because it is a pain to edit every torrc > > Yes, manually managing MyFamily is a pain with that many relays. > It is best to automate it so you don't have to worry about it > no matter how long your relays might run. > > It is also relevant to note that we are not talking about fresh relays > (born days or weeks ago) but >6 months. > I think the relay you are talking about is the relay in Yekaterinburg. This relay is not listed as with no MyFamily in the first email but after receiving the first email i decided that i am okay with the newer hoster more than the older hoster so i included the newer one in MyFamily and excluded the older one and will probably let it expire so the relays mentioned with no MyFamily setup in the first and the ones in the second email should be slightly different. But thats not important anyway. I usually wait at least one billing period. Some of my relays are paid for three years in advance which means there might be cases where a relay will be in a state of unknown for three years till i know if they will stay. > > A few days later i got a message that some of my relays will soon get > > rejected because i did not responded to the previous email. > > A more correct version is: some relays were proposed for removal on the > bad-relays@ list > should there not be any reaction by the operator [2]. > > That is something different than informing an operator about an upcoming > removal since > everybody can propose removals and only dir auths can actually vote for > the removal. > Understood. > [2] > For the readers on this list, this is the second mentioned email: > > I'm proposing the removal of the first 5 entries in the following table > (end-to-end correlation risk) > > should there not be any reaction to this email from the operator. > > > > A previous email from 2020-02-15 did not result in a reply so far. > > > > > +---------------------+--------+----------------------+------------------+-------------------+-----------------+---------------------------------------------------+------------------------------------------+ > > | first_seen | member | contact | nickname > | tor_version | IP | as_name > | fingerprint | > > > +---------------------+--------+----------------------+------------------+-------------------+-----------------+---------------------------------------------------+------------------------------------------+ > > | 2020-02-01 18:00:00 | 1 | NULL | angeltest33 > | 0.4.2.6 | 139.99.238.17 | OVH SAS > | 4BF3D299BC500C350868F078749291C766C7AA6F | > > | 2020-01-11 16:00:00 | 1 | NULL | angeltest5test > | 0.4.2.6 | 51.38.147.96 | OVH SAS > | 951307BA74E44A9C9C208B2F134CDA2409944075 | > > | 2019-08-06 11:00:00 | 1 | NULL | angeltest27 > | 0.4.2.6 | 185.173.177.153 | GalaxyStar LLC > | 95C8B9418E74F3FF80E5C3D3AF7F03156FFBBFBE | > > | 2019-08-31 09:00:00 | 1 | NULL | angeltest9 > | 0.2.9.14 | 104.244.76.190 | FranTech Solutions > | F1D5C0F5157D9B24014BE8C7A1D878AEA6843B42 | > > | 2019-11-21 12:00:00 | 1 | NULL | angeltest26test > | 0.4.2.6 | 91.243.50.239 | Petersburg Internet Network ltd. > | F51A927E34662D6005393F2327C870FB0D0D7FE0 | > > > > > - The bad-relays team expect an answer to their emails even if they do > > not tell you that in the first email and rather send you a second > > email that they will soon reject your relays if you dont answer them. > > I think you are confusing the "bad-relays team" with subscribers or people > sending emails to the bad-relays@ list. > If in doubt require the sender to have a @torproject.org address > (unfortunately there is no actual sender address for the bad-relays team > since it is just a mailing list) > The senders name was "tor-bad-relays(a)riseup.net" which looked official to me. Then Georg Koppen "validated" the second email. For the next time i know that i only need to respond to valid emails. > > So for what reason do i set the MyFamily option beside making a Hidden > > Service Guard discovery attack more easy? > > > - risk reduction for tor users > MyFamily declarations allow the tor client software to automatically > detect relay families when creating circuits to > avoid using multiple relays from the same operator in a single circuit. > This should not matter if the operator is not malicious and like i already said an malicious operator will not use the same contact info or relay name. - reducing the risk for tor users that might become victims if some > operator gets compromized (with all its relays) > This is a reason i can understand. Not sure how much that would really help in practice but i can understand it. - transparency > Every relay operator should declare their relay group to allow everybody > to measure their network fraction (Sybil detection). > Should... But i understand this one too. But as long as my family is still a small one with only one exit compared to others i am not a Sybil attack risk and even if i would would i get any special treatment then? - risk reduction for relay operators > MyFamily also provides risk reduction for operators since they are less > valuable as an attack target > if they can not technically be used for e2e correlation attacks > I think this is similar to your first point but i think that should be the operators choice if he want to take steps against this case. - allow the identification of "false-friends" and actual malicious relays > By setting MyFamily you make it easier to detect relays that claim to be > you > since MyFamily requires mutual configuration malicious entities can not > add their relays to your MyFamily. > > This is what happened in your case (which was a mixture of > misconfiguration and actual "false-friends"). Talking about that particular possibly malicious FranTech relay the operator and me set their MyFamily correctly. I did not included it in my family because i am not the operator and he did not tried to include it in my family so relying on MyFamily was useless anyway. I knew about that relay for some while already because i first thought i had accidentially made one of my relays an exit but decided to not report it because relay names are free to choose. Thats the reason why i was so mad about the fact that someone assume this particular malicious relay is operated by me because what the other possibly malicious operator tried to achieve (to look like me) was exactly what happened. I think MyFamily greatly fails in trying to solve a problem and is making life for honest operators more difficult but not for mailicious operators. > > If you are really interested into the MyFamily topic you can find a few > tickets on trac.torproject.org about it > (including arguments against it). > I will look into it. > > > > [1]: > > Hello, > > > > This email wants to make you aware that you are probably putting tor > users > > at risk by not properly setting MyFamily on your tor relays. > > > > If the relays using your contactInfo are not actually yours > > please send an email to bad-relays(a)lists.torproject.org > > so they can be removed from the network for impersonating your > contactInfo. > > > > > https://nusenu.github.io/OrNetStats/endtoend-correlation-groups#torrpi1405g… > > > > Thanks for taking care of this. > > > > > +---------------------+------+------------------+--------+----------------------+-------------------+-----------------+------------------------------------------+ > > | first_seen | exit | nickname | member | contact > | tor_version | IP | fingerprint > | > > > +---------------------+------+------------------+--------+----------------------+-------------------+-----------------+------------------------------------------+ > > | 2018-08-28 21:00:00 | 0 | angeltest2 | 27 | > [REDACTED] | 0.4.4.0-alpha-dev | 5.39.60.243 | > 3B07C500AC17E7B5A1EE616613E104A094AB87F3 | > > | 2018-09-05 17:00:00 | 0 | angeltest7 | 27 | > [REDACTED] | 0.4.2.6 | 37.252.187.111 | > EE4AF632058F0734C1426B1AD689F47445CA2056 | > > | 2018-09-05 20:00:00 | 0 | angeltest8 | 27 | > [REDACTED] | 0.4.2.6 | 185.112.82.50 | > 7AAF5597B18D82CC90CA95FB7976A1CEA4A32E06 | > > | 2018-09-07 23:00:00 | 0 | angeltest9 | 27 | > [REDACTED] | 0.4.2.6 | 92.38.163.21 | > 9288B75B5FF8861EFF32A6BE8825CC38A4F9F8C2 | > > | 2018-09-27 00:00:00 | 0 | angeltest11 | 27 | > [REDACTED] | 0.4.2.6 | 213.183.60.21 | > 39F91959416763AFD34DBEEC05474411B964B2DC | > > | 2018-09-27 19:00:00 | 0 | angeltest12 | 27 | > [REDACTED] | 0.4.2.6 | 91.201.65.91 | > 57C6DF5B93E54EB9C8DB90029D9E9A1111BD34D2 | > > | 2018-12-15 00:00:00 | 0 | angeltest14 | 27 | > [REDACTED] | 0.4.2.6 | 195.123.245.141 | > 465D17C6FC297E3857B5C6F152006A1E212944EA | > > | 2019-01-10 00:00:00 | 0 | angeltest18 | 27 | > [REDACTED] | 0.4.2.6 | 94.140.125.122 | > B517198B86B3859C307857C59F6660A281FC8B47 | > > | 2019-01-10 22:00:00 | 0 | angeltest19 | 27 | > [REDACTED] | 0.4.2.6 | 185.246.152.22 | > A86EC24F5B8B964F67AC7C27CE92842025983274 | > > | 2019-02-26 10:00:00 | 0 | angeltest20 | 27 | > [REDACTED] | 0.4.2.6 | 178.17.170.103 | > ADE6AB2BFBD7A5780B321DC33BBACCD0D777C94D | > > | 2019-04-26 12:00:00 | 0 | angeltest23 | 27 | > [REDACTED] | 0.4.2.6 | 81.169.235.154 | > EFA2E7B073AA4CE2DAF7160F23C90DB805948F4A | > > | 2019-05-29 07:00:00 | 0 | angeltest26 | 27 | > [REDACTED] | 0.4.2.6 | 89.223.100.121 | > 40108FDFA40EDB013F7291F3B4DA3D412ED3A5EF | > > | 2019-08-06 11:00:00 | 0 | angeltest27 | 27 | > [REDACTED] | 0.4.2.6 | 185.173.177.153 | > 95C8B9418E74F3FF80E5C3D3AF7F03156FFBBFBE | > > | 2019-08-13 12:00:00 | 0 | angeltest6 | 27 | > [REDACTED] | 0.4.2.6 | 185.61.149.67 | > 295F1BD8995A12ECC77E050CCF6EC641572739E9 | > > | 2019-08-19 04:00:00 | 0 | angeltest28 | 27 | > [REDACTED] | 0.4.2.6 | 31.207.89.49 | > 1A7A2516A961F2838F7F94786A8811BE82F9CFFE | > > | 2019-09-19 14:00:00 | 0 | angeltest3 | 27 | > [REDACTED] | 0.4.2.6 | 62.141.38.69 | > FF9FC6D130FA26AE3AE8B23688691DC419F0F22E | > > | 2019-10-02 19:00:00 | 0 | angeltest10 | 27 | > [REDACTED] | 0.4.2.6 | 178.254.20.159 | > C1939D36649DE98A202429631D8EFC70128D5F5F | > > | 2019-11-01 05:00:00 | 0 | angeltest5 | 27 | > [REDACTED] | 0.4.2.6 | 51.38.134.104 | > 39C6F833D4B09524770D3655DF825A11213CA0A9 | > > | 2019-11-01 08:00:00 | 0 | angeltest27test | 1 | > [REDACTED] | 0.4.2.6 | 92.223.109.71 | > 1323D34C2FA4AE0EC4EEA9853F3464693EF428E7 | > > | 2019-11-02 14:00:00 | 0 | angeltest17 | 27 | > [REDACTED] | 0.4.2.6 | 5.34.183.29 | > F8AA8D8CCBA0C5F2836DE6315CDFA6E4A31A0890 | > > | 2019-11-05 14:00:00 | 0 | angeltest13 | 27 | > [REDACTED] | 0.4.2.6 | 185.225.17.173 | > A4CC39184AD287D72C2247738835811C7A7ECB8E | > > | 2019-11-21 12:00:00 | 0 | angeltest26test | 1 | > [REDACTED] | 0.4.2.6 | 91.243.50.239 | > F51A927E34662D6005393F2327C870FB0D0D7FE0 | > > | 2019-12-11 22:00:00 | 0 | angeltest29 | 27 | > [REDACTED] | 0.4.2.6 | 87.106.152.102 | > 73283C4DEBC01D3E4A5FD1BB1F2B50D927379F59 | > > | 2019-12-20 04:00:00 | 0 | angeltest24 | 27 | > [REDACTED] | 0.4.2.6 | 2.56.241.243 | > 401A66747713038CEEF6ED28C8AFEB70570EEBCC | > > | 2019-12-20 06:00:00 | 0 | angeltest25 | 27 | > [REDACTED] | 0.4.2.6 | 185.118.164.41 | > C9BC841E180B35F229FD47664F84CF8A8ADB3F68 | > > | 2019-12-24 16:00:00 | 0 | angeltest30 | 27 | > [REDACTED] | 0.4.2.6 | 185.4.135.157 | > B93503D458D9FE97DE5C12D211082871D08F1284 | > > | 2020-01-11 16:00:00 | 0 | angeltest5test | 1 | > [REDACTED] | 0.4.2.6 | 51.38.147.96 | > 951307BA74E44A9C9C208B2F134CDA2409944075 | > > | 2020-01-12 17:00:00 | 0 | angeltest31 | 27 | > [REDACTED] | 0.4.2.6 | 185.101.35.219 | > 2F8B9500DC98C13FD28CC51E47D3416DE423ED78 | > > | 2020-01-14 15:00:00 | 0 | angeltest32 | 27 | > [REDACTED] | 0.4.2.6 | 185.99.2.178 | > 12B1A5769D38FF47CF68C2235E1BDA315DF400F2 | > > | 2020-01-23 04:00:00 | 0 | angeltest16 | 27 | > [REDACTED] | 0.4.4.0-alpha-dev | 195.123.238.164 | > D5812BAB52820A4D448E5F16EE363A0F4CEEF691 | > > | 2020-02-01 18:00:00 | 0 | angeltest33 | 1 | > [REDACTED] | 0.4.2.6 | 139.99.238.17 | > 4BF3D299BC500C350868F078749291C766C7AA6F | > > | 2020-02-11 14:00:00 | 1 | angeltestwindows | 1 | > [REDACTED] | 0.4.2.5 | 91.132.147.168 | > DC81AA3B1D51566DBF27BFA562E4047AEB1C52DA | > > > +---------------------+------+------------------+--------+----------------------+-------------------+-----------------+------------------------------------------+ > > > > > > _______________________________________________ > tor-relays mailing list > tor-relays(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >

5 10