On 5 Dec 2017, at 22:50, x9p tor@x9p.org wrote:
my second and third positions are similar:
...
Please don't publicly share exact connection numbers and netblocks. They can be used in combination with other information to de-anonymise users.
(For example, if an adversary knows that a guard has 5 connections from a netblock that they can't otherwise observe, they can go and hunt down those users.)
On 6 Dec 2017, at 07:42, null null@omuravpn.com wrote:
... @ Scott Bennett:
What you are seeing is most likely the same phenomenon brought up onthis list repeatedly over at least the last decade or so. That phenomenon is providing HSDir service, or perhaps a rendez-vous point, for a popular hidden service.
If you don't like it, you can set
HidServDirectoryV2 0
Thanks for your reply. The data suggests this was not the case (this time). Some of these relays have been up almost a year with the same configuration, often with the HSDir flag. The recent issues just started occurring, and happened across several relays during the same timeframe.
Nonetheless, we're not opposed to disabling HidServDirectoryV2 to rule it out. However it appears that option is deprecated (on 0.3.1.9). Enabling it causes this in the log:
[WARN] Skipping obsolete configuration option 'HidServDirectoryV2'
It's also no longer listed in the Tor manual (https://www.torproject.org/docs/tor-manual.html.en). It looks like we might be able to achieve the same effect with something like this instead:
MinUptimeHidServDirectoryV2 52 weeks
Anyone have any info on why HidServDirectoryV2 is consider obsolete? Is using MinUptimeHidServDirectoryV2 instead going to achieve the same effect?
No, this option only applies to directory authorities, and determines their votes for the HSDir flag.
From the tor man page:
MinUptimeHidServDirectoryV2 N seconds|minutes|hours|days|weeks Minimum uptime of a v2 hidden service directory to be accepted as such by authoritative directories. (Default: 25 hours)
We have file descriptors (/proc/sys/fs/file-max) set to 64000, but it looks like Tor sets MAX_FILEDESCRIPTORS to 16384 per /etc/init.d/tor:
elif [ "$system_max" -gt "40000" ] ; then MAX_FILEDESCRIPTORS=16384
Surely that is high enough for normal service?
If by normal you mean "low traffic", then yes, it's probably enough.However, that's really not very high in a general sense.
Why does the default /etc/init.d/tor (from the Debian/Ubuntu pkg) cap MAX_FILEDESCRIPTORS at 16384 then? We have it set to 64000 otherwise. Obviously we could comment out these lines, but it seems odd the default config tries to cap it at 16384 if that's too low for a high traffic relay.
Perhaps it's the maximum allowed on some kernels or low-memory systems? Or perhaps it's historical?
I suggest that you submit a ticket or patch to the debian bug tracker.
T
-- Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org ------------------------------------------------------------------------