Port numbers and TLS ore orthogonal: port 443 can be used for cleartext, and port 80 for encrypted traffic. In the case of IRC, it's quite common for 6667 to be used with TLS.
When a relay operator uses exit policies, I believe they express an intent to block certain types of applications, and not just ports those applications typically run on. They mean to block HTTP when they block port 80, and they mean to allow HTTPS when they allow port 443. Exit relay who use anything but "accept *:*" engage in application-level traffic censorship to balance their risk with their contribution (if this is not a form of censorship, what are exit policies really for?).
Both port-based exit policies, designed when ports meant much more than they do today, and the definition of the exit flag, seem obsolete. Ports no longer allow Tor users or relay operators to manage their risks well, and the exit flag policy does not allow the Tor community to protect the network against P2P abuse and optimize it in any meaningful way.
For example, as a Tor user, how can I express my desire to only use exit nodes that refuse to see any plaintext traffic - where's that checkbox in the Tor browser? As an exit relay operator, how can I minimize the abuse risks often associated with insecure protocols? As a member of the Tor community, how can I understand why making _historically_-plaintext traffic on port 6667 (as opposed to usually encrypted traffic on ports 993, 995, 587, 6697) part of the minimum contribution is optimal for the network?
Long-term, I believe that Tor will need to move away from port-based policies to standard / verified / signed deep-packet-inspection plugins. I do have a short-term proposal though (below).
The current Exit flag requires 2 ports out of [80, 443, 6667]. Can you clarify what the two options are that you are suggesting here?
For starters, I would propose making it possible to run an Exit node without relaying traffic to ports designed to carry insecure protocols. That would mean a change as simple as "two ports from [80, 443, 6667-OR-6697]". Later, I would ask the Tor project to study the traffic (by port numbers) and re-examine the port-based exit policy system in general.
And the Exit operator would need to set up DNSCrypt or similar. Otherwise Exit DNS requests are trivially monitorable.
I am using dnsmasq with a large (65536) cache and several 1ms-latency upstream DNS servers it randomly picks from. I believe it should be sufficient to complicate the DNS-assisted timing attacks that I am aware of.
Thanks - Igor
Message: 4 Date: Wed, 5 Jul 2017 08:08:25 +1000 From: teor teor2345@gmail.com To: tor-relays@lists.torproject.org Subject: Re: [tor-relays] Exit flag and port 6667 vs 6697 Message-ID: F84DD3E5-F83F-4B13-A5CF-7A518687B719@gmail.com Content-Type: text/plain; charset="utf-8"
On 5 Jul 2017, at 05:29, grarpamp grarpamp@gmail.com wrote:
...
My current, rather paranoid, list of accepted ports looks like this: 20-21, 53, 443, 993, 995, 6667. I am not sure how useful this is to Tor, and whether I will actually avoid complaints, but I guess I can only wait and see.
Most Tor traffic is HTTP or HTTPS, and the HTTPS proportion is growing. So this is useful.
My question is about 6667 - should Tor's 'Exit flag policy' allow 6697 (IRC encrypted over SSL) as an alternative to 6667? I would rather support people using 6697, if I had the choice.
Some IRC services allow or require SSL on 6667, others require it on 6697. Why not enable both?
I really do think this is a good way to tackle this issue: we should encourage relay operators to enable *both* 6667 and 6697.
The flag minimum requirement really is a minimum.
So I can't see a strong case for switching to 6697, given that the Exit flag is only a hint to relay operators about the minimum useful ports.
6667 cleartext is there because tor is old... it was widely prevailing then. 6697 TLS became widespread much later, especially post Snowden.
What does survey of IRC nets regarding TLS capabilities look like today? Do users have some need to connect, out via exit, to [any particular] cleartext IRC services, for something that TLS IRC services do not provide? Do we continue endorsing cleartext upon operators who seek minimums and/or proffer to carry non-monitorable e2e traffic to avoid legal issues?
Port numbers and TLS ore orthogonal: port 443 can be used for cleartext, and port 80 for encrypted traffic. In the case of IRC, it's quite common for 6667 to be used with TLS.
And the Exit operator would need to set up DNSCrypt or similar. Otherwise Exit DNS requests are trivially monitorable.
Does cleartext insistance therein funnel users into choosing possibly harmful cleartext transports due to better speed / latency / probability of successful exit paths? What are consensus bandwidth capacity and exit node counts for 6667:6697? What is the traffic ratio of 6667:6697 actually exiting the network?
Good question. We don't collect stats on individual ports, because it's hard to do safely.
I suspect switching minimum to 6697 is fine, or at least making it logical OR.
The current Exit flag requires 2 ports out of [80, 443, 6667]. Can you clarify what the two options are that you are suggesting here?
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
On 5 Jul 2017, at 10:36, Igor Mitrofanov igor.n.mitrofanov@gmail.com wrote:
Port numbers and TLS ore orthogonal: port 443 can be used for cleartext, and port 80 for encrypted traffic. In the case of IRC, it's quite common for 6667 to be used with TLS.
When a relay operator uses exit policies, I believe they express an intent to block certain types of applications, and not just ports those applications typically run on. They mean to block HTTP when they block port 80, and they mean to allow HTTPS when they allow port 443. Exit relay who use anything but "accept *:*" engage in application-level traffic censorship to balance their risk with their contribution (if this is not a form of censorship, what are exit policies really for?).
This is a complex question that has been asked before.
To summarise: Exit policies exist to make it possible to run an exit that allows clients access to most websites. The alternative is that the Tor network just doesn't have enough exit capacity or diversity to help people.
Search the mailing lists for previous discussions.
Both port-based exit policies, designed when ports meant much more than they do today, and the definition of the exit flag, seem obsolete. Ports no longer allow Tor users or relay operators to manage their risks well, and the exit flag policy does not allow the Tor community to protect the network against P2P abuse and optimize it in any meaningful way.
For example, as a Tor user, how can I express my desire to only use exit nodes that refuse to see any plaintext traffic - where's that checkbox in the Tor browser? As an exit relay operator, how can I minimize the abuse risks often associated with insecure protocols? As a member of the Tor community, how can I understand why making _historically_-plaintext traffic on port 6667 (as opposed to usually encrypted traffic on ports 993, 995, 587, 6697) part of the minimum contribution is optimal for the network?
Long-term, I believe that Tor will need to move away from port-based policies to standard / verified / signed deep-packet-inspection plugins.
Depp packet inspection has legal implications in many jurisdictions. And it's less safe for users to deploy DPI tools on every relay.
I do have a short-term proposal though (below).
The current Exit flag requires 2 ports out of [80, 443, 6667]. Can you clarify what the two options are that you are suggesting here?
For starters, I would propose making it possible to run an Exit node without relaying traffic to ports designed to carry insecure protocols. That would mean a change as simple as "two ports from [80, 443, 6667-OR-6697]".
I opened a ticket for this: https://trac.torproject.org/projects/tor/ticket/22820
But it needs someone to write a proposal, and then a discussion period. For examples, see: https://gitweb.torproject.org/torspec.git/tree/proposals
Later, I would ask the Tor project to study the traffic (by port numbers) and re-examine the port-based exit policy system in general.
This is a complex question that needs further research, and good legal resources across multiple jurisdictions. We'd love to make it better, but it's going to be slow to change for those reasons.
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@lists.torproject.org
-
Igor Mitrofanov -
teor