Give the Exit flag to Exits that use the secure IRC port 6697
Igor Mitrofano suggests that the Exit flag should be given to relays that allow exiting to the default secure IRC port 6697.
From tor-relays: https://lists.torproject.org/pipermail/tor-relays/2017-July/012585.html
The existing policy is "two ports from [80, 443, 6667]", or these options:
- 80, 443
- 80, 6667
- 443, 6667
We would change to "two ports from [80, 443, 6667-OR-6697]", adding these options:
- 80, 6697
- 443, 6697
We don't need a new consensus method for this, because the way Exit flags are combined stays as majority vote.
Activity
changed milestone to %Tor: unspecified
The Exit flag serves two roles:
A) It allows people to build preemptive circuits, and end them at a relay that has a good chance of being able to handle whatever future stream the client receives. That is, we want to build a circuit before we know what stream request is going to arrive, and we want to have a good chance that the last hop on that circuit will be able to handle the request. So in that sense the Exit flag signifies "is able to handle many of the likely requests by users".
B) It allows clients to shift load away from relays that probably already have a lot of load because they're being used as exits. That is, if your relay has the Exit flag, then my client will avoid using it in the first or second hops of my circuits, because for global load balancing it is best to save its bandwidth for being an exit since exit capacity is scarce.
For the first one, I want to know what this particular client is likely to do, and build circuits that are going to be able to handle those requests. That's part of what the "predicted ports" logic is for in rephist.c -- see for example
rep_hist_note_used_port().Whereas for the second one, I want to know what most of the other clients are likely to do, so I can take the correct behavior to produce the globally optimum load across all the relays.
Originally, I picked "80, 443, and 6667" as an indication that if you accept those three, you probably accept a bunch of other ports too, so you're likely to be an exit relay that gets used for exit traffic.
So as people try to squeeze down their exit policy while retaining the Exit flag, they are pushing themselves farther from being the sort of relay that is being used a lot for exit traffic.
If I were to make a change based on (my intuition of) traffic these days, I would change it to simply "80 and 443".
-
Replying to teor:
People send proposals to the tor-dev@ mailing list for discussion. It will help if it has the same structure as other recent proposals.
In fact, check out proposal 001 for the recommended structure. :)
https://gitweb.torproject.org/torspec.git/tree/proposals/001-process.txt
Your intuition is probably right. I had to pick 6667 to avoid 80 after reading about people still receiving abuse emails when having port 80 open, and after talking to my ISP who warned me about the same happening to my predecessors who tried to run exit nodes (and I assume were forced to stop). Unlike HTTP that is still alive and well, IRC has marginalized / declined in popularity since 2004 (netsplit.de, top 10 networks), making it less interesting as an abuse target.
80 is essentially a wildcard port, the port-based exit policy system may simply be obsolete, but I see no short-term solutions to that.
I had no idea that the 'Exit' flag was used as a predictor of being able to handle most connections. Perhaps it's worth mentioning somewhere. I thought any open port added incremental value.
Trac:
Username: IgorMitrofanovReplying to arma:
... If I were to make a change based on (my intuition of) traffic these days, I would change it to simply "80 and 443".
Your intuition is accurate: the most recent measurements of tor exit port usage show it's mainly 80 and 443 (except when all ports are allowed, when the web percentage drops).
See page 9 of http://www.robgjansen.com/publications/privcount-ccs2016.pdf for some neat graphs.
-
My email to tor-dev@ bounced for some reason. I'll paste what I got below. My main motivation is end-to-end encryption, so I won't be upset if a completely different solution ends up getting implemented.
PROPOSAL:
" Ticket: https://trac.torproject.org/projects/tor/ticket/22820 All comments are welcome.
-
Overview
To allow exit relay operators to specify exit policies restricted to ports typically used with protocols featuring transport-level encryption, this proposal suggests treating port 6697 (IRC over TLS) as an alternative to port 6667 (IRC plaintext) for the purpose of assigning the 'Exit' flag to Tor relays.
-
Background
Today, a relay gets the 'Exit' flag if it allows traffic to exit to at least two of the following 3 ports: 80, 443, 6667. Without the 'Exit' flag, a relay is unlikely to be selected by Tor clients as the exit node for their general-purpose circuits.
Ports 80 and 443 were reserved for HTTP and HTTPS protocols, respectively. Due to the popularity of the WWW, they remained the least likely ports to be blocked by firewalls. Over time, software developers began to tunnel other types of traffic through these ports, rendering the relation between port numbers and the underlying protocols obsolete. Still, this proposal makes an assumption that most of the traffic directed to port 443 is TLS- encrypted, while most of the port 80 traffic remains plaintext.
Port 6667 is commonly used by Internet Relay Chat (IRC) servers for plaintext communication with IRC clients. A consensus has been reached within the IRC community about listening on TCP port 6697 for incoming IRC connections encrypted via TLS.
-
Motivation
The lack of enforced end-to-end encryption creates substantial risks for both Tor users and Tor relay operators. New Tor users are generally unaware of the fact that malicious exit nodes can capture plaintext sensitive data and attack their browsers. Exit relay operators cannot prove (beyond reasonable doubt) that they are not responsible for any criminal activity linked to their node.
Ultimately, the author of this proposal envisions a setting that allows any Tor user to force end-to-end encryption, so that the only party they need to trust is the one they communicate with. As the first step towards that vision, specifying encryption-oriented exit policies should become possible to begin with.
-
Proposed 'Exit' flag policy
Today, in order for a relay to receive the 'Exit' flag, it has to allow Tor traffic to exit to at least one /8 IPv4 address, plus have to accept at least 2 of the following 3 ports (protocols):
80 (HTTP, plaintext) 443 (HTTPS) 6667 (IRC, plaintext)Effectively, to quality for the 'Exit' flag, a relay must allow connections to any of the following combinations of ports:
80 and 443, 80 and 6667, 443 and 6667.This proposal extends the current policy of assigning the 'Exit' flag by adding the following 2 options:
80 and 6697, 443 and 6697**The last option allows Exit relay operators to limit their support to normally-encrypted traffic only.
No new flag need to be created (unless it is a good idea to allow users to prioritize such encryption-focused exit relays).
The concensus algorithm should remain the same.
-
Proposed addition to the list of reduced exit policies.
On the torproject.org website, the following exit policy could be recommended to operators who need to minimize their exposure to plaintext traffic:
ExitPolicy accept *:53 # DNS (does not require encryption) ExitPolicy accept *:443 # HTTPS ExitPolicy accept *:993 # IMAP over SSL ExitPolicy accept *:995 # POP3 over SSL ExitPolicy accept *:6697 # IRC over SSL -
Pros
Allowing relay operators to specialize in relaying usually-encrypted traffic can reduce their risks and make more exit nodes available.
More capacity dedicated to relaying encrypted protocols can make the Tor network faster at relaying that type of traffic, indirectly helping the adoption of those protocols.
Tor users who must pick a specific exit relay (as opposed to picking one randomly) will be able to prioritize relays that favor encrypted traffic (and therefore are less likely to be malicious).
-
Cons
It is unclear how popular port 6697 compared to port 6667 is, and whether relay operators switching from 6667 to 6697 can negatively impact users accustomed to using IRC through its default port 6667.
There are still a number of mostly-plaintext protocols (FTP, HTTP) that can become neglected if exit relay operators start to adopt exit policies limited to encrypted protocols only. "
Trac:
Username: IgorMitrofanov -
Replying to IgorMitrofanov:
My email to tor-dev@ bounced for some reason.
We should get that fixed, so that you can discuss the proposal. (Otherwise, I would just send a copy to the list.)
arma might be able to help with that, or we can open a sysadmin ticket. To search for your email, we will need to know some part of it. Can you please tell us part of the username part? (No need to put your whole email here and attract spam.)
Hi Igor,
Please re-send your email to tor-dev@lists.torproject.org.
-
Replying to arma:
If I were to make a change based on (my intuition of) traffic these days, I would change it to simply "80 and 443".
I have opened a ticket for this direction: #23637 (moved). It includes patches.
mentioned in issue #23637 (moved)
moved to tpo/core/tor#22820 (closed)
mentioned in issue tpo/core/tor#23637 (closed)
