[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-dev] Proposal: Stop giving Exit flags when only unencrypted traffic can exit
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@xxxxxxx
> <mailto:info@xxxxxxx>> 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@xxxxxxx
> <mailto:info@xxxxxxx>
> >> <mailto:info@xxxxxxx <mailto:info@xxxxxxx>>> 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@xxxxxxx
> <mailto:info@xxxxxxx>
> >>>> <mailto:info@xxxxxxx <mailto:info@xxxxxxx>>
> >>>> <mailto:info@xxxxxxx <mailto:info@xxxxxxx>>> 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@xxxxxxxxxxxxxxxxxxxx <mailto:tor-dev@xxxxxxxxxxxxxxxxxxxx>
> > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
> >
>
> _______________________________________________
> tor-dev mailing list
> tor-dev@xxxxxxxxxxxxxxxxxxxx <mailto:tor-dev@xxxxxxxxxxxxxxxxxxxx>
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>
>
>
> _______________________________________________
> tor-dev mailing list
> tor-dev@xxxxxxxxxxxxxxxxxxxx
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev