I've had this on my todo list for a while, finally wrote it down.
Honestly, it's a minor change, but something that imho needs to be done.
Torspec branch: https://github.com/TvdW/torspec/commits/exit-flag-not-all-plaintext
Full text below, tldr first: replace [80,443,6667] with [80,443,5222] for Exit flagging.
===================
Filename: 264-exit-flag-not-all-plaintext.txt Title: Stop giving Exit flags when only unencrypted traffic can exit Author: Tom van der Woerdt Created: 2016-01-05 Status: Open
1. Introduction
Tor's Exit flags are assigned to relays that have an exit policy that allows exiting to at least two out of three pre-defined ports: 80, 443 and 6667.
Since 80 and 6667 (resp. http and irc) are generally used for unencrypted traffic, an attacker could construct an exit policy that relays only unencrypted data.
2. Changes
2.1. Exit flagging
By replacing the port 6667 (IRC) entry with a port 5222 (XMPP) entry, Exit flags can no longer be assigned to relays that exit only to unencrypted ports.
2.2. dir-spec.txt
A change to dir-spec.txt will be needed to change port 6667 to 5222.
3. Migration
This change only needs to be rolled out to directory authorities. Since the flagging system is simple, no special migration is needed for this change, and it will take effect as soon as the deployment of the change has reached a sufficient number of directory authorities.
4. Other considerations
While it would have been ideal to drop the port 80 condition as well, in the current state of the internet this is not likely to be a good idea. Too much websites still use unencrypted connections. However, this may be worth reconsidering every few years.
XMPP was chosen to replace IRC because nowadays unencrypted XMPP is rare, and because the XMPP protocol is slowly gaining popularity within the communities on the internet. Other popular ports have been considered, such as 22 (SSH), 465 (SMTP), or 995 (POP3), but these are unlikely to be good candidates because of wide spread bruteforce attacks on these ports.
===================
Tom
On 5 Jan 2016, at 11:29, Tom van der Woerdt info@tvdw.eu wrote: ... 2.1. Exit flagging
By replacing the port 6667 (IRC) entry with a port 5222 (XMPP) entry, Exit flags can no longer be assigned to relays that exit only to unencrypted ports.
One consequence of this proposal is that relays that only exit to 443 and 6667 will lose the Exit flag. But these relays do exit to an encrypted port, so this somewhat contradicts the goal of the proposal: "Exit flags can no longer be assigned to relays that exit only to unencrypted ports."
Why not make the rule: "at least one of 80/6667, and at least one of 443/5222".
I am also concerned about the choice of XMMP "because the XMPP protocol is slowly gaining popularity within the communities on the internet". Shouldn't we focus on secure protocols that are widely used right now?
Alternately, we could add other widely used SSL ports in addition to XMMP, and perhaps increase the rule to "at least two SSL ports".
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP 968F094B
teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
Tim Wilson-Brown - teor:
One consequence of this proposal is that relays that only exit to 443 and 6667 will lose the Exit flag. But these relays do exit to an encrypted port, so this somewhat contradicts the goal of the proposal: "Exit flags can no longer be assigned to relays that exit only to unencrypted ports."
Why not make the rule: "at least one of 80/6667, and at least one of 443/5222".
Perhaps also a transitional period where exit-qualifying ports are added, and months after that, 80/6667 are no longer qualifying?
I am also concerned about the choice of XMMP "because the XMPP protocol is slowly gaining popularity within the communities on the internet". Shouldn't we focus on secure protocols that are widely used right now?
Alternately, we could add other widely used SSL ports in addition to XMMP, and perhaps increase the rule to "at least two SSL ports".
6697 is the most popular IRCS port, maybe it could replace 6667. Should 993(IMAPS), 995(POP3S) or 465(SMTPS) be considered as well?
Blah, what I said was already suggested, but I hadn't received the original mail when I'd replied
Hi Tim,
Thanks for your comments! Appreciated as always :-)
Op 05/01/16 om 02:15 schreef Tim Wilson-Brown - teor:
On 5 Jan 2016, at 11:29, Tom van der Woerdt <info@tvdw.eu mailto:info@tvdw.eu> wrote: ... 2.1. Exit flagging
By replacing the port 6667 (IRC) entry with a port 5222 (XMPP) entry, Exit flags can no longer be assigned to relays that exit only to unencrypted ports.
One consequence of this proposal is that relays that only exit to 443 and 6667 will lose the Exit flag. But these relays do exit to an encrypted port, so this somewhat contradicts the goal of the proposal: "Exit flags can no longer be assigned to relays that exit only to unencrypted ports."
(Sorry for the huge Perl oneliner -- it's a consensus parser...)
$ curl -q http://128.31.0.34:9131/tor/status-vote/current/consensus 2>/dev/null | perl -nle' @l= split /\s/, $_; if ($l[0] eq "r") { if ($r) { if (grep { "Exit" eq $_ } @{$r->{s}//[]}) { my @ports= split ",", $r->{p}[2]; @ports= map { $_ =~ /(\d+)-(\d+)/ ? eval("$1..$2") : $_ } @ports; my %p= map { $_ => 1 } @ports; if ($p{443} && !$p{80} && $p{6667} && !$p{5222}) { print "$r->{r}[1] $r->{w}[1]"; } } } push @r, $r={} } $r->{$l[0]}= [@l];'
(tlcr: any relay that currently holds an Exit flag and allows exiting to 443 and 6667, but not 80 or 5222.)
tiggersWeltTor1 Bandwidth=2600 smallegyptrela01 Bandwidth=22
These two relays will be impacted, indeed.
Why not make the rule: "at least one of 80/6667, and at least one of 443/5222".
Also sounds good to me. I opted for the smallest possible change (6667->5222) but what you're suggesting lgtm.
I am also concerned about the choice of XMMP "because the XMPP protocol is slowly gaining popularity within the communities on the internet". Shouldn't we focus on secure protocols that are widely used right now?
Alternately, we could add other widely used SSL ports in addition to XMMP, and perhaps increase the rule to "at least two SSL ports".
Imho the challenge is in finding port number(s) that accurately reflect what Tor is for, while also having a sufficiently large user base for it to be relevant. XMPP probably has more users than IRC, and is a good match for what I think Tor would consider important (communication). Also note that we now have Tor Messenger. Other protocols (SSH, IMAP, POP3, SMTP) are indeed more popular but I feel that those less reflect the goals of the project, and they are certainly abused more.
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP 968F094B
teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
On 5 Jan 2016, at 19:33, Tom van der Woerdt info@tvdw.eu wrote: ... Op 05/01/16 om 02:15 schreef Tim Wilson-Brown - teor:
On 5 Jan 2016, at 11:29, Tom van der Woerdt <info@tvdw.eu mailto:info@tvdw.eu> wrote: ... 2.1. Exit flagging
By replacing the port 6667 (IRC) entry with a port 5222 (XMPP) entry, Exit flags can no longer be assigned to relays that exit only to unencrypted ports.
One consequence of this proposal is that relays that only exit to 443 and 6667 will lose the Exit flag. But these relays do exit to an encrypted port, so this somewhat contradicts the goal of the proposal: "Exit flags can no longer be assigned to relays that exit only to unencrypted ports."
...
(tlcr: any relay that currently holds an Exit flag and allows exiting to 443 and 6667, but not 80 or 5222.)
tiggersWeltTor1 Bandwidth=2600 smallegyptrela01 Bandwidth=22
These two relays will be impacted, indeed.
Point taken!
How many Exits would lose the Exit flag intentionally based on this change? (That is, how many have 80 & 6667, but not 443?)
Why not make the rule: "at least one of 80/6667, and at least one of 443/5222".
Also sounds good to me. I opted for the smallest possible change (6667->5222) but what you're suggesting lgtm.
I am also concerned about the choice of XMMP "because the XMPP protocol is slowly gaining popularity within the communities on the internet". Shouldn't we focus on secure protocols that are widely used right now?
Alternately, we could add other widely used SSL ports in addition to XMMP, and perhaps increase the rule to "at least two SSL ports".
Imho the challenge is in finding port number(s) that accurately reflect what Tor is for, while also having a sufficiently large user base for it to be relevant. XMPP probably has more users than IRC, and is a good match for what I think Tor would consider important (communication). Also note that we now have Tor Messenger. Other protocols (SSH, IMAP, POP3, SMTP) are indeed more popular but I feel that those less reflect the goals of the project, and they are certainly abused more.
80/443 get us anonymous web browsing, primarily through Tor Browser 6667/6697 get us anonymous messaging via IRC (I don't know if 6697 is common enough to be worth changing for.) 5222 get us anonymous messaging via Tor Messenger
I can't think of any others right now.
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP 968F094B
teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
Op 05/01/16 om 10:22 schreef Tim Wilson-Brown - teor:
On 5 Jan 2016, at 19:33, Tom van der Woerdt <info@tvdw.eu mailto:info@tvdw.eu> wrote: ... Op 05/01/16 om 02:15 schreef Tim Wilson-Brown - teor:
On 5 Jan 2016, at 11:29, Tom van der Woerdt <info@tvdw.eu mailto:info@tvdw.eu mailto:info@tvdw.eu> wrote: ... 2.1. Exit flagging
By replacing the port 6667 (IRC) entry with a port 5222 (XMPP) entry, Exit flags can no longer be assigned to relays that exit only to unencrypted ports.
One consequence of this proposal is that relays that only exit to 443 and 6667 will lose the Exit flag. But these relays do exit to an encrypted port, so this somewhat contradicts the goal of the proposal: "Exit flags can no longer be assigned to relays that exit only to unencrypted ports."
...
(tlcr: any relay that currently holds an Exit flag and allows exiting to 443 and 6667, but not 80 or 5222.)
tiggersWeltTor1 Bandwidth=2600 smallegyptrela01 Bandwidth=22
These two relays will be impacted, indeed.
Point taken!
How many Exits would lose the Exit flag intentionally based on this change? (That is, how many have 80 & 6667, but not 443?)
If we change 6667 to 5222, this changes (where 0->1 means it will become an exit and 1->0 means it will no longer be one) :
FruityOatyTorexit Bandwidth=17700 0->1 Alice Bandwidth=25 0->1 tiggersWeltTor1 Bandwidth=3100 1->0 onionnetGOT01 Bandwidth=387 0->1 icubdw2o2xipsdc Bandwidth=137 1->0 miepernl Bandwidth=1420 1->0 ReservoirPi2016 Bandwidth=114 0->1 TORWeazel Bandwidth=98 0->1 HelloWorld Bandwidth=820 1->0 smallegyptrela01 Bandwidth=22 1->0 AnonNodeFin69 Bandwidth=80 0->1 Serveur Bandwidth=703 0->1 Biverse Bandwidth=779 0->1 comaTor1 Bandwidth=148 0->1 Unnamed Bandwidth=138 1->0
Gained bw: 20034 Lost bw: 5637
Tom
(source of this data: https://paste.debian.net/360256/)
Why not make the rule: "at least one of 80/6667, and at least one of 443/5222".
Also sounds good to me. I opted for the smallest possible change (6667->5222) but what you're suggesting lgtm.
I am also concerned about the choice of XMMP "because the XMPP protocol is slowly gaining popularity within the communities on the internet". Shouldn't we focus on secure protocols that are widely used right now?
Alternately, we could add other widely used SSL ports in addition to XMMP, and perhaps increase the rule to "at least two SSL ports".
Imho the challenge is in finding port number(s) that accurately reflect what Tor is for, while also having a sufficiently large user base for it to be relevant. XMPP probably has more users than IRC, and is a good match for what I think Tor would consider important (communication). Also note that we now have Tor Messenger. Other protocols (SSH, IMAP, POP3, SMTP) are indeed more popular but I feel that those less reflect the goals of the project, and they are certainly abused more.
80/443 get us anonymous web browsing, primarily through Tor Browser 6667/6697 get us anonymous messaging via IRC (I don't know if 6697 is common enough to be worth changing for.) 5222 get us anonymous messaging via Tor Messenger
I can't think of any others right now.
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP 968F094B
teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Other protocols (SSH, IMAP, POP3, SMTP) are indeed more popular but I feel that those less reflect the goals of the project, and they are certainly abused more.
I hear you that these are abused more. But I personally think of Tor as a mere mechanism than a mechanism+policy. For example, should the command "rm" refuse to remove a file that has the text in it that says "IMPORTANT! DO NOT DELETE!" Although obviously this is a well-intentioned feature, presumably rm should not behave this way. The rm command is a mechanism, the policy for that mechanism judicious use is a wrapping around the command itself.
One additional benefit of separating mechanism from policy is that it makes policies more easily changeable. Well-meaning people have disagreements on policies, and policies invariably evolve. Separating policies from the core functionality is helpful to allow easier experimentation with alternative policies.
Applying this here, I argue that the ports a relay makes available should not impact whether they get the exit flag. This is consistent with treating Tor as a mechanism instead of applying top-down a policy for how people are "supposed" to use it.
-V
On Wed, Jan 6, 2016 at 2:25 AM Tom van der Woerdt info@tvdw.eu wrote:
Op 05/01/16 om 10:22 schreef Tim Wilson-Brown - teor:
On 5 Jan 2016, at 19:33, Tom van der Woerdt <info@tvdw.eu mailto:info@tvdw.eu> wrote: ... Op 05/01/16 om 02:15 schreef Tim Wilson-Brown - teor:
On 5 Jan 2016, at 11:29, Tom van der Woerdt <info@tvdw.eu mailto:info@tvdw.eu mailto:info@tvdw.eu> wrote: ... 2.1. Exit flagging
By replacing the port 6667 (IRC) entry with a port 5222 (XMPP) entry, Exit flags can no longer be assigned to relays that exit only to
unencrypted
ports.
One consequence of this proposal is that relays that only exit to 443 and 6667 will lose the Exit flag. But these relays do exit to an encrypted port, so this somewhat contradicts the goal of the proposal: "Exit flags can no longer be assigned to relays that exit only to unencrypted ports."
...
(tlcr: any relay that currently holds an Exit flag and allows exiting to 443 and 6667, but not 80 or 5222.)
tiggersWeltTor1 Bandwidth=2600 smallegyptrela01 Bandwidth=22
These two relays will be impacted, indeed.
Point taken!
How many Exits would lose the Exit flag intentionally based on this
change?
(That is, how many have 80 & 6667, but not 443?)
If we change 6667 to 5222, this changes (where 0->1 means it will become an exit and 1->0 means it will no longer be one) :
FruityOatyTorexit Bandwidth=17700 0->1 Alice Bandwidth=25 0->1 tiggersWeltTor1 Bandwidth=3100 1->0 onionnetGOT01 Bandwidth=387 0->1 icubdw2o2xipsdc Bandwidth=137 1->0 miepernl Bandwidth=1420 1->0 ReservoirPi2016 Bandwidth=114 0->1 TORWeazel Bandwidth=98 0->1 HelloWorld Bandwidth=820 1->0 smallegyptrela01 Bandwidth=22 1->0 AnonNodeFin69 Bandwidth=80 0->1 Serveur Bandwidth=703 0->1 Biverse Bandwidth=779 0->1 comaTor1 Bandwidth=148 0->1 Unnamed Bandwidth=138 1->0
Gained bw: 20034 Lost bw: 5637
Tom
(source of this data: https://paste.debian.net/360256/)
Why not make the rule: "at least one of 80/6667, and at least one of 443/5222".
Also sounds good to me. I opted for the smallest possible change (6667->5222) but what you're suggesting lgtm.
I am also concerned about the choice of XMMP "because the XMPP protocol is slowly gaining popularity within the communities on the internet". Shouldn't we focus on secure protocols that are widely used right now?
Alternately, we could add other widely used SSL ports in addition to XMMP, and perhaps increase the rule to "at least two SSL ports".
Imho the challenge is in finding port number(s) that accurately reflect what Tor is for, while also having a sufficiently large user base for it to be relevant. XMPP probably has more users than IRC, and is a good match for what I think Tor would consider important (communication). Also note that we now have Tor Messenger. Other protocols (SSH, IMAP, POP3, SMTP) are indeed more popular but I feel that those less reflect the goals of the project, and they are certainly abused more.
80/443 get us anonymous web browsing, primarily through Tor Browser 6667/6697 get us anonymous messaging via IRC (I don't know if 6697 is common enough to be worth changing for.) 5222 get us anonymous messaging via Tor Messenger
I can't think of any others right now.
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP 968F094B
teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Interesting thought.
I've followed git history a bit (back then it was svn) and traced it back to 54a6a8f0 (tor.git). It's added to a function "router_is_general_exit" which is described as:
/** Return true iff <b>ri</b> is "useful as an exit node." */
Port 6667 is later chosen by Roger in 0ac3c584, the commit message doesn't describe why.
In 19408cf8, code is added to check that at least *two* ports are allowed.
Note that all of these happened about 10 years ago. I'd like to hear from Roger/Nick what their opinion is on flagging any exit node with the Exit flag, instead of just the ones that exit on some common ports.
It seems that doing this will result in adding a significant amount of exit relays, many of them quite useful: https://paste.debian.net/360365/
(Obviously) no exits will be dropped from the consensus if we choose to do that.
Tom
PS: Big fan of this relay: Pushkin Bandwidth=3190 21,23,25,80,110,143
Op 05/01/16 om 20:15 schreef Virgil Griffith:
Other protocols (SSH, IMAP, POP3, SMTP) are indeed more popular but I feel that those less reflect the goals of the project, and they are certainly abused more.
I hear you that these are abused more. But I personally think of Tor as a mere mechanism than a mechanism+policy. For example, should the command "rm" refuse to remove a file that has the text in it that says "IMPORTANT! DO NOT DELETE!" Although obviously this is a well-intentioned feature, presumably rm should not behave this way. The rm command is a mechanism, the policy for that mechanism judicious use is a wrapping around the command itself.
One additional benefit of separating mechanism from policy is that it makes policies more easily changeable. Well-meaning people have disagreements on policies, and policies invariably evolve. Separating policies from the core functionality is helpful to allow easier experimentation with alternative policies.
Applying this here, I argue that the ports a relay makes available should not impact whether they get the exit flag. This is consistent with treating Tor as a mechanism instead of applying top-down a policy for how people are "supposed" to use it.
-V
On Wed, Jan 6, 2016 at 2:25 AM Tom van der Woerdt <info@tvdw.eu mailto:info@tvdw.eu> wrote:
Op 05/01/16 om 10:22 schreef Tim Wilson-Brown - teor: > >> On 5 Jan 2016, at 19:33, Tom van der Woerdt <info@tvdw.eu <mailto:info@tvdw.eu> >> <mailto:info@tvdw.eu <mailto:info@tvdw.eu>>> wrote: >> ... >> Op 05/01/16 om 02:15 schreef Tim Wilson-Brown - teor: >>> >>>> On 5 Jan 2016, at 11:29, Tom van der Woerdt <info@tvdw.eu <mailto:info@tvdw.eu> >>>> <mailto:info@tvdw.eu <mailto:info@tvdw.eu>> >>>> <mailto:info@tvdw.eu <mailto:info@tvdw.eu>>> wrote: >>>> ... >>>> 2.1. Exit flagging >>>> >>>> By replacing the port 6667 (IRC) entry with a port 5222 (XMPP) entry, >>>> Exit >>>> flags can no longer be assigned to relays that exit only to unencrypted >>>> ports. >>> >>> One consequence of this proposal is that relays that only exit to 443 >>> and 6667 will lose the Exit flag. >>> But these relays do exit to an encrypted port, so this somewhat >>> contradicts the goal of the proposal: >>> "Exit flags can no longer be assigned to relays that exit only to >>> unencrypted ports." >> >> ... >> >> (tlcr: any relay that currently holds an Exit flag and allows exiting to >> 443 and 6667, but not 80 or 5222.) >> >> tiggersWeltTor1 Bandwidth=2600 >> smallegyptrela01 Bandwidth=22 >> >> These two relays will be impacted, indeed. > > Point taken! > > How many Exits would lose the Exit flag intentionally based on this change? > (That is, how many have 80 & 6667, but not 443?) If we change 6667 to 5222, this changes (where 0->1 means it will become an exit and 1->0 means it will no longer be one) : FruityOatyTorexit Bandwidth=17700 0->1 Alice Bandwidth=25 0->1 tiggersWeltTor1 Bandwidth=3100 1->0 onionnetGOT01 Bandwidth=387 0->1 icubdw2o2xipsdc Bandwidth=137 1->0 miepernl Bandwidth=1420 1->0 ReservoirPi2016 Bandwidth=114 0->1 TORWeazel Bandwidth=98 0->1 HelloWorld Bandwidth=820 1->0 smallegyptrela01 Bandwidth=22 1->0 AnonNodeFin69 Bandwidth=80 0->1 Serveur Bandwidth=703 0->1 Biverse Bandwidth=779 0->1 comaTor1 Bandwidth=148 0->1 Unnamed Bandwidth=138 1->0 Gained bw: 20034 Lost bw: 5637 Tom (source of this data: https://paste.debian.net/360256/) > >>> >>> Why not make the rule: "at least one of 80/6667, and at least one of >>> 443/5222". >> >> Also sounds good to me. I opted for the smallest possible change >> (6667->5222) but what you're suggesting lgtm. >> >>> >>> I am also concerned about the choice of XMMP "because the XMPP protocol >>> is slowly gaining popularity within the >>> communities on the internet". >>> Shouldn't we focus on secure protocols that are widely used right now? >>> >>> Alternately, we could add other widely used SSL ports in addition to >>> XMMP, and perhaps increase the rule to "at least two SSL ports". >> >> Imho the challenge is in finding port number(s) that accurately reflect >> what Tor is for, while also having a sufficiently large user base for it >> to be relevant. XMPP probably has more users than IRC, and is a good >> match for what I think Tor would consider important (communication). >> Also note that we now have Tor Messenger. Other protocols (SSH, IMAP, >> POP3, SMTP) are indeed more popular but I feel that those less reflect >> the goals of the project, and they are certainly abused more. > > 80/443 get us anonymous web browsing, primarily through Tor Browser > 6667/6697 get us anonymous messaging via IRC > (I don't know if 6697 is common enough to be worth changing for.) > 5222 get us anonymous messaging via Tor Messenger > > I can't think of any others right now. > > Tim > > Tim Wilson-Brown (teor) > > teor2345 at gmail dot com > PGP 968F094B > > teor at blah dot im > OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F > > > > _______________________________________________ > tor-dev mailing list > tor-dev@lists.torproject.org <mailto:tor-dev@lists.torproject.org> > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org <mailto:tor-dev@lists.torproject.org> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
On 01/05/2016 01:29 AM, Tom van der Woerdt wrote:
communities on the internet. Other popular ports have been considered, such as 22 (SSH), 465 (SMTP), or 995 (POP3), but these are unlikely to be good candidates because of wide spread bruteforce attacks on these ports.
Just as a data point, I don't see much scanning/abuse regarding SMTPS (465) or IMAPS (993).
Tom, to ensure I understand you clearly, is your argument that relays that export only unencrypted shouldn't get the Exit Flag because insecure/unecrypted traffic "isn't what Tor is intended for?" I want to be sure that I'm fully understanding your proposal.
-V On Wed, 6 Jan 2016 at 17:57 Moritz Bartl moritz@torservers.net wrote:
On 01/05/2016 01:29 AM, Tom van der Woerdt wrote:
communities on the internet. Other popular ports have been considered, such as 22 (SSH), 465 (SMTP), or 995 (POP3), but these are unlikely to
be good
candidates because of wide spread bruteforce attacks on these ports.
Just as a data point, I don't see much scanning/abuse regarding SMTPS (465) or IMAPS (993).
-- Moritz Bartl https://www.torservers.net/ _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
On 6 Jan 2016, at 21:26, Virgil Griffith i@virgil.gr wrote:
Tom, to ensure I understand you clearly, is your argument that relays that export only unencrypted shouldn't get the Exit Flag because insecure/unecrypted traffic "isn't what Tor is intended for?" I want to be sure that I'm fully understanding your proposal.
If adversaries can set up Exit relays that only permit insecure/unecrypted traffic, then they can inspect/interfere with all the traffic going through that Exit. As can any adversary that is on the upstream path from that Exit.
If we ensure that Exits must pass some encrypted traffic, then running an Exit is less attractive to an adversary. And even adversaries contribute useful, secure bandwidth to the Tor Network.
So this policy is intended to protect users, and encourage non-adversarial contributions to network bandwidth. (Given the small number of Exits flags affected by this change, I'm not sure if this policy is responsible for all the good Exits, or if our exit-checking tools are responsible.)
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP 968F094B
teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
On Wed, Jan 06, 2016 at 10:21:31PM +1100, Tim Wilson-Brown - teor wrote:
On 6 Jan 2016, at 21:26, Virgil Griffith i@virgil.gr wrote:
Tom, to ensure I understand you clearly, is your argument that relays that export only unencrypted shouldn't get the Exit Flag because insecure/unecrypted traffic "isn't what Tor is intended for?" I want to be sure that I'm fully understanding your proposal.
If adversaries can set up Exit relays that only permit insecure/unecrypted traffic, then they can inspect/interfere with all the traffic going through that Exit. As can any adversary that is on the upstream path from that Exit.
If we ensure that Exits must pass some encrypted traffic, then running an Exit is less attractive to an adversary. And even adversaries contribute useful, secure bandwidth to the Tor Network.
Modulo them not simply setting up an acceptable policy but then just dropping all (much) actual traffic for the ports they didn't really want. (And correct attribution and sanctioning for non/incomplete performing are hard.) As always, if the adversarial goal is monitoring, it is typically just easier (and not too expensive) to genuinely provide the service that gets you the flags, but yes this could still be an improvement vs. status quo.
aloha, Paul
So this policy is intended to protect users, and encourage non-adversarial contributions to network bandwidth. (Given the small number of Exits flags affected by this change, I'm not sure if this policy is responsible for all the good Exits, or if our exit-checking tools are responsible.)
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP 968F094B
teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Quoting Tim Wilson-Brown - teor teor2345@gmail.com:
If we ensure that Exits must pass some encrypted traffic, then running an Exit is less attractive to an adversary.
I'd argue that it's marginally less attractive. They still have the opportunity to inspect some unencrypted traffic.
And even adversaries contribute useful, secure bandwidth to the Tor Network.
This could also potentially backfire: adversaries can create local (non-tor) policies to throttle encrypted exit traffic, while not throttling unencrypted traffic.
Peter..
I would argue that the existence of this longer policy discussion, with no obvious solution, is why it behoves us to separate policy (as much as possible) from Tor's core mechanism.
-V On Wed, 6 Jan 2016 at 21:42 Peter Tonoli peter+tor@metaverse.org wrote:
Quoting Tim Wilson-Brown - teor teor2345@gmail.com:
If we ensure that Exits must pass some encrypted traffic, then running an Exit is less attractive to an adversary.
I'd argue that it's marginally less attractive. They still have the opportunity to inspect some unencrypted traffic.
And even adversaries contribute useful, secure bandwidth to the Tor
Network.
This could also potentially backfire: adversaries can create local (non-tor) policies to throttle encrypted exit traffic, while not throttling unencrypted traffic.
Peter..
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
On 7 Jan 2016, at 02:23, Virgil Griffith i@virgil.gr wrote:
I would argue that the existence of this longer policy discussion, with no obvious solution, is why it behoves us to separate policy (as much as possible) from Tor's core mechanism.
As far as I understand the code, clients choose exit relays based on their exit policies, not the exit flag. The exit flag is used for bandwidth weight load-balancing and logging during bootstrap, but that's about all.
So I'm not sure this proposal will have any effect on the Tor network, apart from perhaps a minor social effect if people are seeking flags for their relays. (Nor will it have much effect on policy, except, again, for a minor social effect.)
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP 968F094B
teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F
On Wed, Jan 6, 2016 at 4:56 AM, Moritz Bartl moritz@torservers.net wrote:
Just as a data point, I don't see much scanning/abuse regarding SMTPS (465)
SUBMISSION (567) is what is used these days as relay to send mail. 465 is a legacy bug. 25 fronts your @address. See wikipedia for more info.
or IMAPS (993).
POP3S (995) still holds significant userbase even though it could be considered a subset of what imap can do.
-
grarpamp -
Moritz Bartl -
ncl＠cock.li -
Paul Syverson -
Peter Tonoli -
Tim Wilson-Brown - teor -
Tom van der Woerdt -
Virgil Griffith