Hi,
Everytime i speak with colleagues i wonder that the most performance related options for TOR relays are unknown.
I just started to write down what i know and i would be happy if someone else could benefit from that.
There a couple of sysctrl parameters that Moritz described here: https://www.torservers.net/wiki/setup/server#sysctlconf
Without setting them my relays were not able to handle really large numbers of concurrent connections.
Regards,
torland
On Monday 24 March 2014 20:02:15 Sebastian Urbach wrote:
Hi,
Everytime i speak with colleagues i wonder that the most performance related options for TOR relays are unknown.
I just started to write down what i know and i would be happy if someone else could benefit from that.
On 24 Mar 2014, at 20:21, tor-admin tor-admin@torland.me wrote:
There a couple of sysctrl parameters that Moritz described here: https://www.torservers.net/wiki/setup/server#sysctlconf
That website has at least one glaringly dangerous suggestion, namely
apt-key adv --recv-keys --keyserver keys.gnupg.net 886DDD89
The issue is that he key which is to be fetched from a public, untrusted keyserver using an unauthenticated protocol is not being verified at all. This immediately compromises the entire box in case someone is messing with your upstream traffic.
It would seem advisable to review the remainder of the advice there, and also fix the above problem.
Cheers Sebastian
On 03/25/2014 03:29 AM, Sebastian Hahn wrote:
That website has at least one glaringly dangerous suggestion, namely apt-key adv --recv-keys --keyserver keys.gnupg.net 886DDD89
I agree. That is coming from https://www.torproject.org/docs/debian.html.en btw :)
On 03/25/2014 04:29 AM, Sebastian Hahn wrote:
On 24 Mar 2014, at 20:21, tor-admin tor-admin@torland.me wrote:
There a couple of sysctrl parameters that Moritz described here: https://www.torservers.net/wiki/setup/server#sysctlconf
That website has at least one glaringly dangerous suggestion, namely
apt-key adv --recv-keys --keyserver keys.gnupg.net 886DDD89
The issue is that he key which is to be fetched from a public, untrusted keyserver using an unauthenticated protocol is not being verified at all. This immediately compromises the entire box in case someone is messing with your upstream traffic.
It would seem advisable to review the remainder of the advice there, and also fix the above problem.
Cheers Sebastian
A couple of thoughts on this :
one could use hkps as transport, as suggested here [1]
Mind that hkps will provide encryption while fetching the key, thus anyone observing your traffic will not be able to know which key you did fetch. What is more if you want gpg to work with hkps you will probably have to trust the certificate of the hkps keyserver.
_But_ you should not rely on hkps or the server to fetch the right key. What's the point of web of trust and digital signatures and stuff in the end, if you just rely on single (perhaps central) point?
The correct way, I think, is to know a priori the correct fingerprint of the public key you want to fetch. That is, you somehow have to know that Tor's debian repository signing key is the one with fingerprint A3C4 F0F9 79CA A22C DBA8 F512 EE8C BC9E 886D DD89. Or somehow build a trust path to it, for example if you trust one of the persons who have signed it. [2]
I hope more people will give some input on this conversation though, cause it's an important detail. Also I might miss something.
Cheers, Alex
[1] https://we.riseup.net/debian/openpgp-best-practices#consider-making-your-def...
[2] http://keys.mayfirst.org/pks/lookup?op=vindex&search=0x886DDD89&fing...
tor-relays@lists.torproject.org