Re: [tor-relays] Tor Relay Web Ports

[Sebastian Elisa Pfeifer]

Are you running that from home? Then don't. Are you running it from a
datecenter? Ask the ISP if they allow Tor Exits. Then we will see!

On 20/05/2020 09:24, mnlph74 wrote:
> Hi, I'm running a non-exit relay for quite some time now and I would
> like to open ports 53, 80, 443 (web ports) to be more useful.
> How do you handle fraudulent complaints? What is the best approach to
> this situation? Thank you for your help.
>
>
> Sent with ProtonMail  Secure Email.
>
>
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Trouble with opening ports for a new bridge

[Philipp Winter]

On Wed, May 20, 2020 at 03:40:38PM +, nottryingtobel...@protonmail.com 
wrote:
> I have two low-traffic websites hosted on Digital Ocean. Each one is
> its own Droplet. I setup a Tor bridge on one and it has been running
> successfully (20-80 clients / 6 hours or so average) so I know this is
> possible. Now I am trying to setup a bridge on the second Droplet.

Is this your bridge?


If so, it is running just fine.  I could bootstrap an obfs4 connection
over it.  What makes you think that there is a problem?

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

Re: [tor-relays] Tor relay occasionally maxing out CPU usage

[William Kane]

It sure is a problem for those on virtualized machines with only a single core.

As far as offloading to a different worker thread goes, it should be
very easy to implement code wise, Tor already does off-load some
crypto stuff to a different thread when NumCPU's is set / detected
appropriately.

2020-05-20 12:24 GMT, Matt Traudt :
> To me it sounds like there isn't actually a problem. This is the way Tor
> works now (now == since consensus diffs were added). It's unfortunate
> that Tor isn't more multithreaded, so much happens in the same main
> loop, and client throughput is momentarily impacted, but that's the way
> it is and there isn't a problem here to be solved. At least not for you
> the relay operator.
>
> Getting more into tor-dev@ territory here, but doesn't compressing
> consensus documents sound like something that could easily be shoved
> over into a worker thread? I'm unfamiliar with the subsystem and I'm
> sure many of my implicit assumptions are wrong.
>
> Matt
>
> On 5/19/20 11:59, William Kane wrote:
>> Okay, so your suspicion was just confirmed:
>>
>> consdiffmgr_rescan_flavor_(): The most recent ns consensus is
>> valid-after 2020-05-19T15:00:00. We have diffs to this consensus for
>> 0/25 older ns consensuses. Generating diffs for the other 25.
>>
>> Right after, diffs were compressed with zstd and lzma, causing the CPU
>> usage to spike.
>>
>> Disabling DirCache still gives me the following warning on Tor 0.4.3.5:
>>
>> May 19 17:56:42.909 [warn] DirCache is disabled and we are configured
>> as a relay. We will not become a Guard.
>>
>> So, unless I sacrifice the Guard flag, there doesn't seem to be a way
>> to fix this problem in an easy way.
>>
>> Please correct me if I'm wrong.
>>
>>
>> 2020-05-19 15:07 GMT, William Kane :
>>> Another thing, from the change-log:
>>>
>>> - Update the message logged on relays when DirCache is disabled.
>>>   Since 0.3.3.5-rc, authorities require DirCache (V2Dir) for the
>>>   Guard flag. Fixes bug 24312; bugfix on 0.3.3.5-rc.
>>>
>>> If I understand this correctly, my relay would no longer be a Guard if
>>> I choose to disable DirCache in order to prevent Tor from hogging my
>>> CPU?
>>>
>>> From the code that I have seen, simply not setting the directory port
>>> does not stop the relay from caching / compressing diffs.
>>>
>>> Or has this been changed more recently?
>>>
>>> Not being a guard would honestly suck, and being a guard but with
>>> limited bandwidth due to Tor hogging the CPU also sucks.
>>>
>>> Any ideas on what to do?
>>>
>>> 2020-05-19 13:43 GMT, William Kane :
 Dear Alexander,

 I have added 'Log [dirserv]info notice stdout' to my configuration and
 will be monitoring the system closely.

 Tor was also upgraded to version 0.4.3.5, and the linux kernel was
 upgraded to version 5.6.13 but I do not think this will change
 anything.

 Expect a follow-up within the next 12 hours.

 William

 2020-05-18 1:40 GMT, Alexander Færøy :
> Hello,
>
> On 2020/05/17 18:20, William Kane wrote:
>> Occasionally, the CPU usage hit's 100%, and the maximum throughput
>> drops down to around 16 Mbps from it's usual 80 Mbps. This happens
>> randomly and not a fixed intervals which makes it pretty hard to
>> profile.
>
> One of the subsystem's that I can think of that could potentially lead
> to the problem that you are describing is our "consensus diff"
> subsystem. The consensus diff subsystem is responsible for turning
> consensus documents into these patch(1)-like diffs that clients can
> fetch without the need to transfer the whole consensus for each minor
> change.
>
> The subsystem also takes care of compression, which includes LZMA,
> which
> is a beast when it comes to burning CPU cycles.
>
>> No abnormal entries in the log files.
>
> I suspect you're logging at `notice` log-level, which is the reasonable
> thing to do. We need to log at slightly higher granularity to discover
> the problem here.
>
> Could I get you to add `Log [dirserv]info notice syslog` to your
> `torrc`? This line makes Tor log everything at notice log-level (the
> default), to the system logger, except for the directory server
> subsystem, which will be logged at `info` log-level instead. The code
> responsible for generating consensus diffs uses the `dirserv` for
> logging purposes.
>
> If the CPU spike happens right after a log message that says something
> in the line of "The most recent XXX consensus is valid-after XXX. We
> have diffs to this consensus for XXX/XXX older XXX consensuses.
> Generating diffs for the other XXX." then I think we have our winner.
>
> Please remember to remove the `info` log-level when the experiment is
> over :-)
>
> I'm curious what you figure out here. Let me know if you need any help.
>
> All the best,
> Alex.
>>

[tor-relays] Trouble with opening ports for a new bridge

[nottryingtobelame]

Hello,
I have two low-traffic websites hosted on Digital Ocean. Each one is its own 
Droplet. I setup a Tor bridge on one and it has been running successfully 
(20-80 clients / 6 hours or so average) so I know this is possible. Now I am 
trying to setup a bridge on the second Droplet.

I have Tor and obfs4proxy installed. My torrc is as follows:

Log notice file /var/log/tor/notices.log
RunAsDaemon 1
Nickname whatever
ExitRelay 0
ExitPolicy reject *:*
BridgeRelay 1
BridgeDistribution moat
ServerTransportPlugin obfs4 exec /usr/bin/obfs4proxy
ORPort 6063
ExtORPort auto
ContactInfo 

I am pasting the output of netstat -plunt to pastebin for the sake of clarity 
and space: https://pastebin.com/30UHP5FD

And here is a screenshot of the firewall I created on Digital Ocean and applied 
explicitly to this Droplet: https://imgur.com/a/jm9ZIQ6

I have rebooted the Droplet, deleted and re-created the firewall, and I'm not 
getting anywhere. Any assistance is appreciated.___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Tor relay occasionally maxing out CPU usage

[William Kane]

Hi Alexander,

I am a customer of Wedos Internet, and originally ordered this virtual
machine back in 2014, as far as I know no hardware updates to the
hypervisor were ever performed, so it's likely some older Intel Xeon
(clocked at 2133.408MHz), guess with that information you can find the
exact CPU model.

Here's the output from 'lscpu':

Architecture:x86_64
CPU op-mode(s):  32-bit, 64-bit
Byte Order:  Little Endian
Address sizes:   40 bits physical, 48 bits virtual
CPU(s):  1
On-line CPU(s) list: 0
Thread(s) per core:  1
Core(s) per socket:  1
Socket(s):   1
NUMA node(s):1
Vendor ID:   GenuineIntel
CPU family:  6
Model:   13
Model name:  QEMU Virtual CPU version (cpu64-rhel6)
Stepping:3
CPU MHz: 2133.408
BogoMIPS:4268.60
Hypervisor vendor:   KVM
Virtualization type: full
L1d cache:   32 KiB
L1i cache:   32 KiB
L2 cache:4 MiB
NUMA node0 CPU(s):   0
Vulnerability Itlb multihit: KVM: Vulnerable
Vulnerability L1tf:  Mitigation; PTE Inversion
Vulnerability Mds:   Vulnerable; SMT Host state unknown
Vulnerability Meltdown:  Vulnerable
Vulnerability Spec store bypass: Vulnerable
Vulnerability Spectre v1:Vulnerable: __user pointer
sanitization and usercopy barriers only; no swapgs barriers
Vulnerability Spectre v2:Vulnerable, STIBP: disabled
Vulnerability Tsx async abort:   Not affected
Flags:   fpu de pse tsc msr pae mce cx8 apic
sep mtrr pge mca cmov pse36 clflush mmx fxsr sse sse2 syscall nx lm
nopl cpuid tsc_known_freq pni cx16 hypervisor lahf_lm

Notice the lack of AES instructions, despite them being supported by
the host cpu - I previously asked them reconfigure their KVM
configuration to set the emulated CPU model to 'host' so I can benefit
from hardware AES-NI acceleration but they refused even though this
would help to reduce CPU load, improve throughput and make headroom
for non-crypto operations (such as the diffing / compression of
consensus documents which hogs my CPU for multiple minutes).

Further specs of the VM:

1024MB of RAM
256MB Swap

Memory wise, no problems at all, the tor process doesn't utilize more
than 600 MB's even under maximum load, and the base system only
utilizes ~60MB so it's not a ram bottleneck.

I thought about re-writing the code responsible for compression to
make it use the least CPU intensive compression level.

If anyone is familiar with the code responsible for it, let me know if
my attempts are going to be futile (I have 10+ years of experience
with C/C++, just not with the Tor code base except for very small
parts of it.)

William

2020-05-20 13:06 GMT, Alexander Færøy :
> On 2020/05/19 15:59, William Kane wrote:
>> Right after, diffs were compressed with zstd and lzma, causing the CPU
>> usage to spike.
>
> Thank you for debugging this William.
>
> Tor behaves in the way it is designed to here. Tor uses a number of
> worker threads to handle compression (and a couple of other tasks), but
> what worries me is how big an impact it has on the traffic processing of
> your relay during the time where your relay is also compressing.
>
> I'm a bit curious what the specs are of your relays here -- especially
> CPU and memory specs?
>
>> Disabling DirCache still gives me the following warning on Tor 0.4.3.5:
>>
>> May 19 17:56:42.909 [warn] DirCache is disabled and we are configured
>> as a relay. We will not become a Guard.
>>
>> So, unless I sacrifice the Guard flag, there doesn't seem to be a way
>> to fix this problem in an easy way.
>
> This is correct for now. Tor have the `NumCPUs` configuration entry,
> which defines how many workers we can spawn, but the default value is
> sensible for most systems and I doubt it makes sense to tune this for
> you.
>
>> Please correct me if I'm wrong.
>
> You're right.
>
> All the best,
> Alex.
>
> --
> Alexander Færøy
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
>
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] Metrics site down

[mnlph74]

As of this writing... noticed that the metrics site is currently down.. Can 
someone confirm? Thanks
https://metrics.torproject.org/

Sent with ProtonMail Secure Email.

publickey - mnlph74@protonmail.com - 0xA7D18794.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] Tor Relay Web Ports

[William Kane]

P.S: If you were not asking about relays on OVH, my bad - had their
company name stuck in my head due to your previous posts to the
mailing list.

2020-05-20 21:07 GMT, William Kane :
> Port 53 over TCP (DNS) seems useless, it won't be used at all or only
> very rarely - your exit already resolves domain names for your
> clients, this is why it's recommended to have a local recursive
> resolver installed instead of passing on DNS requests to remote
> services such as Google or Cloudflare DNS, due to the possibility of
> correlation and anonymity compromising attacks:
>
> https://medium.com/@nusenu/who-controls-tors-dns-traffic-a74a7632e8ca
> https://medium.com/@nusenu/what-fraction-of-tors-dns-traffic-goes-to-google-and-cloudflare-492229ccfd42
>
> If you open up 80 and 443, expect to receive a lot of abuse mails
> related to brute-forcing or exploit attempts, and having to deal with
> the occasional douche-bag downloading child porn from a clear-net
> hoster and confused law enforcement agencies.
>
> If that doesn't bother you or your hoster (in the case of OVH, it
> will, I can guarantee you that), then go ahead.
>
> OVH is a bad provider though, over-congested network due to all the
> seed boxes, bad peering, many Tor nodes already hosted there, etc.
>
> All that means please don't host another node there, instead go for a
> small provider, ideally also in a country which does not host a lot of
> Tor nodes already, see if they host only a handful of Tor nodes,
> ideally colocate, get your own IP range and ask them to modify the
> abuse address for the range to an address you control.
>
> After that is all done, you can safely ignore most abuse reports
> unless they actually have a case against you, which, in most countries
> is not possible due to network providers being protected from
> liability by the law.
>
> Hope this helps.
>
>
> 2020-05-20 7:24 GMT, mnlph74 :
>> Hi, I'm running a non-exit relay for quite some time now and I would like
>> to
>> open ports 53, 80, 443 (web ports) to be more useful.
>> How do you handle fraudulent complaints? What is the best approach to
>> this
>> situation? Thank you for your help.
>>
>> Sent with ProtonMail Secure Email.
>
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Tor Relay Web Ports

[William Kane]

Port 53 over TCP (DNS) seems useless, it won't be used at all or only
very rarely - your exit already resolves domain names for your
clients, this is why it's recommended to have a local recursive
resolver installed instead of passing on DNS requests to remote
services such as Google or Cloudflare DNS, due to the possibility of
correlation and anonymity compromising attacks:

https://medium.com/@nusenu/who-controls-tors-dns-traffic-a74a7632e8ca
https://medium.com/@nusenu/what-fraction-of-tors-dns-traffic-goes-to-google-and-cloudflare-492229ccfd42

If you open up 80 and 443, expect to receive a lot of abuse mails
related to brute-forcing or exploit attempts, and having to deal with
the occasional douche-bag downloading child porn from a clear-net
hoster and confused law enforcement agencies.

If that doesn't bother you or your hoster (in the case of OVH, it
will, I can guarantee you that), then go ahead.

OVH is a bad provider though, over-congested network due to all the
seed boxes, bad peering, many Tor nodes already hosted there, etc.

All that means please don't host another node there, instead go for a
small provider, ideally also in a country which does not host a lot of
Tor nodes already, see if they host only a handful of Tor nodes,
ideally colocate, get your own IP range and ask them to modify the
abuse address for the range to an address you control.

After that is all done, you can safely ignore most abuse reports
unless they actually have a case against you, which, in most countries
is not possible due to network providers being protected from
liability by the law.

Hope this helps.


2020-05-20 7:24 GMT, mnlph74 :
> Hi, I'm running a non-exit relay for quite some time now and I would like to
> open ports 53, 80, 443 (web ports) to be more useful.
> How do you handle fraudulent complaints? What is the best approach to this
> situation? Thank you for your help.
>
> Sent with ProtonMail Secure Email.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays