Re: [tor-talk] Please Remove Tor bridge and... from Censorship countries.

[Seth David Schoen]

Jason Long writes:

> Not from ISP!! It is so bad because ISPs are under 
> governments control. If an ISP can see I use Tor then it is a good evidence 
> in censorship countries.You said " If a government is running the bridge, it 
> will know where the users are who are using that particular bridge.", In your 
> idea it is not silly? I mean was it and Tor must ban it.

My point is that people in other countries could still benefit from these
services, especially if they don't mind as much that the government of a
country where they don't live knows something about their Tor traffic.
For example, if I live in Germany, maybe I am more comfortable with my
Tor circuits going through Iran, compared to someone who lives in Iran
who is unhappy about that.  Both people might agree that the Iranian
government probably spies on the Tor network in a way they disagree
with, but the person who lives in Iran may see this as a very practical
important thing to worry about, while the perhaps who lives in Germany
may think it's not as practically important.  Or maybe someone living
in Argentina is trying to hide their location from a particular person,
but not from the government, and doesn't really mind if their data goes
through Tor nodes in their own country.

If you're using bridges to hide the fact that you use Tor at all, you
need some way to know if the particular bridges and technologies you
use can accomplish that goal.  That might include knowing the person
or organization who runs the bridge that you use.  If you use bridges
that are run by unknown people, you get a much greater risk that those
bridges are maliciously tracking your use of Tor, regardless of what
country they're physically located in.

I totally agree that surveillance by ISPs and governments is very serious
and very disturbing.  Tor's design is partly about letting people use
resources that are "somewhere else" so that perhaps they're not under
surveillance by the user's own government or ISP, or aren't all under
surveillance by the same people.  This will probably work less well
overall if the Tor developers try to single out particular countries as
extra-bad so that they can't participate in Tor at all.  That would mean
fewer countries overall participating in Tor, and an easier time for
people trying to do surveillance in the somewhat-less-bad countries.
And it would mean fewer choices for users about where to send their
traffic.

One thing that might be useful would be a way for Tor users to actively
pick what jurisdictions (or fiber optic cables or Internet exchange
points) they do or don't want their data to pass through, and have the
Tor client respect those preferences.  This is helpful both because
individual Tor users believe different things and because they have
different threat models.  I believe there's an old mechanism in the
torrc configuration file to avoid using nodes in particular countries,
but very few Tor users use this or understand how to use it.  Maybe it
could be made clearer and more convenient and integrated with the Tor
Browser interface in some way.

-- 
Seth Schoen  
Senior Staff Technologist   https://www.eff.org/
Electronic Frontier Foundation  https://www.eff.org/join
815 Eddy Street, San Francisco, CA  94109   +1 415 436 9333 x107
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Please Remove Tor bridge and... from Censorship countries.

[Jason Long]

Not from ISP!! It is so bad because ISPs are under 
governments control. If an ISP can see I use Tor then it is a good evidence in 
censorship countries.You said " If a government is running the bridge, it will 
know where the users are who are using that particular bridge.", In your idea 
it is not silly? I mean was it and Tor must ban it.

On Monday, November 7, 2016 12:08 AM, Seth David Schoen  
wrote:
 

 Jason Long writes:

> You said the governments can see a user bandwidth usage and it is so bad 
> because they can understand a user use Tor for regular web surfing or use it 
> for upload files and...  
> You said governments can see users usages but not contents but how they can 
> find specific users if Tor hide my IP?!!

Tor hides your IP address from the sites you're communicating with,
but not from your own ISP (for example), or from the Tor bridge or guard
node that you use.

In the original design of Tor there was absolutely no attempt to hide
who is using Tor, only what they are doing with it.  One idea was that
lots of people should use Tor for lots of things, so that it will be
hard to guess why a particular person uses Tor.

In the case of bridges for anticensorship, there is also some attempt
to hide who is using Tor (especially because of the idea that using
Tor can be forbidden or blocked in certain countries).  If a particular
bridge technology is unblocked, maybe the government doesn't know how
to detect it yet, so maybe they don't know who the Tor users who use
that technology are.  If a government is running the bridge, it will
know where the users are who are using that particular bridge.

-- 
Seth Schoen  
Senior Staff Technologist                      https://www.eff.org/
Electronic Frontier Foundation                  https://www.eff.org/join
815 Eddy Street, San Francisco, CA  94109      +1 415 436 9333 x107
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk


   
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Timing attacks and fingerprinting users based of timestamps

[Seth David Schoen]

Flipchan writes:

> So i was thinking about timing attacks and simular attacks where time is a 
> Big factor when deanonymizing users . 
> and created a Little script that will generate a ipv4 address and send a get 
> request to that address 
> https://github.com/flipchan/Nohidy/blob/master/traffic_gen.py then delay x 
> amount of seconds and do it again. This will probelly make it harder for the 
> attacker to fingerprint the users output data due to the increased data flow 
> coming out from the server. 
> 
> So to protect against traffic timing attacks and simular would be to generate 
> More data.

This is called padding traffic and it's been studied a bit in relation
to systems like Tor.  Roger has often said that a conclusion of the
studies was that it's hard to get a lot of privacy benefit from most
padding schemes, but it might be good to know what the state of the
art is in padding attacks and defenses.

-- 
Seth Schoen  
Senior Staff Technologist   https://www.eff.org/
Electronic Frontier Foundation  https://www.eff.org/join
815 Eddy Street, San Francisco, CA  94109   +1 415 436 9333 x107
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

[tor-talk] Timing attacks and fingerprinting users based of timestamps

[Flipchan]

So i was thinking about timing attacks and simular attacks where time is a Big 
factor when deanonymizing users . 
and created a Little script that will generate a ipv4 address and send a get 
request to that address 
https://github.com/flipchan/Nohidy/blob/master/traffic_gen.py then delay x 
amount of seconds and do it again. This will probelly make it harder for the 
attacker to fingerprint the users output data due to the increased data flow 
coming out from the server. 

So to protect against traffic timing attacks and simular would be to generate 
More data.

Has anyone else got any other solution for these kinds of attacks?

Take care
-- 
Sincerly flipchan 
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Please Remove Tor bridge and... from Censorship countries.

[Seth David Schoen]

Jason Long writes:

> You said the governments can see a user bandwidth usage and it is so bad 
> because they can understand a user use Tor for regular web surfing or use it 
> for upload files and...  
> You said governments can see users usages but not contents but how they can 
> find specific users if Tor hide my IP?!!

Tor hides your IP address from the sites you're communicating with,
but not from your own ISP (for example), or from the Tor bridge or guard
node that you use.

In the original design of Tor there was absolutely no attempt to hide
who is using Tor, only what they are doing with it.  One idea was that
lots of people should use Tor for lots of things, so that it will be
hard to guess why a particular person uses Tor.

In the case of bridges for anticensorship, there is also some attempt
to hide who is using Tor (especially because of the idea that using
Tor can be forbidden or blocked in certain countries).  If a particular
bridge technology is unblocked, maybe the government doesn't know how
to detect it yet, so maybe they don't know who the Tor users who use
that technology are.  If a government is running the bridge, it will
know where the users are who are using that particular bridge.

-- 
Seth Schoen  
Senior Staff Technologist   https://www.eff.org/
Electronic Frontier Foundation  https://www.eff.org/join
815 Eddy Street, San Francisco, CA  94109   +1 415 436 9333 x107
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Tor 0.2.9.4-alpha is released

[Nick Mathewson]

On Sun, Nov 6, 2016 at 7:35 AM, Dash Four  wrote:
> Hi Nick,
>
>
> First time this happens (I have been compiling tor sources with this
> compiler since around 2009). Not sure about using the -Wlogical-op warning
> though.
>
> Here is what I get:
>
> ==
> gcc -std=gnu99 -DHAVE_CONFIG_H -I.  -I./src/ext -Isrc/ext
> -I./src/ext/trunnel -I./src/trunnel -I./src/common -Isrc/common
> -I./src/ext/trunnel -I./src/trunnel -I./src/or -Isrc/or
> -DSHARE_DATADIR="\"/usr/share\"" -DLOCALSTATEDIR="\"/var\""
> -DBINDIR="\"/usr/bin\"" -I./src/common-ftrapv   -O2 -g -pipe -Wall
> -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
> --param=ssp-buffer-size=4 -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
> -m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables -U_FORTIFY_SOURCE
> -D_FORTIFY_SOURCE=2 -fstack-protector-all -Wstack-protector --param
> ssp-buffer-size=1 -fPIE -fno-omit-frame-pointer -fasynchronous-unwind-tables
> -Wall -fno-strict-aliasing -Waddress -Warray-bounds -Wextra -Winit-self
> -Wlogical-op -Wmissing-field-initializers -Wmissing-format-attribute
> -Wmissing-noreturn -Wnormalized=id -Woverlength-strings -Woverride-init
> -Wshadow -Wstrict-overflow=2 -Wsync-nand -Wunused-but-set-parameter
> -Wunused-but-set-variable -Wvariadic-macros -W -Wfloat-equal -Wundef
> -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wwrite-strings
> -Wredundant-decls -Wchar-subscripts -Wcomment -Wformat=2 -Wwrite-strings
> -Wnested-externs -Wbad-function-cast -Wswitch-enum -Waggregate-return
> -Wpacked -Wunused -Wunused-parameter  -Wold-style-definition
> -Wmissing-declarations -Werror -c -o src/common/util.o src/common/util.c
> cc1: warnings being treated as errors
> src/common/util.c: In function 'tor_strstrip':
> src/common/util.c:643: error: logical '&&' with non-zero constant will
> always evaluate as true
> src/common/util.c: In function 'tor_escape_str_for_pt_args':
> src/common/util.c:1397: error: logical '&&' with non-zero constant will
> always evaluate as true
> src/common/util.c: In function 'str_num_before':
> src/common/util.c:4730: error: logical '&&' with non-zero constant will
> always evaluate as true
> make[1]: *** [src/common/util.o] Error 1
> make[1]: *** Waiting for unfinished jobs
> make[1]: Leaving directory `/builddir/build/BUILD/tor-0.2.9.4-alpha'
> make: *** [all] Error 2
> error: Bad exit status from /var/tmp/rpm-tmp.fmqO31 (%build)
> ==
>
> util.c:643:
> if (strchr(strip, *readp)) {
>
> util.c:1397:
> if (strchr(chars_to_escape, *string))
>
> util.c:4730:
>   const char *cp = strchr(s, ch);
>
>
> This link [1] may offer some explanation/workaround (I know it is for a
> different - older - version of gcc, but the point still stands).
>
> For the time being, I use "tor_cv_cflags_Wlogical_op=no" to disable this
> warning, but I am not sure whether this is the correct way of dealing with
> the issue.
>
>
> [1] http://seclists.org/wireshark/2013/Jan/6

Yeah -- my guess here is that you have a version of GCC that is either
much older or much newer than your version of glibc.  Turning off the
warning is a perfectly fine solution.

best wishes,
-- 
Nick
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Please Remove Tor bridge and... from Censorship countries.

[Jason Long]

You said the governments can see a user bandwidth usage and it is so bad 
because they can understand a user use Tor for regular web surfing or use it 
for upload files and...  
You said governments can see users usages but not contents but how they can 
find specific users if Tor hide my IP?!!

On Sat, 11/5/16, Seth David Schoen  wrote:

 Subject: Re: [tor-talk] Please Remove Tor bridge and... from Censorship 
countries.
 To: tor-talk@lists.torproject.org
 Date: Saturday, November 5, 2016, 11:36 PM
 
 Jason Long writes:
 
 > Hello Tor Developers and administrator.The
 Tor goal is provide Secure web surfing as free and Freedom
 but unfortunately some countries like Iran, China, North
 Korea and... Launch Tor bridges for spying on users and
 sniff their traffics and it is so bad and decrease Tor users
 and security. If Tor Project goal is Freedom and Anti
 Censorship then it must ban all bridges and Servers from
 those countries. Please consider it and do a serious
 job.
 
 Tor's
 approach to this issue is generally to look for
 ever-greater
 geographic diversity of
 servers.
 
 The Tor design
 assumes that there could be monitoring of servers in a
 particular network, but hopes that this
 won't be a big problem because
 most
 organizations monitoring Tor nodes can only see a part of
 the
 overall network.  In that case, they
 can hopefully only see a part of
 the path
 that a particular user's traffic takes, so they may not
 know
 where the user is and also whom the
 user is communicating with (though
 they
 might know one or the other).
 
 In this model, it's not necessarily bad to
 have nodes on networks that
 are hostile --
 because the people doing the monitoring get incomplete
 information.  At the same time, having nodes
 in many places can decrease
 how complete a
 picture any one network operator or government can get.
 For example, suppose that the U.S. government,
 the Chinese government,
 and the Iranian
 government are all trying to spy on Tor users whose
 traffic passes through their territory, but the
 governments don't directly
 cooperate
 with each other.  In that case, having a user use nodes in
 all
 3 jurisdictions is probably great for
 anonymity because each jurisdiction
 to some
 extent protects facts about the user's activity from the
 other
 jurisdictions, and it's hard for
 anyone to put the whole picture together.
 
 If people want to hide the
 fact that they're using Tor at all, and are
 using bridges for that reason, they probably
 should not use bridges
 inside their own
 country.  But those bridges could be useful to people
 in other countries who aren't trying to
 hide from the same adversary.
 
 If an exit node is unable to reach a lot of
 network resources because
 of censorship on
 the network where it's located, it should be possible
 to detect this through scanning and flag it as
 a BadExit so that clients
 will avoid using
 it in that role.
 
 There's still a problem when network
 operators pool their information or
 when
 governments can monitor networks outside of their own
 territory.
 This is a practical problem for
 path selection and also for assessing
 how
 much privacy Tor can actually provide against a particular
 adversary.
 For instance, if the U.K.
 government taps enough of the world's Internet
 links, or trades data about Tor users with
 other governments, it might
 be able to learn
 a lot about a high fraction of Tor users even if they
 don't use nodes that are in the U.K.  That
 could be hard to fix without
 adopting a
 different anonymity design or finding a way to prevent
 these
 taps and exchanges of data.
 
 People have been thinking
 about that kind of issue quite a bit, like in
 
 
https://www.nrl.navy.mil/itd/chacs/biblio/users-get-routed-traffic-correlation-tor-realistic-adversaries
 
 and other research projects,
 and to my mind the news isn't necessarily
 that good.  But the key point is that having
 nodes on an unfriendly
 network isn't
 necessarily bad in itself unless that network actually
 sees interesting data as a result (or actively
 disrupts traffic in a way
 that doesn't
 get blacklisted from clients' path selection).  And
 that can
 sometimes happen, but doesn't
 always have to happen, and people on other
 networks can still get a potential privacy or
 anticensorship benefit in
 the meantime.
 
 Notice that this argument
 doesn't depend on saying that what governments
 are doing is OK, or that they don't have
 ill will toward the Tor network
 or
 particular Tor users.  It also doesn't prove that
 governments will
 fail to monitor the
 network; there's a lot of uncertainty about how
 effective governments' capabilities in this
 area are.
 
 Finally,
 there's an issue about identifying which nodes are
 secretly
 run by the same organizations (or
 secretly monitored by the same
 organizations!) which fail to admit it.  This
 is a form of Sybil attack,
 where one entity
 

Re: [tor-talk] Tor 0.2.9.4-alpha is released

[Dash Four]

Hi Nick,


First time this happens (I have been compiling tor sources with this compiler 
since around 2009). Not sure about using the -Wlogical-op warning though.

Here is what I get:

==
gcc -std=gnu99 -DHAVE_CONFIG_H -I.  -I./src/ext -Isrc/ext -I./src/ext/trunnel -I./src/trunnel -I./src/common -Isrc/common -I./src/ext/trunnel -I./src/trunnel 
-I./src/or -Isrc/or -DSHARE_DATADIR="\"/usr/share\"" -DLOCALSTATEDIR="\"/var\"" -DBINDIR="\"/usr/bin\"" -I./src/common-ftrapv   -O2 -g -pipe -Wall 
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m32 -march=i686 -mtune=atom 
-fasynchronous-unwind-tables -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fstack-protector-all -Wstack-protector --param ssp-buffer-size=1 -fPIE 
-fno-omit-frame-pointer -fasynchronous-unwind-tables -Wall -fno-strict-aliasing -Waddress -Warray-bounds -Wextra -Winit-self -Wlogical-op 
-Wmissing-field-initializers -Wmissing-format-attribute -Wmissing-noreturn -Wnormalized=id -Woverlength-strings -Woverride-init -Wshadow -Wstrict-overflow=2 
-Wsync-nand -Wunused-but-set-parameter -Wunused-but-set-variable -Wvariadic-macros -W -Wfloat-equal -Wundef -Wpointer-arith -Wstrict-prototypes 
-Wmissing-prototypes -Wwrite-strings -Wredundant-decls -Wchar-subscripts -Wcomment -Wformat=2 -Wwrite-strings -Wnested-externs -Wbad-function-cast -Wswitch-enum 
-Waggregate-return -Wpacked -Wunused -Wunused-parameter  -Wold-style-definition -Wmissing-declarations -Werror -c -o src/common/util.o src/common/util.c

cc1: warnings being treated as errors
src/common/util.c: In function 'tor_strstrip':
src/common/util.c:643: error: logical '&&' with non-zero constant will always 
evaluate as true
src/common/util.c: In function 'tor_escape_str_for_pt_args':
src/common/util.c:1397: error: logical '&&' with non-zero constant will always 
evaluate as true
src/common/util.c: In function 'str_num_before':
src/common/util.c:4730: error: logical '&&' with non-zero constant will always 
evaluate as true
make[1]: *** [src/common/util.o] Error 1
make[1]: *** Waiting for unfinished jobs
make[1]: Leaving directory `/builddir/build/BUILD/tor-0.2.9.4-alpha'
make: *** [all] Error 2
error: Bad exit status from /var/tmp/rpm-tmp.fmqO31 (%build)
==

util.c:643:
if (strchr(strip, *readp)) {

util.c:1397:
if (strchr(chars_to_escape, *string))

util.c:4730:
  const char *cp = strchr(s, ch);


This link [1] may offer some explanation/workaround (I know it is for a 
different - older - version of gcc, but the point still stands).

For the time being, I use "tor_cv_cflags_Wlogical_op=no" to disable this 
warning, but I am not sure whether this is the correct way of dealing with the issue.


[1] http://seclists.org/wireshark/2013/Jan/6


Nick Mathewson wrote:

On Sat, Oct 22, 2016 at 10:27 PM, Dash Four  wrote:

Nick Mathewson wrote:

Hi, all!  There is a new alpha release of the Tor source code, with
fixes for a security bug. You should probably upgrade as packages
become available.


I am having trouble compiling this version. I get the WLogical-op warning
and "logical '&&' with non-zero constant will always evaluate as true" error
message.

The "offending" file is util.c:643, util.c:1397 and util.c4730.

Quick look at ./configure and Google search tells me to use
"tor_cv_cflags_Wlogical_op=no", and if I use that all is well (compiles OK,
haven't run this yet), but I am not sure whether that's right.

My compiler is pretty old (GCC 4.4.5-2), so that might be what is causing
this issue.


If I'm reading that right, that line is just a strchr() call?  Do all
the glibc strchr() calls have this problem with your gcc and
-Wlogical-op ?



--
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

Re: [tor-talk] Please Remove Tor bridge and... from Censorship countries.

[Seth David Schoen]

Jason Long writes:

> Hello Tor Developers and administrator.The Tor goal is provide Secure web 
> surfing as free and Freedom but unfortunately some countries like Iran, 
> China, North Korea and... Launch Tor bridges for spying on users and sniff 
> their traffics and it is so bad and decrease Tor users and security. If Tor 
> Project goal is Freedom and Anti Censorship then it must ban all bridges and 
> Servers from those countries. Please consider it and do a serious job.

Tor's approach to this issue is generally to look for ever-greater
geographic diversity of servers.

The Tor design assumes that there could be monitoring of servers in a
particular network, but hopes that this won't be a big problem because
most organizations monitoring Tor nodes can only see a part of the
overall network.  In that case, they can hopefully only see a part of
the path that a particular user's traffic takes, so they may not know
where the user is and also whom the user is communicating with (though
they might know one or the other).

In this model, it's not necessarily bad to have nodes on networks that
are hostile -- because the people doing the monitoring get incomplete
information.  At the same time, having nodes in many places can decrease
how complete a picture any one network operator or government can get.
For example, suppose that the U.S. government, the Chinese government,
and the Iranian government are all trying to spy on Tor users whose
traffic passes through their territory, but the governments don't directly
cooperate with each other.  In that case, having a user use nodes in all
3 jurisdictions is probably great for anonymity because each jurisdiction
to some extent protects facts about the user's activity from the other
jurisdictions, and it's hard for anyone to put the whole picture together.

If people want to hide the fact that they're using Tor at all, and are
using bridges for that reason, they probably should not use bridges
inside their own country.  But those bridges could be useful to people
in other countries who aren't trying to hide from the same adversary.

If an exit node is unable to reach a lot of network resources because
of censorship on the network where it's located, it should be possible
to detect this through scanning and flag it as a BadExit so that clients
will avoid using it in that role.

There's still a problem when network operators pool their information or
when governments can monitor networks outside of their own territory.
This is a practical problem for path selection and also for assessing
how much privacy Tor can actually provide against a particular adversary.
For instance, if the U.K. government taps enough of the world's Internet
links, or trades data about Tor users with other governments, it might
be able to learn a lot about a high fraction of Tor users even if they
don't use nodes that are in the U.K.  That could be hard to fix without
adopting a different anonymity design or finding a way to prevent these
taps and exchanges of data.

People have been thinking about that kind of issue quite a bit, like in

https://www.nrl.navy.mil/itd/chacs/biblio/users-get-routed-traffic-correlation-tor-realistic-adversaries

and other research projects, and to my mind the news isn't necessarily
that good.  But the key point is that having nodes on an unfriendly
network isn't necessarily bad in itself unless that network actually
sees interesting data as a result (or actively disrupts traffic in a way
that doesn't get blacklisted from clients' path selection).  And that can
sometimes happen, but doesn't always have to happen, and people on other
networks can still get a potential privacy or anticensorship benefit in
the meantime.

Notice that this argument doesn't depend on saying that what governments
are doing is OK, or that they don't have ill will toward the Tor network
or particular Tor users.  It also doesn't prove that governments will
fail to monitor the network; there's a lot of uncertainty about how
effective governments' capabilities in this area are.

Finally, there's an issue about identifying which nodes are secretly
run by the same organizations (or secretly monitored by the same
organizations!) which fail to admit it.  This is a form of Sybil attack,
where one entity pretends to be many different entities.  If a government
set up many ostensibly unrelated nodes, and clients believed they were
actually unrelated, it would increase the chance that a given Tor user
used several of those nodes for the same circuit, decreasing anonymity.
Tor can probably do better about detecting this.  It's not certain that
blacklisting countries would help much with this, because we don't know
which governments are attempting this to what degrees, and because they
don't have to host their nodes on IP addresses in their own jurisdiction!
If the North Korean government wants to do this sort of attack, it can
pay to set up a bunch of servers in France and Germany, which users and

Re: [tor-talk] Please Remove Tor bridge and... from Censorship countries.

[Jason Long]

Any idea? 

On Wednesday, November 2, 2016 7:30 PM, Jason Long  
wrote:
 

 Hello Tor Developers and administrator.The Tor goal is provide Secure web 
surfing as free and Freedom but unfortunately some countries like Iran, China, 
North Korea and... Launch Tor bridges for spying on users and sniff their 
traffics and it is so bad and decrease Tor users and security. If Tor Project 
goal is Freedom and Anti Censorship then it must ban all bridges and Servers 
from those countries. Please consider it and do a serious job.

Thank you.

   
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk