[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-talk] Problematic ORPorts

On Sat, 7 Jun 2014 14:02:43 -0400
grarpamp <grarpamp@xxxxxxxxx> wrote:

> > So my idea is, maybe consider making directory authorities blacklist some
> > ports as being unacceptable as ORPorts, 22 and 53 come to mind for a start,
> > along with maybe 25 to avoid false alarms from anti-spam countermeasures.
> ORport config exists to give better anti blocking/censorship
> performance. So Tor should not exclude any OR port/protocol.
> The problem is with you and your ISP, not other relays who
> have fine working relationships with their ISP regarding binding
> to those ports.

First of all, if an end-user is affected by censorship, they are likely to use
Tor Bridges anyway, so the need of plain relays on standard ports does not
seem to be of much significance.

Second, to the contrary of what you describe regarding ISP relationships, it
could very well be that running a relay on a port like 22 or 53 is caused by
the opposite, i.e. by their ISP not being fully informed of what the relay
operator is doing on their machine, and as a result with the said operator
only being able to request opening/forwarding of a few innocent-looking ports
from their network administrator (e.g. at an university or school). Sure they
are doing this out of their best intentions to contribute bandwidth to Tor,
but if such 'contribution' ends up knocking five other much faster relays from
being able to act as relays anymore, how positive is it really.

> A relay operator who feels they are at risk of making such
> contact should probably work with their host or find another
> one instead of narrowing their possible outbound paths. (The
> impact to tor network of RelayNoORPorts would depend on
> percent nodes having your noisy ORport and traffic weights.
> May also affect clients reaching specific exit relay using said
> ports. And add more overhead signaling. Better to find new host.)

One issue is often the very fact that having a lot of such connections can be
problematic might only be discovered post-factum*, i.e. after the user already
has been forcefully "parted" with their VPS or dedi (prepaid for a some
significant period too). Trying to explain about Tor in this case can easily
result in some less-than-qualified or overly cautious ISPs banning all Tor on
their network altogether ("oh so it was Tor that caused these SSH or DNS
attacks? OK, from now on adding a 'no Tor' rule into the ToS").

* Sure you might argue that any relay operator needs to be upfront about
running a relay with their ISP, but really, the easiest and the most workable
solution when running a non-exit relay is (or at least was, before these
port 22 and port 53 relays) to stay "below the radar".

Another issue is that the pool of hosts providing cheap or reasonably priced
unmetered VPSes or dedicated servers is far from being infinite, that you
could so easily just abandon one and move over to the next one.

With respect,

Attachment: signature.asc
Description: PGP signature

tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to