Re: [tor-dev] Proposal: Stop giving Exit flags when only unencrypted traffic can exit

[Tom van der Woerdt]

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 > > 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
> 
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Proposal: Stop giving Exit flags when only unencrypted traffic can exit

[Tim Wilson-Brown - teor]

> On 5 Jan 2016, at 19:33, Tom van der Woerdt  wrote:
> ...
> Op 05/01/16 om 02:15 schreef Tim Wilson-Brown - teor:
>> 
>>> On 5 Jan 2016, at 11:29, Tom van der Woerdt >> > 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



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Applications Team meeting today (Tuesday Jan 5) 19:00 UTC

[Mike Perry]

Hi,

Just a reminder that the applications team is having its monthly meeting
today at 19:00 UTC in #tor-project on irc.oftc.net.

We'll likely recap the State of the Onion, and generally talk about
UI/UX as per usual.

Please come up with suggestions if you feel there is something else we
should discuss.

-- 
Mike Perry


signature.asc
Description: Digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] [Win32] test_util.c + test_checkdir.c

[Gisle Vanem]

The src/test/test_util.c have this statement:

 #ifdef _WIN32
 #define UTIL_TEST_NO_WIN(n, f) { #n, NULL, TT_SKIP, NULL, NULL }
 #define UTIL_TEST_WIN_ONLY(n, f) UTIL_TEST(n, (f))
 #define UTIL_LEGACY_NO_WIN(n) UTIL_NO_WIN(n)

But I fail to see where 'UTIL_NO_WIN(n)' is defined. Should not the
above read:

--- a/test/test_util.c 2016-01-05 13:19:07
+++ b/test/test_util.c 2016-01-05 14:36:52
@@ -4676,7 +4676,7 @@
 #ifdef _WIN32
 #define UTIL_TEST_NO_WIN(n, f) { #n, NULL, TT_SKIP, NULL, NULL }
 #define UTIL_TEST_WIN_ONLY(n, f) UTIL_TEST(n, (f))
-#define UTIL_LEGACY_NO_WIN(n) UTIL_NO_WIN(n)
+#define UTIL_LEGACY_NO_WIN(n)   { #n, NULL, TT_SKIP, NULL, NULL }
 #else
 #define UTIL_TEST_NO_WIN(n, f) UTIL_TEST(n, (f))

With this, my test.exe runs fine. Although 36 SKIPPED tests.

Another thing regarding MSVC. In test/test_checkdir.c,
 is included for _WIN32. MSVC does not have this header.
Hence I think this patch is needed:

--- a/test/test_checkdir.c 2015-08-31 13:24:33
+++ b/test/test_checkdir.c 2015-08-31 14:50:53
@@ -4,9 +4,7 @@
 #include "orconfig.h"
 #include "or.h"

-#ifdef _WIN32
-#include 
-#else
+#ifndef _MSC_VER
 #include 
 #endif

Since  is already included in "or.h", it's not needed here
too.

-- 
--gv
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Proposal: Stop giving Exit flags when only unencrypted traffic can exit

[Tom van der Woerdt]

Op 05/01/16 om 10:22 schreef Tim Wilson-Brown - teor:
> 
>> On 5 Jan 2016, at 19:33, Tom van der Woerdt > > wrote:
>> ...
>> Op 05/01/16 om 02:15 schreef Tim Wilson-Brown - teor:
>>>
 On 5 Jan 2016, at 11:29, Tom van der Woerdt >>> 
 > 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
> 



signature.asc
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Proposal: Stop giving Exit flags when only unencrypted traffic can exit

[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  wrote:

> Op 05/01/16 om 10:22 schreef Tim Wilson-Brown - teor:
> >
> >> On 5 Jan 2016, at 19:33, Tom van der Woerdt  >> > wrote:
> >> ...
> >> Op 05/01/16 om 02:15 schreef Tim Wilson-Brown - teor:
> >>>
>  On 5 Jan 2016, at 11:29, Tom van der Woerdt   
>  > 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
> >
> >
> >
> > 

Re: [tor-dev] Proposal: Stop giving Exit flags when only unencrypted traffic can exit

[Tom van der Woerdt]

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 ri 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  > wrote:
> 
> Op 05/01/16 om 10:22 schreef Tim Wilson-Brown - teor:
> >
> >> On 5 Jan 2016, at 19:33, Tom van der Woerdt  
> >> >> wrote:
> >> ...
> >> Op 05/01/16 om 02:15 schreef Tim Wilson-Brown - teor:
> >>>
>  On 5 Jan 2016, at 11:29, Tom van der Woerdt  
>  >
>  >> 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