Re: [tor-relays] How to reduce tor CPU load on a single bridge?

[Roger Dingledine]

[I'm about to go off-line for some days, so I am sending my current
suboptimally-organized reply, which I hope is better than waiting another
week to respond :)]

On Thu, Dec 30, 2021 at 10:42:51PM -0700, David Fifield wrote:
> Let's make a distinction between the "frontend" snowflake-server
> pluggable transport process, and the "backend" tor process. These don't
> necessarily have to be 1:1; either one could be run in multiple
> instances. Currently, the "backend" tor is the limiting factor, because
> it uses only 1 CPU core. The "frontend" snowflake-server can scale to
> multiple cores in a single process and is comparatively unrestrained.

Excellent point, and yes this simplifies. Great.

> I believe that the "pinning" of a client session to particular tor
> instance will work automatically by the fact that snowflake-server keeps
> an outgoing connection alive (i.e., through the load balancer) as long
> as a KCP session exists.
>[...]
> But before starting the second instance the first time, copy keys from
> the first instance:

Hm. It looks promising! But we might still have a Tor-side problem
remaining. I think it boils down to how long the KCP sessions last.

The details on how exactly these bridge instances will diverge over time:

The keys directory will start out the same, but after four weeks
(DEFAULT_ONION_KEY_LIFETIME_DAYS, used to be one week but in Tor
0.3.1.1-alpha, proposal 274, we bumped it up to four weeks) each
bridge will rotate its onion key (the one clients use for circuit-level
crypto). That is, each instance will generate its own fresh onion key.

The two bridge instances actually haven't diverged completely at that
point, since Tor remembers the previous onion key (i.e. the onion key
from the previous period) and is willing to receive create cells that
use it for one further week (DEFAULT_ONION_KEY_GRACE_PERIOD_DAYS). So it
is after 5 weeks that the original (shared) onion key will no longer work.

Where this matters is (after this 5 weeks have passed) if the client
connects to the bridge, fetches and caches the bridge descriptor of
instance A, and then later it connects to the bridge again and gets
passed to instance B. In this case, the create cell that the client
generates will use the onion key for instance A, and instance B won't
know how to decrypt it so it will send a destroy cell back.

If this is an issue, we can definitely work around it, by e.g. disabling
the onion key rotation on the bridges, or setting up a periodic rsync+hup
between the bridges, or teaching clients to use createfast cells in this
situation (this type of circuit crypto doesn't use the onion key at all,
and just relies on TLS for security -- which can only be done for the
first hop of the circuit but that's the one we're talking about here).

But before we think about workarounds, maybe we don't need one: how long
does "the KCP session" last?

Tor clients try to fetch a fresh bridge descriptor every three-ish
hours, and once they fetch a bridge descriptor from their "current"
bridge instance, they should know the onion key that it wants to use. So
it is that up-to-three-hour window where I think things could go wrong.
And that timeframe sounds promising.

(I also want to double-check that clients don't try to use the onion
key from the current cached descriptor while fetching the updated
descriptor. That could become an ugly bug in the wrong circumstances,
and would be something we want to fix if it's happening.)

Here's how you can simulate a pair of bridge instances that have diverged
after five weeks, so you can test how things would work with them:

Copy the keys directory as before, but "rm secret_onion_key*" in the
keys directory on n-1 of the instances, before starting them.)

Thanks!
--Roger

___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Maybe the next step in russian Tor discrimination

[Josh Lawson via tor-relays]

   I have been wondering the last few days about the use of bridges in Russia. Are you more likely to help out the Russian population by running the bridge from a Russian data center? I’m considering if I want to pay for a VPS as well, but not sure how effective this may be with the so-called Russian black box.   On Mon, Jan 3, 2022 at 04:39,   wrote:  Hi,I've made the same experience with my node in RU.Greetings,Sebastian ElisaOn 02.01.2022 16:09, abuse--- via tor-relays wrote:> Very interesting!>> I have two VPS at different locations with justhost.ru (IQ Data St.> Petersburg and DataLine Moscow - AS51659) and have also noticed a> change:>> - on December 30th, both servers could not reach deb.torproject.org> and the torproject.org web page. Both IPv4 and IPv6 were blocked.>> - I tried again today and everything worked fine. I even downloaded> the tor browser bundle for Windows over one of the servers just to see> if it works. It does and the signature also checks out (verified on a> different server outside Russia)>> - running tor nodes at both locations continues to work>> Best Regards,>> Kristian>> Jan 2, 2022, 08:22 by torrelaysaregr...@gmail.com:>>> Hello, i have a relay at profitserver.ru [1] at their Chelyabinsk location>> and recently the relay fell out of the consensus. I can ping all authorities with IPv4 and IPv6 and torproject.org [2]>> is not blocked. I opened the ControlPort and tried to manually create circuits to>> the authorities. extendcircuit 0 authoritynickname getinfo circuit-status I observed that i can successfully create circuits to no more than>> three authorities and it seems to change to which authorities i can>> create circuits. The unsuccessful circuits stay in EXTENDED but never reach BUILT>> until Tor gives up eventually. Currently no other of my russian relays are affected. I am not an expert with the ControlPort but i hope this is proving>> what i tried to prove. Here is the conversation with the support: me: Hello, I am running a (non-exit) Tor relay on the VPS and it stopped>> working a few weeks ago. I can ping the Tor authorities IP addresses but when i try to>> manually create a Tor circuit it seems to timeout 6 out of 9 times>> which indicates some blocking attempts on your (or your upstream>> providers) side. I have a couple of other Tor relays in russia and i have never seen>> routinely failing manually created circuits to the Tor authorities. Do you block Tor or do you otherwise mess with Tor traffic? support agent:>> Hello, i can't say something about TOR network, now.>> We have black box from government, which can control traffic, and>> perhaps block TOR.>> Ourselves don't block TOR me:>> Thanks for your answer.>> The TSPU from Roskomnadzor that is doing Deep Packet Inspection?>> I feel with you and all the russian citizens... :(>> Good luck support agent: Maybe it's a black box If this is indeed their blackbox messing with Tor traffic then it is>> quite subtile because it does not block torproject.org [2] and pings>> to the authorities are going through.>> The relay suddenly was online for one consensus in the last weeks>> and i can still use it when i manually set it as a Guard in my Tor>> client. So if you run a relay in russia and you experience weird stuff with>> it then you may not only want to check if you can reach the>> authorities by ping but you may want to try to manually craft a>> circuit to all of them. Hope that helps anyone Cheers Links:> --> [1] http://profitserver.ru> [2] http://torproject.org> ___> tor-relays mailing list> tor-relays@lists.torproject.org> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays___tor-relays mailing listtor-relays@lists.torproject.orghttps://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays




publicKey - joshuawlawson@protonmail.ch - 4d977914.asc
Description: application/pgp-keys


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] cases where relay overload can be a false positive

[s7r]

Replying to myself:

s7r wrote:
[SNIP]


Metrics port says:

tor_relay_load_tcp_exhaustion_total 0

tor_relay_load_onionskins_total{type="tap",action="processed"} 52073
tor_relay_load_onionskins_total{type="tap",action="dropped"} 0
tor_relay_load_onionskins_total{type="fast",action="processed"} 0
tor_relay_load_onionskins_total{type="fast",action="dropped"} 0
tor_relay_load_onionskins_total{type="ntor",action="processed"} 8069522
tor_relay_load_onionskins_total{type="ntor",action="dropped"} 273275

So if we account the dropped ntor circuits with the processed ntor 
circuits we end up with a reasonable % (it's  >8 million vs <300k).


So the question here is: does the computed consensus weight of a relay 
change if that relay keeps sending reports to directory authorities that 
it is being overloaded? If yes, could this be triggered by an attacker, 
in order to arbitrary decrease a relay's consensus weight even when it's 
not really overloaded (to maybe increase the consensus weights of other 
malicious relays that we don't know about)?


Also, as a side note, I think that if the dropped/processed ratio is not 
over 15% or 20% a relay should not consider itself overloaded. Would 
this be a good idea?


Sending to tor-relays@ for now, if some of you think of this in any way 
we can open a thread about it on tor-dev@ - please let me know if I 
should do this.




I am now positive that this particular relay is actively being probed, 
overloaded for just few minutes every 2-3-4 days, rest of the time 
performing just fine with under 70% usage for CPU and under 50% for RAM, 
SSD and bandwidth.


I also confirm that after this time's overload report, my consensus 
weight and advertised bandwidth decreased. So my concerns about this 
being triggered arbitrary has a network-wide effect in terms of path 
selection probability and might suite someone a purpose of any sort.


I don't know what is the gain here and who is triggering this, as well 
as if other Guard relays are experiencing the same (maybe we can analyze 
onionoo datasets and find out) but until then I am switching to 
OverloadStatistics 0.



Here are today's Metrics Port results:

tor_relay_load_tcp_exhaustion_total 0

tor_relay_load_onionskins_total{type="tap",action="processed"} 62857
tor_relay_load_onionskins_total{type="tap",action="dropped"} 0
tor_relay_load_onionskins_total{type="fast",action="processed"} 0
tor_relay_load_onionskins_total{type="fast",action="dropped"} 0
tor_relay_load_onionskins_total{type="ntor",action="processed"} 10923543
tor_relay_load_onionskins_total{type="ntor",action="dropped"} 819524

As you can see, like in the first message of this thread, the calculated 
percent of dropped/processed ntor cells is not a concern (over 10 
million processed, under 900 000 dropped).



Other relevant log messages that sustain my doubts:
This appeared when it was being hammered intentionally. As you can see 
the overload only took 7 minutes. At previous overload it took 5 minutes 
and previous previous overload 6 minutes.


I think the attacker saves resources as it gains same result overloading 
it 5 minutes versus overloading it 24x7.


Jan 03 07:14:42.000 [warn] Your computer is too slow to handle this many 
circuit creation requests! Please consider using the 
MaxAdvertisedBandwidth config option or choosing a more restricted exit 
policy. [2004 similar message(s) suppressed in last 213900 seconds]
Jan 03 07:15:42.000 [warn] Your computer is too slow to handle this many 
circuit creation requests! Please consider using the 
MaxAdvertisedBandwidth config option or choosing a more restricted exit 
policy. [52050 similar message(s) suppressed in last 60 seconds]
Jan 03 07:16:42.000 [warn] Your computer is too slow to handle this many 
circuit creation requests! Please consider using the 
MaxAdvertisedBandwidth config option or choosing a more restricted exit 
policy. [92831 similar message(s) suppressed in last 60 seconds]
Jan 03 07:17:42.000 [warn] Your computer is too slow to handle this many 
circuit creation requests! Please consider using the 
MaxAdvertisedBandwidth config option or choosing a more restricted exit 
policy. [89226 similar message(s) suppressed in last 60 seconds]
Jan 03 07:18:42.000 [warn] Your computer is too slow to handle this many 
circuit creation requests! Please consider using the 
MaxAdvertisedBandwidth config option or choosing a more restricted exit 
policy. [74832 similar message(s) suppressed in last 60 seconds]
Jan 03 07:19:42.000 [warn] Your computer is too slow to handle this many 
circuit creation requests! Please consider using the 
MaxAdvertisedBandwidth config option or choosing a more restricted exit 
policy. [79933 similar message(s) suppressed in last 60 seconds]
Jan 03 07:20:42.000 [warn] Your computer is too slow to handle this many 
circuit creation requests! Please consider using the 
MaxAdvertisedBandwidth config option or choosing a more restricted exit 
policy. [68678 similar message(s) 

Re: [tor-relays] Maybe the next step in russian Tor discrimination

[ValdikSS via tor-relays]

I can confirm that profitserver.ru at Chelyabinsk location has TSPU 
(government) DPI system, at least on one of their links for some of the 
destination IPs. On that link the filtering is the same as a residential 
connection from ER-Telecom.


The TSPU could be detected by 307 HTTP reply with Location header and 
nothing more:


# curl -v rutracker.org
*   Trying 45.132.105.85:80...
* TCP_NODELAY set
* Connected to rutracker.org (45.132.105.85) port 80 (#0)
> GET / HTTP/1.1
> Host: rutracker.org
> User-Agent: curl/7.68.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 307 Temporary Redirect
< Location: http://lawfilter.ertelecom.ru/
* no chunk, no close, no size. Assume close to signal end


Contrary to torproject.org request, which doesn't seem to be routed via 
TSPU (but via another DPI box, at Megafon):


# curl -v torproject.org
*   Trying 95.216.163.36:80...
* TCP_NODELAY set
* Connected to torproject.org (95.216.163.36) port 80 (#0)
> GET / HTTP/1.1
> Host: torproject.org
> User-Agent: curl/7.68.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 302 Found
< Location: http://m.megafonpro.ru/rkn?channel=3
* no chunk, no close, no size. Assume close to signal end


The IP addresses of blocked Tor relays and bridges are not reachable 
over Chelyabinsk profitserver as well.





OpenPGP_signature
Description: OpenPGP digital signature
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays