[tor-relays] Exit flag and port 6667 vs 6697

Wed Jul 5 00:36:18 UTC 2017

> 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 at gmail.com>
> To: tor-relays at lists.torproject.org
> Subject: Re: [tor-relays] Exit flag and port 6667 vs 6697
> Message-ID: <F84DD3E5-F83F-4B13-A5CF-7A518687B719 at gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
>
>> On 5 Jul 2017, at 05:29, grarpamp <grarpamp at 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
> ------------------------------------------------------------------------
>
>
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 801 bytes
> Desc: Message signed with OpenPGP
> URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20170705/b27de9ce/attachment-0001.sig>
>
> ------------------------------