Re: [tor-relays] AWS abuse handling

[Roman Mamedov]

On Wed, 27 Jul 2016 21:07:39 +0200
Markus Koch  wrote:

> Okay, I knew I am not a normal person with over a petabyte a months across 
> all my servers but seriously what service can you run on a vps with 15 gigz a 
> month? 

Well for example you could run some IRC or IM related service, or something
else where you don't transfer a lot of stuff from/to the VPS in general.

However my chief concern with the AWS would be that they don't turn off your
VPS as soon as you exceed the 15GB, they start *charging* you for the bandwidth
overage, at pretty exorbitant rates, and then bill directly from your credit
card (which they require that you leave with them when signing up for this).
Also I believe there are some limits on the amount of disk access, with the
same billing policy. Basically the "free" AWS is a minefield, one mistake and
you can find yourself paying ridiculous amounts for it.

As for being "on a tight budget", you cannot afford one euro a month[1], two
euros a month[2], 15 USD per year[3], really? Not to mention getting 500GB to
2 TB bandwidth on those, not 15GB.

The free AWS is the most widespread mistake in choosing "your first VPS" for
just about any purpose (and as mentioned can be a dangerous one); probably
because people are generally unaware how cheap the actual proper VPSes can be.

[1] https://www.arubacloud.com/
[2] https://www.ultravps.eu/en/plans/
[3] http://ramnode.com/vps.php

-- 
With respect,
Roman


pgpwggQ072Ggn.pgp
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] AWS abuse handling

[Roman Mamedov]

On Thu, 28 Jul 2016 08:09:12 +0100
"Louie Cardone-Noott"  wrote:

> Am I right in thinking that even 2 TByte/month is fairly low? That's
> only 6 Mbit/s average (whether that's 6/6 or 3/3 depends on their
> accounting I suppose).

That's correct, however I don't have any unmetered offers to recommend, which
would be as cheap as those mentioned, and at the same time would not be at OVH
or DigitalOcean (which, as recent discussions show, have "too many" relays
already).

-- 
With respect,
Roman


pgpHkg7d9Gztg.pgp
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] cheap unmetered non-exit VPS offers

[Roman Mamedov]

On Thu, 28 Jul 2016 15:30:02 +0200
Markus Koch  wrote:

> Just chatted with the Support and I highly doubt they are knowing what
> they are doing, anyway setup one exit relay and will report back after
> my first abuse mail. This will be fun :)
> 
> btw:
> Jul 28 15:24:19.832 [warn] Failed to parse/validate config: Nickname
> 'niftychinchillarabbit' is wrong length or contains illegal
> characters.

Up to 19 characters, whereas yours is

echo -n niftychinchillarabbit | wc -c
21

-- 
With respect,
Roman


pgpWbEwxpb1l8.pgp
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] outgooing UDP flooding on middle relay

[Roman Mamedov]

On Mon, 1 Aug 2016 14:28:04 +0200
pa011  wrote:

> Hello,
> 
> one of my middle relays got auto limited by the ISP because of
> "outgooing UDP flooding ".
> 
> The VPS is pure debian8, fail2ban, pub key and nothing else installed -
> so I highly doubt the give reason for the traffic limitation.
> Also I cant find anything in the log files.
> 
> Anybody having experience with such an issue?
> What to check for please?

Happened once to me, in my case the culprit was a buggy DHCPv6 client (i.e.
unrelated to Tor). Does your VPS utilize IPv6 with DHCPv6 and which client do
you use, if so?

-- 
With respect,
Roman


pgpZUorD5hIMQ.pgp
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] High speed Tor relay advice

[Roman Mamedov]

On Sun, 14 Aug 2016 20:57:13 -0400
George  wrote:

> > Alternately, run ntpdate via cron every few hours, to avoid running
> > an unnecessary network service. (Recent security issues in ntp remain
> > unpatched in some distributions.)
> 
> There's actually a technical problem with running ntpdate periodically.
> NTP works by slowly and carefully adjusting the time, accounting for any
> local gaps without breaking any precise-time requiring daemons or
> functions, like databases.  ntpdate might be used on startup (or with
> ntpd_sync_on_start), but it's deprecated last I read. Tools like rdate
> are not replacements for an ntp daemon on a production system.
> 
> You might even notice the tor daemon isn't fond of abrupt time
> adjustments, and will bark in the log about it.

I do the same (ntpdate in crontab) and have never seen any issues with that.
If you run ntpdate often enough (in my case I find every 6 hours suffices)
your computer clock will never have the chance to drift far enough away, so
that the ntpdate adjustment would disrupt anything.

-- 
With respect,
Roman


pgpe6GoHJEQ4Z.pgp
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] High speed Tor relay advice

[Roman Mamedov]

On Mon, 15 Aug 2016 02:35:49 -0400
grarpamp  wrote:

> On 8/14/16, i3  wrote:
> > My new server has 10Gb/s connection (I've observed it at 900MB/s to the 
> > drives
> 
> Depending on whether you meant MiB/s or MB/s,
> you may find your network calculations off by 350Mbps,

To me these seem to be just two loosely related facts, the latter merely
supporting the notion that the network connection is capable of way more than
1Gbps. I don't see any "network calculations" being presented.

> Standard use is decimal and bits for network "Mbps",
> and binary and bytes for disk "MiB". "MB/s" is neither.

https://en.wikipedia.org/wiki/Megabyte: "The megabyte is a multiple of the
unit byte for digital information. Its recommended unit symbol is MB."
MB/s is a long-accepted shorthand for Megabyte per second, and yes, Mb/s is
megabit per second. But please, take your "MiB" lunacy elsewhere.

-- 
With respect,
Roman


pgpDOdkTquYcv.pgp
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] Pi3 mid relay dropping lil bit of packets

[Roman Mamedov]

On Mon, 15 Aug 2016 20:08:31 +0200
Pi3  wrote:

> Hello,
> I just started running my little 5 mbits mid relay on Pi3 on raspbian and all 
> seems to be dandy,
>  it picked traffic nicely, hovering around 700-800 total connections, 
> its not unusual to see it pushing full advertised bandwidth during peak hours 
> (with ~20-25% load on 1 core, multithread pls come already), tldr so far nice.
> Except with 3days uptime and 20 gigs of data relayed ifconfig shows 11 
> (eleven) packets dropped on eth0. 
> Google says it can be ring buffer on NIC getting full, but 
> ethtool -g eth0 says
> Ring parameters for eth0: Cannot get device ring settings: Operation not 
> supported
> ethtool -S eth0 = no stats available
> Htop avg load is 0.30, tor uses 121/950mb of ram. Im running standard 
> conntrack cstate established related iptable rule with default drop. 
> Pi3 is in LAN behind modem nat. 
> It worries me because if I get more consensus, drops will probably go up.
> I didnt apply any sysctl tweaks. Using official deb
> NIC is Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter and 
> its internally connected to usb2 by design - it shows under lsusb.
> ethtool says 100Mb/s full duplex. 
> Tor log is clean with only heartbeat in it, syslog seemed ok also if I didnt 
> miss anything.
> Or is it so marginal I should forget about it?
> Im not sure what should I do about it, any suggestions are welcomed.
> Thanks

Like others explained, just 11 frames (at maximum, around 15 KB or so in 20GB!)
is practically nothing, so there is no reason to worry. Also keep in mind that
frames can be dropped for legitimate reasons, e.g. if for some reason the board
sees packets on the wire which are not addressed to it, or oversized, or
generally malformed in some way by the other side. In any case, thanks to TCP
any dropped frame (=lost packet) gets rapidly retransmitted with no significant
impact on throughput or connection stability.

That said, I remember from reading various Raspberry Pi forums that the
smsc95xx device doesn't exactly have the reputation of the most reliable or
well designed piece of hardware in the world (mostly related to attempts to
make various 'unusual' USB devices such as some audio interfaces to work with
it, or using a number of USB devices concurrently), so considering your
results it's actually working amazingly well for you so far. :)

-- 
With respect,
Roman


pgpp6r5cC2MTO.pgp
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] Tiny computers (RPi-like) for exit nodes?

[Roman Mamedov]

On Thu, 18 Aug 2016 10:40:00 -0600
Michael McConville  wrote:

> Zack Weinberg wrote:
> > Has anyone had any experience running *exit* nodes on Raspberry
> > Pi-grade hardware, or slightly beefier?  We are thinking of replacing
> > the old, bulky, power-hungry machine currently running exit
> > 78C7C299DB4C4BD119A22B87B57D5AF5F3741A79 with something on that level.
> > It only has to hit 10Mbps.
> 
> There's only one way to find out, but I suspect an RPi would be too weak
> for the job. Exits use more CPU because they manage far more TCP/UDP
> connections than a non-exit relay. I've seen significant CPU usage
> (maybe even CPU saturation) on a cheap Intel Core Duo moving about 3-5
> MB/s.

Raspberry Pi 3 should do fine, not to mention some of the more powerful
boards -- there are now up to 8-core, up to 1.7 GHz ones. Even though the core
number won't help you too much, you shouldn't underestimate what a modern
64-bit ARM can do. Especially if the task at hand is mere 10 Mbps.

-- 
With respect,
Roman


pgpbhHSuKmZZv.pgp
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] Why can't I see more traffic? (is my banana too weak?)

[Roman Mamedov]

On Sat, 03 Sep 2016 16:53:25 +0200
Aeris  wrote:

> > Could it be that it is due to the quite slow hardware, even though I know
> > that it is able to push more traffic?
> 
> Yep, surely.
> 
> You currently push 3Mbps of traffic, which is correct for this kind of 
> hardware.
> All "cheap" hardware (raspi, banana, olimex, pine…) suffer of the fact they 
> don’t have crypto hardware acceleration and do software encryption. And so is 
> very slow (10-100× factor) even compared to low end amd64 CPU with AES-NI 
> extension.

According to 'openssl speed aes-128-cbc' the Allwinner A20 CPU in Banana Pro is
capable of about 25 MBytes/sec in AES performance. While that won't translate
1:1 into Tor performance, as Farid noted in his case the CPU isn't being a
bottleneck, with only 10-20% CPU load observed.

@Farid,

> According to top the CPU hovers around 10-20% most of the time.

I wonder is it 20% across both cores, which could be 40% of one core (since
Tor is not multithreaded enough), and at least somewhat closer to not being
practically idle. Can you launch 'top' and press '1' there to check?

Also seems unclear why it didn't get the guard flag for so long, does your
public IP address change from time to time? Or do you turn the relay off and
on for whatever reason.

-- 
With respect,
Roman


pgpeQqgRbcaFl.pgp
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] DigitalOcean pricing (Re: tomhek - the (new) biggest guard relay operator)

[Roman Mamedov]

On Tue, 13 Sep 2016 15:26:05 +
"Admin Kode-IT"  wrote:

> It's like you're running a Rasperry Pi 1 with an SSD and a good Network for 
> 5$/month.

From my quick testing a DO droplet provides at least 6 times faster CPU than a
Raspberry Pi 1, and more likely closer to 10-20x faster in real world usage.

-- 
With respect,
Roman


pgpWM_uGoV54J.pgp
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] Node families and guard flags

[Roman Mamedov]

On Thu, 15 Sep 2016 19:39:07 +0200
Ralph Seichter  wrote:

> On 15.09.2016 18:40, Markus Koch wrote:
> 
> > 100%  normal. Welcome to tor.
> > No, no clue why ;)
> 
> I was contemplating possible security considerations behind this. One
> particular person or organization responsible for the administration of
> multiple guards, when guards are sensitive because users connect to them
> directly... That sort of thing.
> 
> The alternative might be messed up node configurations, so I thought I'd
> better ask. ;-)

It is normal to run multiple nodes in one family and have most or all of them
get the Guard flag. I don't see why two specifically must be any special
(unless you mean both on the same IP?).

-- 
With respect,
Roman


pgpCScDKiAD3h.pgp
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] Node families and guard flags

[Roman Mamedov]

On Thu, 15 Sep 2016 20:34:54 +0200
Ralph Seichter  wrote:

> On 15.09.16 19:43, Roman Mamedov wrote:
> 
> > It is normal to run multiple nodes in one family and have most or all
> > of them get the Guard flag.
> 
> I don't see this happen. I would think that weeks of uninterrupted
> uptime should mean both nodes qualify, but only one has a guard flag.
> The nodes are on separate machines, with IP addresses dissimilar enough
> for me not to expect issues based on these.

You should post both fingerprint or even just Atlas links directly, maybe
someone will have more ideas on why this could happen. One possibility is if
you're perhaps on the lower brink of the Guard bandwidth requirements, and one
qualifies by chance, while the other doesn't.

-- 
With respect,
Roman


pgpyNefQGuiYN.pgp
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] Guard/Middle/Exit Hosting

[Roman Mamedov]

On Thu, 15 Sep 2016 22:41:41 +0200
Markus Koch  wrote:

> You are welcome :)
> 
> JUST A NOTE: TRAFFIC IS F R E E and UNLIMITED. You don't have to worry
> about the $20/TB at all. ATM! This can chance anytime but atm the
> traffic is FREE! Use is, there are lots of high traffic tor nodes out
> there. Join them ;)

Two problems with proclamations like these:

A) Tor network gets even more DigitalOcean based relays, which are already
kind of discouraged due to them comprising an overly significant part of the
network as it is;

B) tons of very heavy bandwidth users sign up at DO all at once (not to
mention all using the free credit coupon!), putting an increased load on their
networks, and quite likely moving the "Implement bandwidth billing" thing up in
priorities a notch or two (which will end up diminishing the value of DO's
offers for many of their users, not just for Tor relay operators).

IOW you could do better than posting the entire thing here. :)

-- 
With respect,
Roman


pgpHeR4LteSFx.pgp
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] "Potentially dangerous relay groups"

[Roman Mamedov]

On Tue, 27 Sep 2016 21:24:59 +0200
Tim Semeijn  wrote:

> Always watching my ass to be a good old Tor operator, I got my nodes on
> the list. Always fun to see how one time not updating all your
> MyFamily's gets you marked for life xD
> 
> Time for some conf-updating.

To possibly simplify this a bit, consider that:

*) It doesn't hurt anything if a node has itself listed in its own MyFamily.
You can just use the same MyFamily string in all your configs.

*) Give up on listing fingerprints, instead simply list nicknames. Any harm
this can possibly cause, is largely hypothetical. So if that simplifies
management for you, just go for it.

*) Over-listing is better than under-listing, so you can add ALL node nicknames
you currently use or plan to use soon, and don't worry about listing some which
are down at the moment, or not set up just yet.

-- 
With respect,
Roman


pgpondiy46qOK.pgp
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] "Potentially dangerous relay groups"

[Roman Mamedov]

On Wed, 28 Sep 2016 02:38:37 -0400
grarpamp  wrote:

> On Tue, Sep 27, 2016 at 4:38 PM, Roman Mamedov  wrote:
> > *) Give up on listing fingerprints, instead simply list nicknames.
> 
> No. Fingerprints are what to use here. Please do not use nicknames.

Any actual rationale, other than "do as I say"? And aside from linking to the
man page which doesn't provide one EITHER.

The only problem I can imagine with this is that Nefarious People can run a
same fingerprint relay with the same MyFamily string as mine, and by that join
my family, possibly knocking out one of my actual relays out of it. But what
exactly would anyone achieve with that, is entirely unclear.

> Besides, other than for simply announcing a vanity tag, nicks are
> going away in every area they are currently accepted as config input,
> so don't get used to them as such. See tickets 12898, etc.

Then expect the number of people to even bother with MyFamily, to dwindle
further.

-- 
With respect,
Roman


pgpaAETTCEr2K.pgp
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] "Potentially dangerous relay groups"

[Roman Mamedov]

On Wed, 28 Sep 2016 11:53:51 +0500
Roman Mamedov  wrote:

> The only problem I can imagine with this is that Nefarious People can run a

same nickname relay *


-- 
With respect,
Roman


pgp6uN5Itqc5L.pgp
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] "Potentially dangerous relay groups"

[Roman Mamedov]

On Wed, 28 Sep 2016 11:41:16 +0200
Ralph Seichter  wrote:

> Key fingerprints are technically much closer to being IDs than nicknames,
> which are nothing but short strings that can - and do - change at a whim.

We're talking MyFamily, so it's you who is in control of all the nicknames,
and it's only by your whim they may or may not change.

Still did not see any concrete practical arguments to why fingerprints are
worth the additional hassle, especially when what we see in reality is
nicknames working there perfectly well and causing zero issues whatsoever for
years.

-- 
With respect,
Roman


pgphLU5fB1WRV.pgp
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] Dealing with OVH Abuse Complaints

[Roman Mamedov]

On Wed, 5 Oct 2016 18:55:26 +1100
teor  wrote:

> Does anyone have experience running a long-lived Exit on OVH / So You Start?
> 
> We've just received a threat to shut down our OVH Exit due to abuse 
> complaints.
> We were responding to these automated reports (mainly SSH brute force) with 
> template responses, offering to block the destination IP and port if the 
> remote site wanted us to. We never received a reply.
> 
> What does OVH expect its Exit operators to do with complaints?
> Should we have blocked each complaining IP address as soon as we received a 
> complaint?

https://www.soyoustart.com/fr/documents_legaux/Conditions_particulieres_serveur_SoyouStart.pdf

6.4 Pour des raisons de sécurité, OVH se réserve la
possibilité de procéder à la suspension immédiate et sans
préavis de tout Serveur sur lequel serait proposé à titre
gracieux ou onéreux, un service ouvert au public de Proxy,
IRC, VPN, TOR, pour lequel OVH aurait connaissance
d'une utilisation malveillante, frauduleuse ou illicite. 
---
6.4 For security reasons, OVH reserves the
chance to make the immediate suspension without
notice of any server on which would be proposed as
or without charge, a service open to the public Proxy,
IRC, VPN, TOR, for which OVH has knowledge
a malicious, fraudulent or illegal.
---

Some take this as "OVH doesn't allow Tor", I take this as "don't run exits 
there".

-- 
With respect,
Roman


pgpvcWxxt_BQ4.pgp
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] RPi Relay Maximum Speed

[Roman Mamedov]

On Wed, 12 Oct 2016 07:18:56 +0200
Manny  wrote:

> I have a 1gbit symmetric connection at home and would like to donate 
> 100mbit with my raspberry pi 3 model b. Since it has a 100mbit Network 
> Interface, I'm limited to that anyways.
> 
> What Settings do I Need in my torcc to get the Maximum Speed? At the 
> Moment I entered 12 Mbytes - which Shows up at 96 mb/s in Arm - is that 
> correct and my understanding of things is just the opposite?
> Max Speed, I think, should be 12.7mb/s for a 100mbit Connection?

mb is not a thing that exists;
Mb is megabits: https://en.wikipedia.org/wiki/Megabit
MB is megabytes: https://en.wikipedia.org/wiki/Megabyte

What you entered in torrc is currently correct. But since your board has a 100
Mbit interface anyway, it would be better if you just omit the bandwidth limit
line entirely.

Also, actually hit anything remotely close to 100 Mbit, you'll absolutely have
to run two instances of Tor. The Raspberry Pi 3 has 4 CPU cores, but each core
on its own is not very fast. One copy of Tor only uses about 1 to 1.3 cores,
so to fully utilize your hardware you need more than one. Ideally you'd set up
four, but the Tor network will only accept two running from the same IPv4
address. It appears that these days there's a built-in script for that, see
"man tor-instance-create".

-- 
With respect,
Roman


pgpQtu3MAwnb9.pgp
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] RPi Relay Maximum Speed

[Roman Mamedov]

On Wed, 12 Oct 2016 07:20:25 -0500
Tristan  wrote:

> Remember, a relay has to download and upload as well, so your 100Mbps link
> would really only be able to _relay_ at 50Mbps anyway.

The OP mentioned they have "1gbit symmetric connection at home", i.e.
1000 Mbit in, 1000 out.

Whether or not the Raspberry Pi will be limited to some value less than 100
Mbit when doing full duplex, is an interesting question; yes it uses a
USB-based Ethernet chip, but that alone doesn't mean much, since the USB 2.0
is capable of up to 480 Mbit. It's a question of how efficient the actual used
implementation is. Can be easily tested with "iperf -c ... -d".

Alternatively you can get a Gigabit NIC for USB, like described in
http://www.jeffgeerling.com/blogs/jeff-geerling/getting-gigabit-networking

-- 
With respect,
Roman


pgpbQoQnOpZsf.pgp
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] Smallest, cheapest, lightest computer for tor relay

[Roman Mamedov]

On Mon, 17 Oct 2016 01:01:06 +0200
diffusae  wrote:

> Yes, you are right. That doesn't make a real big difference.

Yes it does make a real big difference. Get the Pi 3, the 1st Pi is an order
of magnitude slower.

> The RPi is good to use as relay with your requirement. You can expect a
> total transfer rate of 11 MBytes (100 Mbits/sec). If you use Raspberry
> Pi 1 Model B+ you cannot use the official Tor repository

And no you can not expect 11 Mbytes/sec on a R Pi 1.

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

Re: [tor-relays] DNS resolving -problem?

[Roman Mamedov]

On Tue, 18 Oct 2016 11:58:38 +0200
pa011  wrote:

> apt-get install dnsmasq
> 
> /etc/resolv.conf
>   nameserver 127.0.0.1
> 
> /etc/dnsmasq.conf 
>   server=216.87.84.211 #open.nic us
>   server=84.200.69.80  #dns.watch us
>   server=84.200.70.40  #dns.watch us
>   server=194.150.168.168
>   server=62.113.203.99
>   server=188.165.200.156
>   server=5.9.49.12
>   server=193.183.98.154
>   server=46.101.89.89
>   cache-size=1

>   dnssec
>   dnssec-check-unsigned
> 
> 
> etc/init.d/dnsmasq restart

Sooo, did you actually check you can resolve DNS on the host after that?

Even a trivial "ping google.com", or more proper "nslookup torproject.org".

>   conf-file=usr/share/dnsmasq-base/trust-anchors.conf

This appears like it might need a leading "/" before "usr".

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

Re: [tor-relays] manual vs. automated updates

[Roman Mamedov]

On Wed, 26 Oct 2016 10:53:19 +0200
Markus Koch  wrote:

> I was talking about the bridges you can see on the screen shot. These
> were my "backup" Digital Ocean accounts because Digital Ocean kicked
> my exits after 2-3 months. Digital Ocean is not allowing any exits
> anymore so I use the prepaid accounts to run bridges. The bridges will
> all die end of the year. I will just run them until the prepaid money
> is gone.

Bridges consume next to no bandwidth and can be run on any low speed or b/w
limited connections, whereas you'd get much better use from the resources you
currently get at DO by running regular non-exit relays there.

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

Re: [tor-relays] is it possible to relay using ipv6?

[Roman Mamedov]

On Mon, 28 Nov 2016 10:01:03 +1100
teor  wrote:

> (I've rearranged your threads for clarity, please bottom-post in future.)
> 
> >> On Nov 27, 2016 11:59 AM, "root"  >> > wrote:
> >> 
> >>It is end 2016 we should change from must have IPv4 to must have
> >>IPv6 and can have IPv4.
> 
> When the proportion of Tor relays with IPv6 is above 60%, dual stack by
> default on clients is a feasible option.
> 
> When the proportion exceeds 85% (the cube root of 60%), a switch may
> become plausible.
> 
> The proportion of Tor relays with IPv6 is currently at 17% of
> bandwidth.

Could have been higher, if it weren't so cumbersome to configure.

If you honestly want Tor IPv6 adoption to go up, you should stop treating it
as a second-class citizen in Tor, i.e. firstly remove the need to have a
static literal IPv6 in the config. Not a single other network daemon requires
that. And many home IPv6 allocations are dynamic, so users with those can't
feasibly set that up even if they wanted.

What was it, "it's tricky to autodetect which IPv6 to use"? No it's really
not. Even starting with a simple "ip route get 2001:db8::", then looking at
what "src" you get and if it's a proper global one (in 2000::/3), and try to
retrieve something from the Tor project over v6 to confirm that it actually
works. Done.

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

Re: [tor-relays] Unwarranted discrimination of relays with dynamic IP

[Roman Mamedov]

On Sun, 4 Dec 2016 20:47:17 -
"Alan"  wrote:

> Thanks for that, I've made changes to both torrc files.
> I've added MyFamily with each others finger print like so:
> MyFamily E856ABA2020AA9C483CC2D9B4C878D8D948B0887

You don't need to only list the other one(s) in each MyFamily, you could
simply list all your relays in it. This tends to simplify management of this,
and since now the MyFamily line is identical on all hosts, you have a simpler
task if you want to automate adding it to the configs.

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

Re: [tor-relays] Unwarranted discrimination of relays with dynamic IP

[Roman Mamedov]

On Tue, 6 Dec 2016 22:00:20 +0100
diffusae  wrote:

> Well, I can read and also now the translation from Bits to Bytes.
> But I am not sure about your value of the maximum network capacity.
> 
> That's the iperf3 measurement of a Raspberry Pi 1 Model B+:
> 
> [ ID] Interval   Transfer Bandwidth   Retr
> [  4]   0.00-10.00  sec  83.6 MBytes  8.36 MBytes/sec  141
> sender
> [  4]   0.00-10.00  sec  83.1 MBytes  8.31 MBytes/sec
> receiver

It's no problem to push close to 100 Mbit on any Raspberry Pi with just plain
iperf. 

[ ID] Interval   Transfer Bandwidth
[  3]  0.0-10.0 sec   111 MBytes  93.1 Mbits/sec

Tor is entirely another story though, with all its encryption/decryption and
the need to keep track of a few thousands of connections at the same time. I
suppose the "1 MB/sec" figure mentioned was about Tor specifically.

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

Re: [tor-relays] Unwarranted discrimination of relays with dynamic IP

[Roman Mamedov]

On Wed, 7 Dec 2016 00:36:15 +
Duncan Guthrie  wrote:

> My original figure may have been... somewhat off. With different models 
> they may have updated the network hardware.

They did not. All models with Ethernet use the same SMSC LAN9514 chip.

> A more general point is that old desktop computers still offer better 
> performance than a Raspberry Pi. You can easily get one for considerably 
> less than the cost of a Pi

And pay more than the cost of a Pi in electricity.

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

Re: [tor-relays] relays with dynamic IP - here Rasp2

[Roman Mamedov]

On Wed, 7 Dec 2016 11:02:59 +0200
"Rana"  wrote:

> >> Wow nice bandwidth you are pushing through Paul! You mean two Raspi 2's 
> >> sharing an Internet connection, each relaying 27 Gbytes per day at 5.4 
> >> Mbit/s on the average?? Total 10.8 Mbit/s?? Or 2.7 Mbit/s each?
> > 
> > It is just 1 single Rasp2 - running 2 tor instances on 1 IP, details 
> > here 
> > https://gitweb.torproject.org/debian/tor.git/tree/debian/tor-instance-create.8.txt
> 
> Any specific reason you have for running 2 instances of Tor on the same Raspi 
> instead of one?

It has 4 cores, and a single instance of Tor cannot utilize all of them. It
only uses one core and maybe 20-30% at most of another.

Ideally you would run 3-4 Tor instances on a 4-core machine (if RAM allows),
but the maximum allowed by the Tor authority servers is 2 per IPv4.

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

Re: [tor-relays] relays with dynamic IP - here Rasp2

[Roman Mamedov]

On Wed, 7 Dec 2016 11:13:54 +0200
"Rana"  wrote:

> But is it possible to tell Tor on which cores to run? I mean, install a 2nd
> instance of Tor and tell it to run on the two cores not used by the first
> instance?

The Linux kernel will sort it out automatically. Deciding optimally which
programs get to run on which cores is the kernel's job.

It's also possible to pin programs to specific cores using "schedtool", but
that's more of an advanced tuning trick: not something you should need as the
first thing you do, but you could look into that if you get to the point when
both of them use 100% CPU, and you want to micro-optimize things a bit further.

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

Re: [tor-relays] Exploiting firmware

[Roman Mamedov]

On Wed, 7 Dec 2016 22:50:39 +
Alex Haydock  wrote:

> Intel ME/AMT concerns me too, especially how unavoidable it seems to be
> on modern CPUs (AMD is no escape, as they have an equivalent in the form
> of their "Platform Security Processor").

On AMD that's been implemented only after "Family 15h"
https://libreboot.org/faq/#amdbastards
https://en.wikipedia.org/wiki/List_of_AMD_CPU_microarchitectures

Family 15h itself is safe.

It includes FX-series 8-core CPUs at up to 5 GHz supporting DDR3-2133 RAM:
https://en.wikipedia.org/wiki/Piledriver_%28microarchitecture%29

So don't handwave-away AMD with "they are doing that too", today you CAN have
a non-backdoored modern high-performance CPU -- from AMD.

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

Re: [tor-relays] EOMA68 as a platform for trustworthy computing? / was: Exploiting firmware

[Roman Mamedov]

On Thu, 8 Dec 2016 12:11:48 +0100
Christian Pietsch  wrote:

> On Thu, Dec 08, 2016 at 10:41:46AM +0500, Roman Mamedov wrote:
> > On AMD that's been implemented only after "Family 15h"
> > https://libreboot.org/faq/#amdbastards
> > https://en.wikipedia.org/wiki/List_of_AMD_CPU_microarchitectures
> > 
> > Family 15h itself is safe.
> > 
> > It includes FX-series 8-core CPUs at up to 5 GHz supporting DDR3-2133 RAM:
> > https://en.wikipedia.org/wiki/Piledriver_%28microarchitecture%29
> > 
> > So don't handwave-away AMD with "they are doing that too", today you CAN 
> > have
> > a non-backdoored modern high-performance CPU -- from AMD.
> 
> Interesting, but this microarchitecture entered the market in 2012 and
> is probably being phased out now, I guess?

It is still their current desktop/server performance offer today, the next
generation ("AMD Zen", also making the switch to DDR4, and likely adding that
PSP) is planned to be released some time in 2017 and is mostly at the stage of
announcements and rumors right now.

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

Re: [tor-relays] Exploiting firmware

[Roman Mamedov]

On Fri, 9 Dec 2016 04:17:49 -0500
grarpamp  wrote:

> >> Intel ME/AMT concerns me too
> 
> > AMD Family 15h itself is safe.
> 
> No one has any proof of that for any modern cpu from any
> maker, featureset irrelavant.

Sure, to clarify what's meant here is "it does not implement the actual
backdoor-like feature (separate CPU-within-CPU running proprietary code and
having super-user rights over the rest of the system and full access to
everything) in the form of 'Platform Security Processor' or 'Intel Management
Engine'". Point is if you wanted a desktop CPU without such feature, there's an
option available today, and you don't have to go back to Pentium 200 to avoid
it.

> They all accept microcode updates, which btw are all encrypted closed binary
> blobs.

Those are applied by your BIOS or your OS.
https://packages.debian.org/jessie/amd64-microcode
https://packages.debian.org/jessie/intel-microcode
You don't HAVE to install those. It's not like they are auto-downloaded from
the Internet directly by your CPU (at least if your CPU doesn't have those
AMT/PSP things :).

> And the chips themselves are fully closed source containing billions
> of transistors. You simply have no idea what's in there and no way to
> economically and publicly test or negotiate to find out and openly publish
> it all.

Sure there still can be subtle bugs and backdoors, but those will need to be
subtle, well hidden, likely more difficult to exploit, and likely having much
less of a "feature set" when exploited. Not to mention the devastating
reputation effect on the vendor if uncovered.

> Billions of secret transistors... billions.
> Not good, and not necessary.
> 
> #OpenFabs printing #OpenDesigns

As far as I know there's no fully free and open chip right now which provides
performance expected of a modern desktop or server. There is the TALOS
project[1], but for most people it'll be a non-starter due to price. And even
there from what I see you don't get it made on an open fab. So we need to
choose the least evil option from what we have available, and to me the AMD FX
appears to be a win in that regard.

[1]
https://www.crowdsupply.com/raptor-computing-systems/talos-secure-workstation

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

Re: [tor-relays] Tor Relay on ARM server Marvell Armada 370/XP

[Roman Mamedov]

On Tue, 20 Dec 2016 14:24:47 +0100
"Fabio Pietrosanti (naif) - lists"  wrote:

> Hello,
> 
> i'm experimenting Tor setup on very cheap servers from scaleaway.com
> that run a quad-core ARM Marvell Armada 370/XP servers but have
> unlimited bandwidth.
> 
> Those are Soc platform:
> http://natisbad.org/NAS2/refs/Marvell_ARMADA_370_SoC.pdf
> 
> I saw no information on torproject mailing list about those SOC.
> 
> I'm trying to push the limits and i saw that those have a crypto
> acceleration support:
> https://www.kernel.org/doc/Documentation/devicetree/bindings/crypto/marvell-cesa.txt
> 
> However with kernel 4.5.7 it does not really work and loading of
> marvel-cesa gives out error:
> [6.841862] marvell-cesa: probe of d009.crypto failed with error -22
> 
> :(
> 
> 
> I've only built latest Tor 0.2.9 with -O9 -mcpu=marvell-pj4
> -mtune=xscale and the Tor Relay is at
> https://atlas.torproject.org/#details/82C63C5D61D17557B7C5D0E7FDC545A2B6B6B7E0
> .
> 
> Does someone have experienced optimizing and tuning Tor specifically on
> ARM processors to understand how far those could be optimized?

Do you run two Tor instances per machine? On platforms like these (with two
or more cores, but each core being rather weak), you pretty much have to, if
you want good resource utilization. Pin the 1st instance to cores 0,1, the
second one to 2,3 using schedtool for better cache locality, and if you're
already using schedtool, might as well mark the Tor processes as SCHED_BATCH.

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

Re: [tor-relays] Tor Relay on ARM server Marvell Armada 370/XP

[Roman Mamedov]

On Tue, 20 Dec 2016 18:19:06 +0100
niftybunny  wrote:

> Yes, running 12 exits there.
> 
> https://atlas.torproject.org/#details/28F4F392F8F19E3FBDE09616D9DB8143A1E2DDD3
>  
> 
> 
> the atom cpu suxx, install 2 instance, so you get around 100-120 mbit. 

That's OVH, and Scaleway is Online.net.

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

Re: [tor-relays] Report of home relay experience (cont'd)

[Roman Mamedov]

On Tue, 20 Dec 2016 19:12:54 +0100
Petrusko  wrote:

> Haaa extra packages needed to compile from source...
> I don't remember which ones ! If someone here knows ? :s
> 

Try running "apt-get build-dep tor".

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

Re: [tor-relays] TOR Relay performance issue

[Roman Mamedov]

On Sat, 7 Jan 2017 16:55:12 +0100
Thomas Maurice  wrote:

> It is supposed to be caped at 20MBps, and 25MBps burst so I doubt the
> limitation I am observing is enforced by the node itself.

You mean traffic limitation in torrc? Remove it. There is no reason to apply
bandwidth caps unless you want to run other tasks on the same connection, or
it's metered per transfer amounts. If neither is the case, you only tie down
your Tor with pointless housekeeping to track limits (which likely won't be
reached anyways).

As for what to do for better utilization, set up a second instance of Tor.
Tor is poorly multithreaded, and one instance on its own, even with NumCPU
specified, is not able to utilize more than about 1.3 CPU cores.

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

Re: [tor-relays] FW: What's a "useful" mailing list contributor? (was Re: What's a "useful" relay?)

[Roman Mamedov]

On Wed, 11 Jan 2017 07:09:27 +0200
"Rana"  wrote:

> Wow. I offer to maintain a FAQ for small relays and in return I get this. 
> Unsubscribed.

Those were all reasonable requests laid out in a clear and polite fashion.
If you don't want to follow etiquette of a community, never listen and instead
throw a tantrum at the earliest opportunity, I have to wonder how useful any
"FAQ" would have been with a maintainer like that. IMO your decision is a good
one, please don't consider to reverse it.

>  On 3 Jan 2017, at 17:57, Rana   > wrote:
>  
>  @teor
>  I hereby volunteer to maintain a FAQ for operators of small relays (or noob 
> operators). Which means I would be watching this list, generating the Q&A and 
> from time to time alerting this list to the appearance of new questions and 
> answers, to allow knowledgeable people to do quality control. And/or inviting 
> people to convert their answers on this list  to the FAQ answers. This would 
> relieve them from answering the same question over and over again and reduce 
> the influx of questions from noobs (like myself J). I believe this would also 
> strengthen the community and reduce the frustration of small relay operators  
> and – who knows? – even lead to advancements in Tor design to make better use 
> of them.
> 
> I would appreciate that, but please learn some mailing list etiquette
> first. Otherwise, your contributions may be ignored by many people on
> the list.
> 
> Some examples:
> * make sure each email adds something valuable to the conversation
> * structure your emails well:
>   * learn how to bottom-post, even if your email client doesn't support
> it
>   * learn how to quote others' emails to provide context to your
> response
> * try to write succinctly
> * keep the volume of your emails down:
>   * write one response to a thread each day
>   * search for similar threads before starting a new one
>   * wait until an active thread is finished before starting a new one
>  Caveat: I need someone (Tor project people) to create the Wiki on the site 
> and let me admin it.
> 
> Demonstrate you can do the things above, and I'll gladly set this up
> for you.
> 
> 
> 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
> 
>   _  
> 
> 
> 
> 
> 


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

Re: [tor-relays] Network is unreachable?

[Roman Mamedov]

On Tue, 24 Jan 2017 03:40:05 +
John Ricketts  wrote:

> It is entirely possible this is a result of the HE vs Cogent feud, big break 
> in the IPv6 routing tables as a cogent is refusing to peer with HE.  Not sure 
> where they are in that negotiation...

Any basis for that in this case?
Other than "a random thing I remember about IPv6, so I'll mention it
regardless of whether relevant, to further confuse the discussion".
According to http://bgp.he.net/AS54290#_graph6 AS54290 Hostwinds is
connected both to Cogent and HE.net, so this shouldn't be the issue here.

> > On Jan 23, 2017, at 21:38, teor  wrote:
> > 
> > 
> >> On 24 Jan 2017, at 14:31, niftybunny  wrote:
> >> 
> >>  inet6 addr: 2607:5500:2000:5d3::de95/64 Scope:Global
> >>  UP BROADCAST POINTOPOINT RUNNING NOARP  MTU:1500  Metric:1
> >>  RX packets:3169513589 errors:0 dropped:0 overruns:0 frame:0
> >>  TX packets:3438384506 errors:0 dropped:0 overruns:0 carrier:0
> >>  collisions:0 txqueuelen:0
> >>  RX bytes:2825471195234 (2.5 TiB)  TX bytes:2911672053962 (2.6 TiB)
> >> 
> >> looks like a IPv6 to me. Will contact Hostwinds anyway, I hate them with 
> >> every cell of my body.
> > 
> > $ wget dist.torproject.org
> > --2017-01-24 03:34:08--  http://dist.torproject.org/
> > Resolving dist.torproject.org (dist.torproject.org)... 
> > 2001:41b8:202:deb:213:21ff:fe20:1426, 2620:0:6b0:b:1a1a:0:26e5:4810, 
> > 2a01:4f8:172:1b46:0:abba:5:1, ...
> > Connecting to dist.torproject.org 
> > (dist.torproject.org)|2001:41b8:202:deb:213:21ff:fe20:1426|:80... connected.
> > HTTP request sent, awaiting response... 302 Found
> > ...
> > 
> > dist.torproject.org works over IPv6 via a US Hurricane Electric tunnel,
> > and from OVH in France and Canada, so I'd check with your provider.
> > 
> > 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
> > 
> > 
> > 
> > 
> > ___
> > 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


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

Re: [tor-relays] why my exit is not being used?

[Roman Mamedov]

On Mon, 30 Jan 2017 15:12:46 +1100
teor  wrote:

> Your relay also does not seem capable of handling much tor traffic, so
> tor clients are being told not to use it:

That's the usual problem of relays in Asia (Singapore in this case), with all
the bandwidth measuring authority servers being too far away from there.


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

Re: [tor-relays] why my exit is not being used?

[Roman Mamedov]

On Mon, 30 Jan 2017 23:46:31 +0800
"gustavo panizzo (gfa)"  wrote:

> Would make sense then to run another tor instance in the same server? 

It nearly always does (unless on just a single very slow CPU core), so yes.

Although you might start running out of RAM if you run that on a 512 MB droplet.

> a non-exit relay.

Doesn't matter, if the first one is exit, the 2nd one can be an exit too.

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

Re: [tor-relays] New Relay Operator: Hostname

[Roman Mamedov]

On Mon, 20 Feb 2017 21:16:38 -0800
co...@awakening.io wrote:

> I would like the hostname to be public, I wonder if I have misconfigured
> as the hostname does not display here:
> 
> https://torstatus.blutmagie.de/router_detail.php?FP=b0a8f23372309d3589e70bd3c2e48c5b6fc3ec36
> 
> I have the following in my configuration:
> 
> ORPort 198.100.159.72:9000
> DirPort 198.100.159.72:9001
> Address tor-exit-01.awakening.io
> 
> Any thoughts?

The hostname is taken from reverse DNS (aka PTR record) of the IP address, but
in your case:

$ host 198.100.159.72
Host 72.159.100.198.in-addr.arpa. not found: 3(NXDOMAIN)

The owner of that IP address has to set the reverse DNS record, or in your
case, it's likely you can set that yourself via a function in your hoster's
(OVH) control panel.

In any case, you don't need the "Address" line with hostname in torrc.

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

Re: [tor-relays] What kind of hardware do I need for my relay

[Roman Mamedov]

On Mon, 20 Mar 2017 21:03:57 +
Farid Joubbi  wrote:

> Intel NUC5CPYH Celeron N3050 1,6 GHz to 2,16 burst -> 5 Mbit/s max (OpenBSD)

This sounds wrong. VIA Nano 1.6GHz, a single core laptop CPU from 2011, can
sustain about 40+40 Mbit (WITHOUT utilizing the crypto acceleration).

The Celeron N3050 has two cores and supports AES-NI, and if OpenBSD seriously
doesn't (which I doubt), then swap out OpenBSD.

With two cores you could also run 2 instances of Tor for more efficient CPU
use. I would expect both cores stay at sub-50% CPU use while the entire thing
is capping out into the full 100+100 Mbit.

That said, when did you measure the speed, and are you aware of
https://blog.torproject.org/blog/lifecycle-of-a-new-relay ?

Another possibility, maybe your ISP only provides "up to 100 Mbit" and is
shaping certain types, patterns or amounts of traffic use.

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

Re: [tor-relays] Tor version on Debian Wheezy (oldstable)

[Roman Mamedov]

On Wed, 17 May 2017 11:32:39 -0400
Matt Traudt  wrote:

> You could tell Debian to get Tor from torproject.org
> 
> https://www.torproject.org/docs/debian.html.en
> 
> You'd probably tell it you use old stable and want Tor version stable. 
> After a couple of apt commands, I predict you will end up with Tor 0.3.0.7

No he will not, as nobody cares to update the Tor stable repository for
0.3.0.7, all you get on stable is 0.2.9.10.

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

Re: [tor-relays] Tor version on Debian Wheezy (oldstable)

[Roman Mamedov]

On Wed, 17 May 2017 18:36:12 -0400
Roger Dingledine  wrote:

> My guess is that our fine debian maintainer is leaving it at 0.2.9.10
> while Stretch finishes its freeze and goes stable:
> https://wiki.debian.org/DebianStretch

I don't mean packages in the Debian official repo, but those at 
deb.torproject.org.
Surely those shouldn't have any dependence on Debian freeze/stable cycles.

> Tor 0.2.9.x is our most recent long-term-stable release:
> https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/CoreTorReleases#Listofreleases
> 
> So it is wiser to have 0.2.9 in the next Debian stable, rather than
> using 0.3.0 and then having Tor want to abandon 0.3.0 well before
> Stretch's expected lifetime.


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

Re: [tor-relays] Memory Problems with tor releay - restart tor automatically after failure

[Roman Mamedov]

On Thu, 25 May 2017 08:54:00 +
nusenu  wrote:

> I noticed your comment [1] about your plans to write a script that
> restarts tor should it get killed.
> 
> I just wanted to let you know that if you have plans to upgrade to
> Ubuntu 16.04 you will get this out of the box due to systemd Restart=
> [2] service configuration.
> 
> [1] https://trac.torproject.org/projects/tor/ticket/22255#comment:23
> [2]
> https://gitweb.torproject.org/debian/tor.git/tree/debian/systemd/tor@.service#n20
> https://www.freedesktop.org/software/systemd/man/systemd.service.html#Restart=

Or you can just put

   /etc/init.d/tor start | grep -v "already running"

into your crontab at every 5 minutes or similar. If Tor is already running,
this will not do anything, i.e. won't launch a duplicate or anything of that
sort. And in case it crashed, you will get an E-Mail automatically (assuming
you set up your crontab MAILTO= and system's MTA properly) telling you that it
has been started (again), letting you to keep assessing frequency of the issue.

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

Re: [tor-relays] [SOLVED] published descriptor missing from consensus

[Roman Mamedov]

On Thu, 08 Jun 2017 09:43:00 -0500
Scott Bennett  wrote:

>  As noted more than once previously, the pf rules *pass* all traffic
> from relay addresses *first*, so that traffic has already gone on to tor
> before the block list is applied.

There are most likely some relays which use a different IP for outgoing
connections than what is listed in the consensus, due to multiple IPs or
provider multihoming. Your scheme does not seem to account for that, so those
connections may fail. In effect you will be leaving the Tor network
permanently semi-broken by running a relay while employing such filtering.

In any case I don't think there is any reasonable threat scenario against which
you must protect by not just allowing all connections from anywhere to
ORPort/DirPort of a Tor relay.

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

Re: [tor-relays] sharing tor relay at night or working hours ? make sense ?

[Roman Mamedov]

On Sun, 11 Jun 2017 09:00:48 -0700
Zalezny Niezalezny  wrote:

> I thought about it, the best solution for me will be to change Bandwith
> settings during working hours using crontab.
> 
> I will prepare two separate configuration files with different Bandwidth
> settings and using it, two times per day cronjob will increase/decrease
> bandwith for TOR.
> This should be the best solution in that case.
> 
> 
> ok , if I will replace configuration file with the new settings, do I need
> to reload or restart my tor node ?
> I do not want to loose my active connections. How to do it properly ?

Yes this can work. A tor reload is enough to apply the new bandwidth settings.

Not sure how fast you will ramp up during the night though (if at all), e.g.
if the bandwidth authorities measure your relay during the day and get a very
low number.

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

Re: [tor-relays] Want to help test 'Sandbox 1'? (Linux only)

[Roman Mamedov]

On Sun, 25 Jun 2017 18:25:00 +
nusenu  wrote:

> I'm aiming to enable tor's 'Sandbox' feature by default on Debian based
> relays starting with the next release of ansible-relayor [1].
> 
> Before doing so I'd like to collect some feedback from tor relay
> operators willing to test this feature.
> 
> If you
> - run tor 0.3.0.x >= 0.3.0.8
> - are on Linux
> - willing to report proplems
> 
> it would be greate if you could add the following line to your torrc
> configuration file:
> 
> Sandbox 1
> 
> 
> Ideally you have also a system monitoring in place that tells you
> whether this config change has any impact (i.e. on CPU or bandwidth).

FWIW I haven't noticed any impact, bad or good, after enabling this on a
couple of relays since the date you asked.

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

Re: [tor-relays] Load balancing (with IPVS) multiple Tor daemons

[Roman Mamedov]

On Sat, 8 Jul 2017 09:54:20 +1000
teor  wrote:

> Tor uses multithreaded crypto already: depending on the speed of your
> processor, you can get up to 400 Mbps per instance (250 Mbps is
> typical).

In practice I don't remember seeing much more than 120-130% CPU use per
process, and even that, only in brief peaks. Maybe crypto is not actually the
bottleneck, but some other non-parallel operation instead.

Speaking of CPU use, is there any roadmap to phase out TAP mode circuits? IIRC
those are very CPU-expensive compared to NTor. Even though now TAP counts are
only 10-20% compared to NTor, could it be that those are actually responsible
for something like 50%+ of total CPU usage.

> You can also get a second IPv4 address, and run 2 Tor daemons on that
> IP address as well.

This is not always feasible and carries additional expense even if it is.

Another idea that I proposed some time ago is raising the relay-per-IP limit
from 2 to 4. There are almost no 1 or 2-core CPUs anymore, and 4-core CPUs (for
4 Tor processes) are extremely common. Especially considering the ARM
architecture, where it's really common now to see 4-core CPUs, with each core
being relatively weak on its own.

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

Re: [tor-relays] 100K circuit request per minute for hours killed my relay

[Roman Mamedov]

On Fri, 21 Jul 2017 10:24:39 +0100
Pascal Terjan  wrote:

> Last night for 4h30 (until VPS provider shut it down) one of my middle
> relays seems to have got in a bad state where it was using 100% CPU
> continuously
> 
> It was not using much bandwidth, about 4MB/s, but reading the logs it
> seems it was getting a lot of circuit requests (70K/minute initially,
> 100K at the end). Is there anything I can do about it?

Your message prompted me to check logs, and on one relay I see the following:

Jul 19 03:26:03.000 [notice] Circuit handshake stats since last time: 4242/4242 
TAP, 65583/65583 NTor.
Jul 19 09:26:03.000 [notice] Circuit handshake stats since last time: 4897/4897 
TAP, 60996/60996 NTor.
Jul 19 15:26:03.000 [notice] Circuit handshake stats since last time: 3682/3682 
TAP, 1759242/1759519 NTor.
Jul 19 21:26:04.000 [notice] Circuit handshake stats since last time: 3762/3762 
TAP, 5946906/5947506 NTor.
Jul 20 03:26:04.000 [notice] Circuit handshake stats since last time: 1676/1676 
TAP, 6794460/6795903 NTor.
Jul 20 09:26:04.000 [notice] Circuit handshake stats since last time: 4432/4433 
TAP, 6991546/6993275 NTor.
Jul 20 15:26:04.000 [notice] Circuit handshake stats since last time: 7649/7650 
TAP, 1437786/1437748 NTor.
Jul 20 21:26:04.000 [notice] Circuit handshake stats since last time: 7484/7484 
TAP, 68388/68388 NTor.
Jul 21 03:26:04.000 [notice] Circuit handshake stats since last time: 6105/6105 
TAP, 52027/52027 NTor.
Jul 21 09:26:04.000 [notice] Circuit handshake stats since last time: 5210/5210 
TAP, 99365/99365 NTor.

That one has not been shut down (the VPS provider does not seem to have any
issue with allowing high CPU usage) and works normally after that.

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

Re: [tor-relays] PSA: Run a Tor node, lose access to Chinese IPs

[Roman Mamedov]

On Sun, 23 Jul 2017 17:13:04 +
n...@neelc.org wrote:

> Today, I wanted to try to see how the Internet looks behind the Great 
> Firewall of China. I used a public HTTP proxy list 
> (http://spys.ru/free-proxy-list/CN/) listing Chinese proxy servers (meaning 
> getting into Chinese censorship from the US, not bypassing it in China), and 
> guess what? I was already blocked. Why? I suspect that I was running a Tor 
> relay from my home connection 
> (https://atlas.torproject.org/#details/A20840A16CB658024B0D3A0E3F19A9C0E34C843F).
>  
> 
>   Some Chinese websites do load, but many of those who do usually have a 
> CDN outside the Chinese firewall. For example, I can visit AliExpress from my 
> home computer without Tor, but I can't visit 163.com or 2345.com. 

I can confirm it with 163.com and 2345.com, inaccessible from 3 current Tor
relays, and accessible from 3 non-Tor hosts.

Also if a host has been running Tor in the past, but doesn't anymore, it
appears to regain access to those Chinese sites, i.e. the blocking is not
permanent, the list of Tor nodes is rechecked periodically and those IPs which
are no longer in it get removed from the block list.

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

Re: [tor-relays] ORSN DNS servers vs OpenNic

[Roman Mamedov]

On Fri, 4 Aug 2017 16:18:23 +0200
niftybunny  wrote:

> I use:
> 
> nameserver 204.152.184.76
> nameserver 194.150.168.168
> nameserver 213.73.91.35
> nameserver 8.8.8.8
> 
> works fine. Google as gateway of last resort :)

A common gotcha, only the first three will be used, the rest are apparently
ignored. `man resolv.conf`:

  Up  to  MAXNS  (currently 3, see ) name servers may be
  listed, one per keyword.

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

Re: [tor-relays] HOW-TO: Simple DNS resolver for tor exit operators

[Roman Mamedov]

On Sun, 6 Aug 2017 16:03:53 -0400
"Dennis Emory Hannon"  wrote:

> I decided to make a quick starter guide to introduce using a local resolver
> for tor-exit node operators. I'd like to solicit some of your feedback on
> things that should be added or improved upon. Hopefully this will be a
> living document - My goal is to help lower the amount of TOR exit relays
> using 3rd party DNS providers for client DNS lookups. While it doesn't
> address all security concerns, it's a necessary step to improving anonymity
> of TOR's users. Let me know what you think.
> 
> Guide is meant for debian/linux users
> http://backplanedns.org/TOR_exit_dns_resolver_howto.htm

> ...
> in the clearweb are being probably being logged. In this simple tutorial
> ...

Your tutorial is in the clearweb itself, and probably not only being logged,
but also can be MITMed to include all sorts of malicious instructions and/or
rewrite the recommended third party resolver IPs to an attacker-controlled
ones.

Why not use HTTPS for the website? Doubly weird that you want to educate
others on security topics, and then don't follow the best practices yourself.

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

Re: [tor-relays] Tor exit nodes attacking SSH?

[Roman Mamedov]

On Tue, 8 Aug 2017 18:51:51 -1100
Mirimir  wrote:

> On 08/08/2017 01:48 PM, Steven Chamberlain wrote:
> > Hi,
> > 
> > I often run my SSH sessions via Tor using tsocks.  But today I see:
> > 
> > @@@
> > @WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
> > @@@
> > IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
> > Someone could be eavesdropping on you right now (man-in-the-middle
> > attack)!
> > It is also possible that a host key has just been changed.
> > The fingerprint for the RSA key sent by the remote host is
> > e7:0e:73:a5:88:23:67:9c:01:87:3c:61:96:f6:e8:0a.
> 
> I've seen that happen with Digital Ocean droplets. And when I've
> checked, I've found that the host key had, in fact, changed. Did you
> check for that?
> 
> > The authenticity of host '8.8.8.8 (8.8.8.8)' can't be established.
> > RSA key fingerprint is e7:0e:73:a5:88:23:67:9c:01:87:3c:61:96:f6:e8:0a.
> > Are you sure you want to continue connecting (yes/no)? :
> 
> That's not even a host key change. It's just that you don't yet have the
> host key.
> 
> > I could be wrong, but I think this "dropbear" service is most likely
> > something malicious, running on one or more Tor exit nodes, attempting
> > to collect passwords of people logging in this way.
> 
> No, dropbear is an SSH server that 8.8.8.8 seems to be running.

Did you try ssh'ing into 8.8.8.8 (outside of Tor)? It does not run a public
SSH server at all (obviously).

The point was to demonstrate that the exit node intercepts port 22 connections
to any IP, and redirects them to the same particular instance of dropbear.
Note how in both cases it's the same key fingerprint of
e7:0e:73:a5:88:23:67:9c:01:87:3c:61:96:f6:e8:0a.

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

Re: [tor-relays] Tor exit nodes attacking SSH?

[Roman Mamedov]

On Wed, 9 Aug 2017 21:08:30 +0100
Alexander Nasonov  wrote:

> m...@eugenemolotov.ru wrote:
> > Make a "trap" ssh server (for example on virtualbox machine
> > without any sensitive data) and log in into it through tsocks.
> > After that check from which ip it was logged in. This probably
> > would be ip of the exit node.
> 
> What if they "bridge" mitm-ed traffic to a different host?

They could feed MITMed traffic back into Tor, framing a different exit node
in the process :)

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

[tor-relays] Force OpenSSL AES-NI usage on a VPS without the AES CPU flag passthrough

[Roman Mamedov]

Hello,

Today I found that it is possible to force OpenSSL enable the use of CPU AES
acceleration even if it doesn't detect the "aes" CPU flag.

Many VPS hosts configure their hypervisors in a way that does not have the
flag passed through into VPSes, even though all their host nodes surely have
CPUs with support for AES-NI. In my experience hosts have not been forthcoming
in reconfiguring their systems to include that flag passthrough.

But it turns out we can force OpenSSL to believe AES is supported, even
if the CPU does not report it. This can be done with the "OPENSSL_ia32cap"
environment variable. Searching around, all I found was scenarios to use it for
disabling AES-NI (for testing), e.g.: 

  https://mjanja.ch/2013/11/disabling-aes-ni-on-linux-openssl/

I believe the syntax used there applies "xor" over the real flag values, e.g.
OPENSSL_ia32cap="~0x202" to disable AES. But what if you need to
force-enable it. Turns out the syntax working for that is simply:

  OPENSSL_ia32cap="+0x202"

Let's take one VPS box with the aforementioned problem. 

# cat /proc/cpuinfo 
processor   : 0
vendor_id   : GenuineIntel
cpu family  : 6
model   : 13
model name  : QEMU Virtual CPU version 1.5.3
stepping: 3
microcode   : 0x1
cpu MHz : 1695.729
cache size  : 4096 KB
physical id : 0
siblings: 1
core id : 0
cpu cores   : 1
apicid  : 0
initial apicid  : 0
fpu : yes
fpu_exception   : yes
cpuid level : 4
wp  : yes
flags   : fpu de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov 
pse36 clflush mmx fxsr sse sse2 syscall nx lm rep_good nopl eagerfpu pni cx16 
hypervisor lahf_lm
bugs:
bogomips: 3391.45
clflush size: 64
cache_alignment : 64
address sizes   : 46 bits physical, 48 bits virtual
power management:

As you can see "aes" is not present.

Testing OpenSSL speed in the default configuration.

# openssl speed -elapsed -evp aes-128-gcm
...
type 16 bytes 64 bytes256 bytes   1024 bytes   8192 bytes  
16384 bytes
aes-128-gcm  32332.17k40365.80k42265.77k42376.19k  43196.42k
43401.22k

And now we force AES hardware acceleration usage:

# OPENSSL_ia32cap="+0x202" openssl speed -elapsed -evp aes-128-gcm
...
type 16 bytes 64 bytes256 bytes   1024 bytes   8192 bytes  
16384 bytes
aes-128-gcm  59047.07k   104467.39k   141712.21k   151093.93k   158321.32k  
 156827.65k

Almost 4 times faster! For Tor this leads to higher bandwidth utilization and 
lower CPU usage
(which will actually make your VPS host happier :)

But how to apply that to Tor? Well, for some initial testing I just chose to 
add the following
line to /etc/init.d/tor (not using systemd here), right after "#! /bin/bash":

  export OPENSSL_ia32cap="+0x202"

(but this will get overwritten and removed by the next Tor version upgrade).

Seems to work just fine, my CPU usage is half of what it was before, at similar 
bandwidth levels.
So now it has headroom to ramp up further.

A word of caution, firstly always test as shown above to verify that it works.

I believe if the underlying CPU actually doesn't support AES, all programs 
trying to use it,
including "openssl speed", will crash outright, with an incorrect instruction 
error, or somesuch.

So there is no risk to jeopardize encryption strength or security of Tor.

Also even if it works now, it may stop working down the line if the host 
migrates your VPS to
a node with older CPU, one which doesn't support AES. But migrations of 
customers between do not
happen very often, and in fact all CPUs used today in a hosting environment 
should support
AES, as that's been implemented in server (and even desktop) CPUs a very very 
long time ago.

(Apologies for double-post, I realized tor-relays should have been the better 
place to post).

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

Re: [tor-relays] Any IP allocations available out there?

[Roman Mamedov]

On Thu, 24 Aug 2017 01:30:13 + (UTC)
Paul Templeton  wrote:

> At the moment there are 50 nodes in Australia with the fastest running at
> 357Kbs and only two exit nodes - fastest is 100Kbs. Its a reflection on the
> state of politics and the level of service that is provided by ISP's. 

I feel this can be in part a reflection of Tor's particular bandwidth
measurement method, as teor has mentioned in a previous reply.

And in any case, with Tor's overall architecture, does it really make sense to
route e.g. EU clients exiting to EU destinations, via Tor circuits going
through Australian nodes and back. I guess this is still an area open for
further research and optimization.

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

Re: [tor-relays] HOW-TO: Simple DNS resolver for tor exit operators

[Roman Mamedov]

On Tue, 12 Sep 2017 13:43:35 -0700
"Igor Mitrofanov"  wrote:

> Alternatively, the Tor community could run our own DNS servers, and every 
> exit node would use those by default.

On Tue, 12 Sep 2017 22:11:23 +0200 (CEST)
jpmvtd...@laposte.net wrote:

> from the owner of the DNS server.

THE owner of THE dns server. Right.

Too bad DNS servers are not something a regular person can own, so we have to
be at mercy of those shady all-knowing uber-powerful Owners of the DNS Servers.

Lacking that, there must be a Community which gathers together to Run One.

Oh wait, we need none of that, and running a resolver which answers to no one
and can only be tracked via traffic monitoring (i.e. if they do that, you're
f*cked anyway) is just an "apt-get install unbound" away.

Are you sure you understand how Internet architecture works, before proposing
"solutions".

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

Re: [tor-relays] HOW-TO: Simple DNS resolver for tor exit operators

[Roman Mamedov]

On Tue, 12 Sep 2017 23:28:35 +0200
Ralph Seichter  wrote:

> On 12.09.17 23:06, Roman Mamedov wrote:
> 
> > Too bad DNS servers are not something a regular person can own, so we
> > have to be at mercy of those shady all-knowing uber-powerful Owners
> > of the DNS Servers.
> 
> I take it you're being ironic?

Guess I failed at doing that well, if you had to clarify. (Or maybe you didn't
read my entire message.)

> One might say that the more people run their own nameservers, the harder
> it gets for attackers to gather data or interfere with the DNS system.

Running your own authoritative nameservers is laudable as well, but the
current discussion is about recursive resolvers. You know, the likes of
8.8.8.8 and the ones your ISP runs for their clients "to reduce traffic".

Point is that it is entirely possible, and really easy, to just have your own
instance of that. It will not use any fixed "upstream server" other than the
root nameservers (and those, only to ask generic depersonalized stuff such as
"who handles the .com zone").

Note that 'dnsmasq' won't do, that's just a caching proxy to a fixed set of
a few upstream DNS resolvers; you need 'unbound' which IS a full independent
DNS resolver itself.

(Unbound is caching as well, though).

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

Re: [tor-relays] About relay size

[Roman Mamedov]

On Tue, 3 Oct 2017 09:53:46 -0400
teor  wrote:

> > For interposing dual-protocoled nodes along the way, how many do there
> > have to be for it to become "not too limiting"?
> 
> This is one of the questions we need researchers to answer.

I can't help but feel you are overcomplicating this.

Clients create a circuit by randomly picking 3 nodes out of the all-nodes
pile, right? If all 3 happen to be IPv6-capable, then the circuit can go over
IPv6 and all is fine. If some of the 3 happen to be IPv6-only while others are
IPv4-only, the whole selection can be thrown away and repeated.

That way IPv6-only relays could get some usage on a totally random basis, with
no compromises and no restraining "of the next hop based on the previous one",
not hurting anonymity. Clients just need to know which nodes are IPv4-only,
IPv6-only or dual-stack, to not attempt unworkable combinations, discarding
them instead.

And as there are more and more dual-stack or IPv6-only relays, the "throw
away" step will be needed less and less often.

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

Re: [tor-relays] Just got my first Abuse email :-)

[Roman Mamedov]

On Wed, 11 Oct 2017 09:38:22 + (UTC)
Paul Templeton  wrote:

> It makes me happy but alas it was forwarded to me by the provider and didn't 
> include an email address... so now I can not reply, SIGH

I believe in such case you are supposed to reply to your provider, usually to
indicate that the problem the abuse report relates to "has been dealt with" and
will not repeat. In case of a Tor Exit you cannot guarantee that, aside from
removing port 22 from your exit policy.

> Question: this has come from port 22 usage - how important is this port to 
> the general population? Thoughts...

There was a mini discussion recently on that, with the general consensus
seeming to be that keeping it open is more trouble than it's worth.
https://lists.torproject.org/pipermail/tor-relays/2017-October/013188.html

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

Re: [tor-relays] spurios warning about using the nickname instead of the key

[Roman Mamedov]

On Thu, 12 Oct 2017 21:01:55 +0100 (BST)
Dylan Issa  wrote:

> Maybe they're truncated, but they still need to start with a $

If you would just read the manual page, you would gather that $ is optional.
> 
> On 12 October 2017 at 20:09 Sebastian Hahn  wrote:
> 
> Hi there,
> 
> On 12. Oct 2017, at 20:43, Scott Bennett  wrote:
> teor  wrote:
> 
> On 12 Oct 2017, at 13:21, Toralf F?rster  wrote:
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> On 10/11/2017 10:08 AM, Dylan Issa wrote:
> Did you set MyFamily using nicknames of the key?
> Because if nickname, change it to key is basically what it?s saying.
> 
> No,
> 
> both Tor processes share this common config file:
> 
> grep -i famil /etc/tor/torrc*/*
> 
> /etc/tor/torrc.d/00_common:MyFamily 
> 1AF72E8906E6C49481A791A6F8F84F8DFEBBB2BA,6EABEBF38CE7E3DF672C4DB01383606FE3EB2215
> 
> Doessn't each fingerprint need to start with a $ character? Otherwise
> it's just a really long nickname, right?
> 
> No; nicknames are at most 20 characters long.
> 
> Cheers
> Sebastian
> 
> ___
> tor-relays mailing list
> tor-relays@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays


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

[tor-relays] PSA: exclude /var/lib/tor/diff-cache/ from your backups

[Roman Mamedov]

Hello,

Turns out that dir is highly variable, and judging from the name, also
disposable.

In my case it was responsible for about 20 GB of churn over a month, i.e. it
took 25 GB to keep incremental backups of two Tor nodes with only 2 GB each in
root FS (and I was wondering what's going on with my backup location's free
space...)

Dear Tor project: this is very bad style to keep that in /var/lib, content
with properties like this must go into /var/cache/ [1], where it would be
automatically excluded from backups by default policies in most backup systems.

[1] http://www.pathname.com/fhs/pub/fhs-2.3.html#VARCACHEAPPLICATIONCACHEDATA

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

Re: [tor-relays] [metrics-team] Atlas is now Relay Search!

[Roman Mamedov]

On Tue, 14 Nov 2017 13:22:00 +
nusenu  wrote:

> > Quick question for you. Atlas used to have the search box at all time in the
> > corner which for me was very useful because I could do many search without 
> > an
> > extra click
> 
> +1

Here's another variation on the Atlas theme that I found some time ago:
https://onionite.now.sh/
it still has the search box.

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

Re: [tor-relays] my IP got blocked

[Roman Mamedov]

On Tue, 14 Nov 2017 14:45:44 +
Nagaev Boris  wrote:

> dnsbl.info used to provide two tor-related lists: (1) all nodes and (2) exits.
> Some webmasters could use the first one by mistake.

https://www.dan.me.uk/dnsbl still does, and some webmasters do use the first
one.

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

Re: [tor-relays] DigitalOcean bandwidth billing changes

[Roman Mamedov]

On Wed, 25 Apr 2018 18:53:56 +0300
pikami  wrote:

> Does anyone know where I should move my relay?
> I can't afford to spend a lot of money, I can only do 5$ a month.

There's not a lot of hosts with cheap unmetered bandwidth -- OVH and
Online.net come to mind -- and the majority of them is already heavily used
for Tor (so it's not advised to add more).

Consider switching your relay to a bridge instead, those consume little
bandwidth and can even be run at home (if your connection is stable enough).

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

Re: [tor-relays] Info about Provider Scaleway and cheap "ARM server"

[Roman Mamedov]

On Wed, 02 May 2018 04:20:57 -0400
Artur Pedziwilk  wrote:

> > https://www.scaleway.com/baremetal-cloud-servers/
> >
> > My order was "C1 - A true metal ARM server running in the cloud."
> >
> > "4 Dedicated ARM Cores, 2GB Memory, 50GB SSD Disk / 200Mbit/s unmetered
> > bandwith"
> 
> I think you are mistaken. As far as I know they use Cavium ThunderX 
> processors.
> https://www.cavium.com/product-thunderx-arm-processors.html

They have a range of ARM64-based VPS, those indeed use Cavium ThunderX.

But they also provide ARM dedicated servers (with shared network-based storage)
https://www.cnx-software.com/2015/09/02/scaleway-c1-dedicated-arm-server-price-drops-to-3-euros-per-month/
Those use 32-bit Marvell Armada SoC, have much lower performance than Cavium
and AFAIK are considered a legacy offer to be phased out over time. (They did
not receive IPv6 support when the rest of the plans got it deployed, for
example).

> Can you share more details what make you thinking you are on Raspberry Pi?

This is certainly not a Raspberry Pi, and overheating concerns are unfounded;
before providing this as a commercial service to the general public, I'm sure
they figured out ways to provide sufficient cooling so it can be used 24x7 no
matter what's the CPU load.

But in any case, Online.net is already heavily utilized for Tor relays and
exits, so can't be considered the best choice to add another one at.

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

Re: [tor-relays] Fwd: Tor Guard Relay

[Roman Mamedov]

On Fri, 8 Jun 2018 18:18:19 -1100
Mirimir  wrote:

> Just save that as a text file, and send it to me as an attachment.
> 
> Why the bloody hell someone would target users of this list in that way
> is bizarre. And why you? Rather than me, who is admittedly an outspoken
> jerk sometimes ;)

I got one too, when posting here quite some time ago (1 year+).

It was very bizarre so my prime guess was they might be targeting some buffer
overflow vulnerability in libjpeg (or some other OS' JPEG parser) such as [1]
with those pictures.

Since we have a couple of those posted publicly, if anyone has free time and
related experience, you could check if that's the case here.

[1]https://www.cvedetails.com/cve/CVE-2004-0200/

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

[tor-relays] No IPv6 bridges from bridges.torproject.org

[Roman Mamedov]

Hello,

If you select "Do you need IPv6 addresses - Yes", it always results in an
error "There aren't any bridges available". No matter if choosing obfs4 or
none for the pluggable transport. Is that thing working?

There should be at least one available (with obfs4, too), or at least I was
under impression that I run one.

As a side note, that page always loads in my native language with no way to
switch to English -- pages which do this are the worst. In this case it means
I can't usefully copy-paste you the exact error messages that I get.

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

Re: [tor-relays] Problem implementing IPv6 and NYX info

[Roman Mamedov]

Hello,

In /etc/network/interfaces you set your IP to

>      address 2a06:1700:0:1b::

which is equivalent of 2a06:1700:0:1b:0:0:0:0, or also 2a06:1700:0:1b::0.

But then in torrc you use:

>      ORPort [2a06:1700:0:1b::1]:9001

From your configs, this is your upstream gateway IP, not IP of your actual
machine. So this configuration is incorrect.

Also generally it is adviced against using the all-zeroes IP (which you
chose), it has some special properties and some software may not support it
properly.

Assuming the entire /64 is assigned to you by the host and the gateway
is ..::1 in it, it's a fine idea to use ..::2, or just whatever IP other than
the ..::0.

Finally though, neither your gateway nor your machine at its present IP seem to
be reachable from the Internet at the moment. Verify that IPv6 works properly
with ping/trace/curl/wget before trying to use it with more complex apps such
as Tor.

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

Re: [tor-relays] [Software Announcement] FamilyGenerator: Tor MyFamily Generator

[Roman Mamedov]

On Sat, 21 Jul 2018 20:29:17 -0400
Neel Chauhan  wrote:

> Hi tor-relays mailing list,
> 
> I have created a tool called FamilyGenerator. FamilyGenerator is a tool 
> to automatically construct a Tor MyFamily line based on Onionoo 
> parameters.

If you blindly trust fingerprints fetched "from the Internet" and insert them
into your MyFamily string, then you might as well just use nicknames there.
Actually this is what I do, and while it does have the same downside as your
tool ("what if someone uses the same nickname"), at least it's much simpler,
human-readable in torrc, and not requiring any extra scripts.

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

Re: [tor-relays] Non-exit abuse reports

[Roman Mamedov]

On Sat, 17 May 2014 10:27:39 +0200
dope457  wrote:

> Hello,
> 
> I have been running middle relay on my VPS since it was too much trouble 
> to operate an exit. But ever since I have received two abuse reports 
> regarding same issue.
> 
> 1) Source: 31.31.78.141
> Event type: DNSANOMALY
> Detail:  High amount of TCP DNS traffic, whole transfer: 12 503 B
> Timestamp:
> 2014-05-14
> 20:20:35
> NetFlow source: localhost
> Targets: 178.238.223.67

This relay:
http://torstatus.blutmagie.de/router_detail.php?FP=44efaf942314f756fc7ea50292d5b383e568a9bd
runs with their ORPort set to 53, which is more commonly used for the TCP
variant of DNS. So your ordinary communication with them as a part of Tor
relaying is misdetected by your ISP as malicious DNS attack.

You options are:

1) Explaining the above (along with some explanation about Tor network in
general) to your provider;

2) mailing to the contact E-Mail of the above relay, asking them to change
their port (but then there may be more relays doing the same in the future);

3) blocking outgoing communication to TCP port 53 to all IPs which are not
your chosen recusive DNS servers (set in /etc/resolv.conf); but this will
partially break the Tor network, as part of the circuits which clients try to
establish via your node will now fail (if they happen to include such ORPort
53 nodes).

-- 
With respect,
Roman


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

Re: [tor-relays] relay not receiving very much traffic

[Roman Mamedov]

On Sun, 18 May 2014 18:59:28 +0200
Markus Klock  wrote:

> Hello!I deployed a new tor-relay about 2 months ago. It runs on a server with 
> 2 Quad-cores, 8GB RAM and 1Gbit connection.However, I have still not received 
> very much traffic to it, it almost never goes above 10Mbit.This is the server 
> traffic the last 2 months:http://best-practice.se/dump/tor-ralay.PNG
> Is this normal or may I have configured something wrong?Last time I had a 
> relay running I received 100Mbit+ traffic...

What's your relay nickname or IP address?

-- 
With respect,
Roman


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

Re: [tor-relays] Confirm IPv6 Setup as Exit Node

[Roman Mamedov]

On Wed, 21 May 2014 22:51:49 -0700
Adam Brenner  wrote:

> I have setup a Tor exit node and IPv4 appears to work (will get a real 
> test in the next 48 hours). I would like to confirm my IPv6 setup as I 
> have found the documentation on this subject lacking (or my googling 
> skills suffering!)

I googled "Tor IPv6" and the first hit is:

  https://people.torproject.org/~linus/ipv6-relay-howto.html

what exactly do you find "lacking" in that document? To me it seems to do an
excellent job in explaining everything one needs to know in a concise and
clear manner.

-- 
With respect,
Roman


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

Re: [tor-relays] hardening a tor relay

[Roman Mamedov]

On Sat, 24 May 2014 10:51:52 +0200
David Serrano  wrote:

> With those ports allowed you'll be able to reach 80% of the network.

So you're okay with the thought that their relay will be 20% broken, and 20%
of all circuits people try to establish through it, will fail?

As Roger said, *all* outgoing ports need to be enabled.

-- 
With respect,
Roman


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

Re: [tor-relays] VPS for tor exit nodes

[Roman Mamedov]

On Tue, 3 Jun 2014 05:35:16 -0700 (PDT)
Contra Band  wrote:

> Dear exit node operators,
> 
> Could you please recommend vps providers allowing to run tor exit nodes? 
> 
> I checked many vps operators but most of them allow relays but not exit nodes 
> according to AUP or ToS.

1) https://trac.torproject.org/projects/tor/wiki/doc/GoodBadISPs

2) by looking to host an Exit node on a VPS as opposed to a dedicated server,
you likely expect to pay much less to the provider than you would for a
dedicated server. However the amount of trouble that an Exit node is going to
bring to the provider stays exactly the same, and it's not even close to being
justified by the profit they gather from a comparatively insignificant amount
which you pay for that VPS.

-- 
With respect,
Roman


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

Re: [tor-relays] Spam

[Roman Mamedov]

On Thu, 26 Jun 2014 15:06:44 +0100
kingqueen  wrote:

> hi,
> 
> well having run a relay for just under 2 weeks, I've got my first spam
> on this email address. As you will no doubt have guessed, this is not
> my usual email address, it is only used for the Tor relay contact
> details, this email list and a very few other projects that will not
> have published my email address anywhere.
> 
> So I guess that this spam is as a result of my email address appearing
> on Atlas or Globe or similar as a result of it being the contact
> address for my Tor relay.
> 
> I know this possibility is mentioned in the Tor documentation; I read
> it somewhere. I guess there's not much to be done about it; I wouldn't
> want to remove contact details - the address is already in the public
> domain anyway, and I want to be contactable with any problems. I guess
> I just have to use the standard spam filtering and combating measures.
> 
> Could those with experience of running a relay for longer, please
> advise if this will become a major problem? Will spam increase
> substantially? Also, any suggestions very gratefully received.

You put your IP on a web page, crawlers can harvest it and use for spam. I've
just tried and easily found your E-Mail using search engines such as Google
and others. If you didn't want it to be harvested for spam purposes, you could
have used at least some minimal obfuscation, e.g. "user AT example DOT com".
But instead you just published it there in the clear form. Nothing surprising
or even strictly speaking Tor-related.

-- 
With respect,
Roman


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

Re: [tor-relays] Spam

[Roman Mamedov]

On Thu, 26 Jun 2014 21:28:36 +0600
Roman Mamedov  wrote:

> You put your IP on a web page

Sorry, meant "E-Mail address" of course :)

-- 
With respect,
Roman


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

Re: [tor-relays] Spam

[Roman Mamedov]

On Thu, 26 Jun 2014 16:47:49 +0100
kingqueen  wrote:

> > just tried and easily found your E-Mail using search engines such as Google
> > and others.
> 
> Really? kingqu...@btnf.tw ?
> https://www.google.co.uk/search?q=kingqueen%40btnf.tw#q=%22kingqueen%40btnf.tw%22
> lists only a Tor node list.

And that Tor node list is, in fact, a web page.

Which is exactly what I meant. Your E-mail is in that list, the list is on the
web, and if crawlers from Google and other search engines could find it, then
also web crawlers which collect E-Mails to be used for spamming purposes could
find it just as easily.

One workaround is to obfuscate the E-Mail you use in your contact details as
I mentioned, either lightly or not, I have seen some really creative ways
people obfuscate their E-Mail to avoid spam-crawlers.

-- 
With respect,
Roman


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

Re: [tor-relays] One IPv4 address, 1Gbit connection

[Roman Mamedov]

On Tue, 01 Jul 2014 22:36:10 +1000
Tim  wrote:

> Tom,
> 
> Why not run multiple tor relays on different ports on the same IPv4 address?
> 
> For example, you could run 6 relays on 6 different ports on your IPv4 address 
> (6 x 180 Mpbs > 1 Gbps).
> 
> This would also utilise your 4 cores much more efficiently than running 2 
> relays (each relay will only ever use 1 core for most operations).

Because more than two relays per IPv4 address is ignored by the network; and
that was the whole point of the question.

I suggested some time ago that with the scarcity of IPv4 *and* abundance of
multi-core CPUs that the Tor developers should really consider raising the
relays-per-IP limit from 2 to at least 3 or 4.

Sure one can use IPv6, but I doubt there's any serious amounts of traffic on
IPv6 via Tor, so it will not help  with the original request to do something
which would help better utilize the full available bandwidth.

-- 
With respect,
Roman


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

Re: [tor-relays] UK Exit Node

[Roman Mamedov]

On Sun, 06 Jul 2014 06:06:35 +0100
Michael Banks  wrote:

> running PeerGuardian on the server in question (blocking 
> P2P/kiddyporn/hacking related IPs)

Thanks for notifying everyone, I hope your BadExit flag is already on its way.

-- 
With respect,
Roman


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

Re: [tor-relays] CPU usage

[Roman Mamedov]

On Mon, 07 Jul 2014 21:31:02 +0100
kingqueen  wrote:

> Hi, I'm running a Tor relay on a low cost dedicated server.
> 
> The tor relay is named kingqueen and it's running on an Intel Atom N2700 dual 
> core hyperthreaded CPU with 2gb of memory, in a data centre with a symmetric 
> 100mbps connection.
> 
> I have found as time goes on and usage of my relay increases (about 3 weeks 
> now) that the Tor process is increasingly using more of the CPU. TOP shows 
> Tor using over 100% of CPU and the load average is 2 or more.
> 
> I use the dedi for other, less intensive things (OpenVPN, seedbox, also 
> Owncloud though this falls over). I know that this is sub-optimal and ideally 
> the dedi should be for the relay alone.
> 
> I was wondering if the CPU usage is standard. I guess it could be, given it 
> has decryption work to be done? Is it high? Is there anything I can do to 
> lower it, other than rate limiting, which I don't want to do?

Hello,

Yes this is normal.

Set "NumCPUs 2" in your torrc to make it try utilizing the second core too
(this won't help much, but at least somewhat).

Also you should renice tor to e.g. +10 so that it doesn't interfere with your
non-Tor tasks. In Debian-based distros this should be configurable via
"/etc/default/tor" config file, by setting NICE="--nicelevel 10" there.

-- 
With respect,
Roman


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

Re: [tor-relays] CPU usage

[Roman Mamedov]

On Mon, 7 Jul 2014 23:30:22 -0700
"Asa Rossoff"  wrote:

> With hyperthreading, I think 4 would be optimal?

Yes, 4 can be set, but I remember reading somewhere that Tor doesn't scale
well beyond NumCPUs 2 (and poorly even to 2).

One way to increase utilization further would be to run a second instance of
Tor. However as this server is also used for other tasks, this could begin
starving them of CPU time via the hyperthreading concurrency even while Tor
nominally runs at lower nice levels.

-- 
With respect,
Roman


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

Re: [tor-relays] CPU usage

[Roman Mamedov]

On Tue, 8 Jul 2014 09:44:57 -0400 (EDT)
"Steve Snyder"  wrote:

> > ...renice to 10...
> 
> This is good for the Tor process itself, but disadvantages other processes. 
> If your server is doing name resolution (as an exit node) the resolver may be 
> impacted, which in turn will hamper handling of exit traffic.

Renicing to a positive value decreases the priority of a process, not
increases it. Tor at +10 will not affect any other processes, except maybe
"completely idle" priority ones, which get +20.

-- 
With respect,
Roman


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

Re: [tor-relays] Google captcha

[Roman Mamedov]

On Wed, 9 Jul 2014 12:22:06 +0100
kingqueen  wrote:

> Hello
> 
> Since running a relay, I have frequently had the notice akin to
> "Google has detected unusual activity from your computer or network"
> and had to do the captcha, when I have connected via the server that
> the relay is running on; both by Chromium over VNC and by Firefox over
> OpenVPN.
> 
> The thing is, I am not, and have never been, an exit node. I was a
> middle node and am now a guard node. So I am somewhat confused as to
> why Google is getting unusual activity from my server?
> 
> I guess it could be a coincidence and somebody else from the server
> farm has tripped it, but it seems a remarkable coincidence, as I have
> run the dedi for nearly a year and didn't have the Google notice until
> after the Tor relay was started in the last three weeks or so. But I
> don't understand how being a Tor relay could have tripped it, as I've
> never been an exit node.

Hello,

In your past E-Mail you mentioned your Tor relay nickname, I looked it up back
then, and it was a dedicated server at OVH.

Thing is, I also rent such a server, and has been running exactly into the
same problem with Google. However I do not run a Tor relay on that server.

If you take a closer look at the CAPTCHA page, at the bottom it should mention
your IP address. Check if it's maybe the IPv6 address of your server
(2001:41d0:...), in my case it always was. If yours shows IPv6 too, then this
issue is definitely not related to Tor, because in the default configuration
Tor does not use IPv6.

I suspect this is either a misconfiguration on Google's part, or indeed a
large number of Google scraper bots running in OVH's network.

For me the solution was to just abandon using the Google Search and switch to
StartPage[1], which aside from a number of privacy-related benefits[2], also
looks like Google from back in 2004 before they ruined it with all the damn
AJAX and "Web 2.0", which in my opinion is completely awesome.

[1] https://startpage.com/

[2] https://startpage.com/eng/protect-privacy.html

-- 
With respect,
Roman


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

Re: [tor-relays] Oubound Ports

[Roman Mamedov]

On Thu, 10 Jul 2014 19:48:06 -0700
"Greg Moss"  wrote:

> Thanks for the help. I have my ORport and DIRport defined in torrc and
> forwarded through the firewall up to the Tor Relay. I was just wondering in
> regards to outbound traffic from the server itself. In the event it gets
> compromised I really hate to open all ports outbound let alone possible DNS
> leaks and what not. Appoligize if this doesn't make since I just fired this
> thing up yesterday and want to make sure it is secure.

You do need to have all ports open outbound.

The reason is, your relay needs to be able to connect to all other relays, and
people run their relays on all sorts of weird ports.

However one thing to consider would be to restrict outbound port 22 and port 53
outbound to not get into trouble with your provider due to suspicions of SSH
bruteforcing / DNS reflection attacks. This will break a very small portion of
circuits built via your relay, but hopefully solve more potential problems
than this would cause.

-- 
With respect,
Roman


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

Re: [tor-relays] Oubound Ports

[Roman Mamedov]

On Fri, 11 Jul 2014 11:02:00 +0200
Moritz Bartl  wrote:

> > However one thing to consider would be to restrict outbound port 22 and 
> > port 53
> > outbound to not get into trouble with your provider due to suspicions of SSH
> > bruteforcing / DNS reflection attacks. This will break a very small portion 
> > of
> > circuits built via your relay, but hopefully solve more potential problems
> > than this would cause.
> 
> No! Tor is not able to detect this case, which will make client
> connection silently fail, and make the user experience a sad experience.

Agreed, but my point was that only a small minority of relays use port 22
(checked, 27 of them - more than I expected) or port 53 (just three relays),
so it may be a sacrifice that's worth making, in order to avoid losing the
ability to run Tor altogether due to being kicked out by your ISP.

Some time ago I proposed that Tor flags some ports as being unacceptable as
ORPort[1], but this did not gather much of a momentum. Meanwhile, especially
port 53 relays continue causing real problems[2] with ISPs.

Running a relay on ports like 22 and 53 should be considered downright rude to
your fellow relay operators.

[1] https://lists.torproject.org/pipermail/tor-talk/2014-June/033173.html

[2] https://lists.torproject.org/pipermail/tor-relays/2014-May/004562.html

-- 
With respect,
Roman


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

[tor-relays] Auto-detect and enable IPv6 // Re: Please enable IPv6 on your relay!

[Roman Mamedov]

Hello,

> We still have a depressingly low number of relays that support IPv6
> (currently only ~120 of ~1900 relays). If your host supports IPv6,
> please enable it, especially if you run an exit! This has to be done
> explicitly.

If you (supposedly) care so much, then can you please make it automatic?

There is no need to explicitly put the IPv4 address into the torrc.

And there is no need to explicitly put the IPv6 address into the config file of
virtually any other IPv4+IPv6 supporting software I can think of: web, mail,
NTP, XMPP servers, those are all capable of automatically figuring out which
IPs the host has.

Can't think of any reason of why this has to be otherwise in Tor, aside from
perhaps a certain lack of understanding of best IPv6 implementation practices
from the Tor developers side and/or nobody simply giving much thought to this
yet.

I currently run 15 Tor relays, 14 of those IIRC are IPv6 capable. But since
you did not bother to make enabling IPv6 in Tor anywhere near user-friendly
[1], I am simply not going to bother pecking the IPs into each torrc
individually. [ One of the practical reasons being that I sometimes need to
migrate the Tor 'identity' (torrc + /var/lib/tor/*) between machines and
providers with v4/v6 addresses obviously changing. ]

Aside from migrations between providers, the requirement to specify the IP is
also impractical in many other situations, e.g. my ISP at home provides only a
__dynamic__ IPv6 subnet which changes to a different one with each new PPPoE
session.

[1] Ideally there should be no 'enabling' at all!!! IPv6 should be active by
default, IF the relay has determined it is able to make a successful IPv6
connection with a dir-authority -- oh and also that's how you can discover the
actual working IPv6 address to use; or at least with a simple "IPv6Relay 1,
but certainly with no requirement of specifying the IP address in the config
file.

-- 
With respect,
Roman


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

Re: [tor-relays] Auto-detect and enable IPv6 // Re: Please enable IPv6 on your relay!

[Roman Mamedov]

On Fri, 22 May 2015 13:31:02 +
Speak Freely  wrote:

> Uhh, I would like to point out that it would be exceptionally stupid
> to have Tor autoconfigure IP addresses, regardless of whether it's
> IPv4 or IPv6.

On IPv4 it currently does. There is zero rationale as to why IPv6 must be
different from IPv4 in this aspect.

> What if I want to run a webserver on one IP address, and Tor on
> another? What if I decide to also run a mail server on a third IP
> address? What if I want to run an Onion Service? What if I have a
> beefy system with quad 100mbit connections and want to run 4 Tor
> relays on the same system? What about a complicated network setup that
> uses VMs and requires punching through NAT and port forwarding through
> two firewalls to the outside world? Does Apache correctly guess which
> IP you want to use, when there are multiple choices? Does your
> favourite mail server *know* which IP address to use? NO! So why
> should Tor be made of fairy dust?

An option to explicitly specify the bind IP is already there for IPv4. Nobody
is against having an option to specify the IP in IPv6 too, if you need that.

> Write a script if it's such a problem! Learn to love sed. This is a
> non-problem. This is trivial. You're running 15 relays

I also run an IPv6 advocacy website [1], so I have somewhat of a vested
interest in seeing IPv6 deployed in a solid fashion, i.e. transparently for
the end-users, not bringing in a requirement of more silly manual busywork with
config files, or coding up elaborate scaffolding for it themselves.

Sure I could write a shell script (hey I have one to auto-update TorFamily!),
but in this case it just feels terrible, having to use a dirty workaround for
a glaring and unexplainable (to me) deficiency, something that should and
easily could have been implemented right in the first place. (Before you
ask, sorry I am not really a C coder so can't send in a patch).

[1] https://version6.ru/en/ipv6-for-freedom

-- 
With respect,
Roman


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

Re: [tor-relays] Bridge Usage and Setup

[Roman Mamedov]

On Mon, 1 Jun 2015 13:23:34 -0400 (EDT)
"Steve Snyder"  wrote:

> >2) Testing
> >How do I (easily) confirm my bridge is correctly configured?
> >Especially if I don't have an IPv6 connection for TBB?
> 
> FYI, you can get up to 5 IPv6 addresses for free from Hurricane Electric:
> 
> https://tunnelbroker.net/

Correction: you can get up to 5 _tunnels_ (pointing to different IPv4
addresses of yours, typically each to a different host or network where you
need to add IPv6);

Each tunnel provides you a /64 subnet by default, plus a /48 subnet on request
(done automatically via their panel);

And each of these subnets provide you with much much more than just 5 IPv6
addresses.

-- 
With respect,
Roman


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

Re: [tor-relays] IPv6 adress valid?

[Roman Mamedov]

On Mon, 1 Jun 2015 20:12:29 +0200
tor-server-crea...@use.startmail.com wrote:

> hi,
> is that IPv6 adress valid for example "becks" [2a01:4f8:162:7345::2]?
> how do i know if IPv6 is correct and reachable?
> thanks

Yes this one is correct and reachable.

You can check yourself by running on any IPv6-capable GNU/Linux machine:

  ping6 2a01:4f8:162:7345::2

As for whether or not any given address is correct, you should be able to tell
after learning about IPv6 addresses are [1], their basic structure and possible
shortening methods (omitting leading zeroes and the :: that you see in yours). 

[1] https://en.wikipedia.org/wiki/IPv6_address

-- 
With respect,
Roman


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

Re: [tor-relays] Multi-core Support

[Roman Mamedov]

On Tue, 02 Jun 2015 11:13:13 -0400
12xBTM <12x...@gmail.com> wrote:

> Improving multi-core support can allow users to saturate high bandwidth 
> connections with cheaper processors, less setup, and just more efficient 
> deployment of high-capacity nodes in general. Improving multi-core 
> support should be a major priority.

Sure but I doubt anyone contests that it's better to have multicore support,
than to not have it. However that work doesn't get automatically done.

One quick and simple stop-gap alternative that I suggested some time ago would
be to stop ignoring more than two relays per IP address.

With the IPv4 shortage and abundance of multi-core CPUs, raising that limit to
let's say 4, would at least allow many people to run a Tor process per core on
the same single IPv4 that they have (utilizing up to four cores, not just two).

Considering that Tor is already somewhat multi-threaded (each process can use
up to "120-130%" CPU), that might be just enough in most circumstances, since
true 6-8-core CPUs are rare, and what's seen more often beyond 4 cores is
either Intel HT or AMD's "light" core technologies.

Of course the management (and memory) overhead of multiple processes is still
there, so proper multi-core scaling is the ideal final goal.

-- 
With respect,
Roman


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

Re: [tor-relays] Please enable IPv6 on your relay!

[Roman Mamedov]

On Thu, 18 Jun 2015 20:40:44 +0200
Jesus Cea  wrote:

> # Declaramos que este nodo TOR es accesible a través de IPv6
> ORPort [::]:PUERTO_TOR

You thought it would be this simple. Nope, unlike every other IPv6-capable
program on Earth, in Tor this syntax of "bind to all IPs" is not supported.
They want you to specify the actual single IP manually, and then keep track if
it changes and each time not forget to go to torrc to update it.
https://lists.torproject.org/pipermail/tor-relays/2015-May/007063.html

> 
> # Es un nodo de tránsito, no de salida
> IPv6Exit 1
> ExitPolicy reject6 *:*
> """
> 
> After 39 hours Atlas still doesn't show me as IPv6 accessible and I see
> ZERO IPv6 connections in or out.
> 
> 
> 


-- 
With respect,
Roman


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

Re: [tor-relays] Qualities of a good relay (Sean Saito)

[Roman Mamedov]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Thu, 25 Jun 2015 10:49:30 +0200
nusenu  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> > Wow, thank you all for the suggestions!
> > 
> > Hope to implement these soon. Would definitely appreciate more
> > ideas too.
> 
> 
> If you have the time to maintain such a factor you could weight in
> relative bw cost per region, because the prices per bw unit heavily
> deffer depending on the region in which a relay is running.
> 
> e.g. relay runs in South America -> expensive bw -> multiplier greater
> than 1

A relay running in South America could do more bad than good, as it would
increase the average latency if e.g. users in Europe accessing sites in Europe
now have to go via South America on some circuits.

However most likely it won't get a high enough consensus weight in the first
place, e.g. I run a relay in Japan on a gigabit connection, but nobody cares
too much, since (I assume) bwauths aren't anywhere near Japan and do not get
good speeds to it, they give it a low weight, and as a result it doesn't see a
lot of use.

- -- 
With respect,
Roman
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlWLxBgACgkQTLKSvz+PZwgWvACbB2WzeQSfAp988T/Z/X2mE6Ky
hTgAmgPyTdYD1kJveorLx6a8oVYjLfp9
=4f/W
-END PGP SIGNATURE-
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Naive question about consensus weight

[Roman Mamedov]

On Fri, 17 Jul 2015 14:52:42 +0100
Jonathan Baker-Bates  wrote:

> So I'm curious as to whether there's anything I can do to bring my
> consensus weight up, apart from just ensuring continuous uptime. That's not
> often under my control though, since reboots for kernel updates etc. come
> quite regularly.

You could set up a 2nd instance of Tor on the same machine and IP address (of
course using a different set of ports). This would help you to try the
suggested "start afresh" experiment without losing your currently running
relay.

-- 
With respect,
Roman


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

[tor-relays] Giving away some "pre-warmed" relay keys for adoption

[Roman Mamedov]

Hello,

If anyone is planning to spin up a new VM or dedi to run a Tor relay and want
it to be put instantly into good use (without wasting couple of weeks to a
month for the whole "unmeasured relay/measured/guard/stable" cycle to
complete) or if you are having trouble with your current relay being measured
properly, in a few days I'm considering to give away several fingerprints+keys
from my relays that I will be shutting down.

If you install Tor on a new machine and unpack one of these into
your /var/lib/tor, it starts up something like this (see below); i.e. in a
couple of hours to a full 100% utilization.


 eth0 16:59 
  ^  t  
  | t  t rt rt rt rt
  | rt rt rt rt rt rt rt
  |  rt rt rt rt rt rt rt rt
  |   rt rt rt rt rt rt rt rt rt
  |   rt rt rt rt rt rt rt rt rt
  |   rt rt rt rt rt rt rt rt rt
  |rt rt rt rt rt rt rt rt rt rt
  | rt rt rt rt rt rt rt rt rt rt rt
  | rt rt rt rt rt rt rt rt rt rt rt
 -+---> 
  |  17 18 19 20 21 22 23 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16

 h  rx (KiB)   tx (KiB)  h  rx (KiB)   tx (KiB)  h  rx (KiB)   tx (KiB) 
17  0  001  0  009   34135840   34964598
18  0  002  0  010   37991652   38890814
19  0  003  0  011   38710878   39749495
20  0  004  0  012   39168357   40164982
21  0  005  50433   147213   42351426   43626118
22  0  006   10904079   1092759314   42826283   43928095
23  0  007   15691530   1583943915   41240931   42507372
00  0  008   27079433   2740303516   41941981   43139517

Drop me an E-Mail if you want one of these (probably about 2-3 available for
now).

-- 
With respect,
Roman


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

Re: [tor-relays] Giving away some "pre-warmed" relay keys for adoption

[Roman Mamedov]

On Sat, 25 Jul 2015 19:47:23 +
isis  wrote:

> I could take those backdoored^W"pre-warmed" keys and put them to good use!

Hello,

Mkay, I'll get in touch in a few days.

As for other repliers, I would not mind explaining my reasoning in more detail,
if you have any specific questions or more articulated objections that a
knee-jerk "ban it" or "lolz" reactions.

Thanks

-- 
With respect,
Roman


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

Re: [tor-relays] Giving away some "pre-warmed" relay keys for adoption

[Roman Mamedov]

On Sun, 26 Jul 2015 01:35:10 +
Yawning Angel  wrote:

> The relay identity key is sensitive cryptographic material.  Sharing it
> means the private key is compromised and is an attempt to subvert:

>  * The bandwidth scanning process.  The consensus weight is the relay's
>capacity relative to other nodes in the network which will change
>and should be reset if the location of the relay changes.

Yeah perhaps I should have mentioned that people should request one if they
are absolutely certain that their server is capable of handling at least 50+50
Mbit of bandwidth.

>  * The flag assignment process.  A random person should not get the
>Guard or Stable flag quickly.

...and that they expect it to have a certain degree of stability. :)

Sure this is a shortcut of sorts, and it's one that you should take if you
believe you can "vouch" for things like stability and b/w capacity you can
provide, and want to "skip the formalities" a bit so to say, and start
contributing to the maximum extent possible immediately; surely nobody likes
paying for idle servers.

Either way you won't do much damage even if any of this ends up being false,
as the consensus weight and the stable status will drop more rapidly than
they are gathered if your node can't maintain them.

>Yes, in an ideal world the bwauths will scan new relays faster.

Meanwhile in reality the outcome is often [1].

> A fun task for someone who likes messing with consensus documents and
> descriptors would be to write a script to measure IP address churn
> for relays while the relay identity remains constant (either
> legitimately eg: being on a dynamic IP, person had to move the rack the
> relay was on, or through key compromise/derp).

I do this extensively on my relays, as one VPS or dedicated server expires,
gets terminated or canceled for various reasons, a different one takes its
place, inheriting the same identity. If I had to always wait for new relays to
spin up from scratch in each case, a lot of the time I probably wouldn't even
bother.

Running 20 relays in a declared family at the moment, together comprising about
1.8% of aggregate Tor bandwidth, however due to financial reasons I will have
to shut down most of these over the coming weeks and months; so I see little
difference if the next machine inheriting a particular identity this time will
be managed and paid for by someone else and not by me. Just throwing these
away seemed like a waste.

[1] https://lists.torproject.org/pipermail/tor-relays/2015-June/007203.html

-- 
With respect,
Roman


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

Re: [tor-relays] Giving away some "pre-warmed" relay keys for adoption

[Roman Mamedov]

On Sun, 26 Jul 2015 05:32:17 +0500
Roman Mamedov  wrote:

> On Sat, 25 Jul 2015 19:47:23 +
> isis  wrote:
> 
> > I could take those backdoored^W"pre-warmed" keys and put them to good use!
> 
> Mkay, I'll get in touch in a few days.

Hello,

I have decided to spin up some more servers, and this should postpone the need
to turn off any of the relays by at least 3 weeks (at the cost of an increased
burn-rate, i.e. now they all will expire sooner and "all at once").

Also the reaction on the mailing list was not overly positive, so I might
reconsider the idea of letting others reuse these identities altogether.

Thanks

-- 
With respect,
Roman


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

Re: [tor-relays] BWauth no-consensus state in effect

[Roman Mamedov]

On Wed, 5 Aug 2015 10:58:30 +0100
Tim Sammut  wrote:

> That said, it raises the partially-rhetorical question: should I spend
> my $x/month on running a relay or could that money be better used in
> other places?

Generally depends on if you are getting a good deal on bandwidth, i.e. how
many terabytes per month for your $x. But I see you are running a relay in
Costa Rica, where servers and bandwidth must be much more expensive than e.g.
in Europe. I'm not sure how useful a relay in an exotic location, if it's
expensive to run and pushes very little traffic. Maybe others can comment.

BTW one way to increase utilization if you can't seem to use the CPU or
bandwidth to their fullest extent, is to run two instances of Tor per one IPv4
(assuming you have at least 512 MB of RAM per instance on the server, i.e. at
least 1GB for two).

-- 
With respect,
Roman


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