Re: [tor-dev] Comparing Stem, metrics-lib, and zoossh

2015-10-01 Thread Karsten Loesing 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello Philipp and iwakeh, hello list,

Damian and I sat down yesterday at the dev meeting to talk about doing
a comparison of the various descriptor-parsing libraries with respect
to capabilities, run-time performance, memory usage, etc.

We put together a list of things we'd like to compare and tests we'd
like to run that we thought we'd want to share with you.  Damian and I
will both be working on these for metrics-lib for a short while and
then switch to Stem.  Please feel free to join us in these effort.
The result is supposed to live on Stem's home page unless somebody
comes up with a better place.

Thanks!

All the best,
Damian and Karsten


On 30/09/15 10:57, Karsten Loesing wrote:
> 1. capabilities - supported descriptor types - all the ones on
> CollecTor's formats.html - hidden service descriptors (have an
> agreed @type for that) - getting/producing descriptors - reading
> from file/directory - reading from tarballs - reading from
> CollecTor's .xz-compressed tarballs - fetching from CollecTor -
> downloading from directories (authorities or mirrors) - generating
> (for unit test) - recognizing @type annotation - inferencing from
> file name - keeping reading history - user documentation -
> validation (format, crypto, successful sanitization) - packages
> available - how much usage by (large) applications
> 
> 2. performance (CPU time, memory overhead) - compression:
> .xz-compressed tarballs/decompressed tarballs/plain-text -
> descriptor type: consensus, server descriptor, extra-info 
> descriptor, microdescriptors - validation: on or off (allows lazy
> loading)
> 
> 3. tests by descriptor type - @type server-descriptor 1.0 - Stem's
> "List Outdated Relays" - average advertised bandwidth - fraction of
> relays that can exit to port 80 - @type extra-info 1.0 - sum of all
> written and read bytes from write-history/read-history - number of
> countries from which v3 requests were received - @type
> network-status-consensus-3 - average number of relays with Exit
> flag - @type network-status-vote-3 - Stem's "Votes by Bandwidth
> Authorities" - @type dir-key-certificate-3 - @type
> network-status-microdesc-consensus-3 1.0 - @type microdescriptor
> 1.0 - look at single microdesc cons and microdescs, compile list
> of extended families - fraction of relays that can exit to port 80 
> - @type network-status-2 1.0 - @type directory 1.0 - @type
> bridge-network-status - @type bridge-server-descriptor - @type
> bridge-server-descriptor 1.0 - @type bridge-extra-info 1.3 - @type
> bridge-pool-assignment - @type tordnsel 1.0 - @type torperf 1.0
> 
> 4. action items - get in touch with Dererk for packaging
> metrics-lib for Debian
> 

-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQEcBAEBAgAGBQJWDOCYAAoJEJD5dJfVqbCrwAMIAJ0Chlui/Qv5kiGy9WZVkoKU
UsxiK1IGVh/eGrpunzKdWQtVhvv+285Ab0OUB4URTK5mpOE+bKD3vcFy3ziXvpke
xl5X2rZ/MtzJpRrGcAue0+2YZBrmOsGtGbclH9LcnTRgs65AKFMUp/SPf30LS0Pw
l8tg6xUtB7/97qxwNDj08J9Yp/YtWaankE0zuI3py10qa/2RTXBSjZ0JkemLmhxL
zVy2yUirNdC+bq9rNh+qh2LMIIEEVbGX2sHJx4JdbLjrJAyrSPtyFhXaih4jkIz3
TptTymRwX8Peny7zEJkkGojH6FkOW0gwpfaZBd4vkphLUbyupHIt3k9aKS15Je0=
=uGPS
-END PGP SIGNATURE-
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Hello, I am a Tor Browser user in China. Currently, many obfs4 bridges are blocked by China's firewall.

2015-10-01 Thread Li Xiaodong 
*Hello, I am a Tor Browser user in China. Currently, many obfs4 bridges are
blocked by China's firewall. When will SkypeMorph Pluggable Transports and
Dust Pluggable Transports be deployed in Tor Browser? There are no
directory servers in I2P network. Can Tor learn from I2P? If Tor user have
to access directory servers by bridges, I feel that Tor will be easily
blocked by China's firewall. Can Tor no longer use directory servers in
future? Since 2010 China's firewall has blocked all of the IP addresses of
Tor directory servers. Thank you very much for your help. I really
appreciate it. All the best with your work. Good luck in all that you will
achieve.*
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Onion Services and NAT Punching

2015-10-01 Thread Nathan Freitas 
On Thu, Oct 1, 2015, at 01:15 AM, Andreas Krey wrote:
> On Wed, 30 Sep 2015 17:12:53 +, Tim Wilson-Brown - teor wrote:
> ...
> > Are there any use cases that:
> > * need NAT punching,
> > * don???t need service location anonymity, and
> > * would benefit from lower latency?
> 
> Of course. All the cases where you set up a hidden service
> exactly because your host is behing a NAT.
> 
> Like the webcam raspi I'm just booting up.

I have been looking at the use of Tor and Onion Services for Internet of
(Onion'd) Things applications, but broadly I haven't thought how and
when single onions could add extra benefit. Mostly in IoOT (IoO?) the
goal is to remove the centralized corporate clouds that are currently
used, and to protect your endpoints (house, car, office, etc) from
becoming easily discovered and compromised.

Accessing a home webcam ("dropcam" or "baby monitor" in the common
parlance) is the best example I can think of where you want all the Tor
goodness, and lower latency is also needed. Most of the other apps I can
think of can deal with async messaging and high latency (i.e.
change/check your thermostat settings).

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

Re: [tor-dev] Hello, I am a Tor Browser user in China. Currently, many obfs4 bridges are blocked by China's firewall.

2015-10-01 Thread David Fifield 
On Thu, Oct 01, 2015 at 08:55:33PM +0800, Li Xiaodong wrote:
> Hello, I am a Tor Browser user in China. Currently, many obfs4 bridges are
> blocked by China's firewall. When will SkypeMorph Pluggable Transports and
> Dust Pluggable Transports be deployed in Tor Browser? There are no directory
> servers in I2P network. Can Tor learn from I2P? If Tor user have to access
> directory servers by bridges, I feel that Tor will be easily blocked by 
> China's
> firewall. Can Tor no longer use directory servers in future? Since 2010 
> China's
> firewall has blocked all of the IP addresses of Tor directory servers. Thank
> you very much for your help. I really appreciate it. All the best with your
> work. Good luck in all that you will achieve.

Tor does not use directory servers when you are using bridges (including
obfs4 bridges). The bridge has a copy of the directory information.
Blocking the directory servers does not cause bridges to be blocked. But
the IP address of the bridge itself could be blocked. It seems that this
is what has happened in your case.

I don't know about a schedule for deploying SkypeMorph and Dust. They
may not help in your case anyway. The GFW is probably blocking the IP
addresses of your bridges, not detecting the obfs4 protocol itself.

You might have luck with the meek-amazon or meek-azure transports. They
are not as likely to have their IP addresses blocked. With a little
effort, you can customize it to use domains that you choose.

https://trac.torproject.org/projects/tor/wiki/doc/meek#Quickstart
https://program-think.blogspot.com/2014/10/gfw-tor-meek.html
http://www.atgfw.org/2015/02/torgfwpk1-meektor.html
https://plus.google.com/+GhostAssassin/posts/26zCmDmjYXP
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Hello, I am a Tor Browser user in China. Currently, many obfs4 bridges are blocked by China's firewall.

2015-10-01 Thread Yawning Angel 
On Thu, 1 Oct 2015 08:26:50 -0700
David Fifield  wrote:
> I don't know about a schedule for deploying SkypeMorph and Dust. They
> may not help in your case anyway. The GFW is probably blocking the IP
> addresses of your bridges, not detecting the obfs4 protocol itself.

SkypeMorph: Never. (Licensing issues among other things)

Dust: I assume you mean Dust2, the original Dust is not getting
  deployed. Not sure yet.

[Folding in the 2nd reply]
> If you know some details of how I2P resists blocking, please add them
> to this wiki page:
> https://trac.torproject.org/projects/tor/wiki/doc/PluggableTransports

It doesn't do anything special.

The old TCP based protocol (NTCP) is trivially identifiable.

Blocking the more modern UDP protocol (SSU) would require looking for
high-entropy UDP or doing statistical attacks IIRC.  Active probing is
possible if they run a node that's part of the network and obtain
enough key material (But, I'd need to look at the floodfill system
again to figure out how many nodes for how long is realistically
required).

Regards,

-- 
Yawning Angel


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

[tor-dev] Hello, thank you very much for your help. I really appreciate it.

2015-10-01 Thread Li Xiaodong 
*Hello, thank you very much for your help. I really appreciate it. In this
afternoon of China Time, I found a obfs4 bridge which is usable in China.
The speed of Tor Browser connecting with obfs4 bridge, and the speed of Tor
Browser connecting with Meek Azure, which is faster? It is more difficult
for China's firewall to block I2P. If Tor can learn some strong points of
I2P in future, Tor can work better in China. Thank you very much for your
help. I really appreciate it. All the best with your work. Good luck in all
that you will achieve.*
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Hello, thank you very much for your help. I really appreciate it.

2015-10-01 Thread Li Xiaodong 
*Hello, thank you very much for your help. I really appreciate it. I don't
know how long I can use the obfs4 bridge which I found. Maybe after two
weeks the obfs4 bridge which I found would be blocked by China's firewall.*
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Hello, thank you very much for your help. I really appreciate it.

2015-10-01 Thread David Fifield 
On Fri, Oct 02, 2015 at 12:05:49AM +0800, Li Xiaodong wrote:
> Hello, thank you very much for your help. I really appreciate it. In this
> afternoon of China Time, I found a obfs4 bridge which is usable in China. The
> speed of Tor Browser connecting with obfs4 bridge, and the speed of Tor 
> Browser
> connecting with Meek Azure, which is faster? It is more difficult for China's
> firewall to block I2P. If Tor can learn some strong points of I2P in future,
> Tor can work better in China. Thank you very much for your help. I really
> appreciate it. All the best with your work. Good luck in all that you will
> achieve.

Most likely, obfs4 will be faster than meek-azure. Especially after
tomorrow, when I will slow down meek-azure to reduce costs. See:
https://lists.torproject.org/pipermail/tor-dev/2015-September/009533.html

If you know some details of how I2P resists blocking, please add them to
this wiki page:
https://trac.torproject.org/projects/tor/wiki/doc/PluggableTransports
To edit the wiki you can create an account:
https://trac.torproject.org/projects/tor/register
Or use the shared cypherpunks/writecode account.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Hello, thank you very much for your help. I really appreciate it.

2015-10-01 Thread Li Xiaodong 
*Hello, thank you very much for your help. I really appreciate it. Below is
the URL of the webpage which contains the technical documentation of I2P.*


*https://geti2p.net/en/docs *

*The weak point of I2P is that the speed is slow.*

*The strong point of Tor is that the speed is fast.*

*If we can combine the strong point of I2P with the strong point of Tor,
China's firewall would exist in name only.*
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Blocking-resistance in I2P (Was Re: Hello, I am a Tor Browser user in China. Currently, many obfs4 bridges are blocked by China's firewall.)

2015-10-01 Thread str4d 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Yawning Angel wrote:
> [Folding in the 2nd reply]
>> If you know some details of how I2P resists blocking, please add
>> them to this wiki page: 
>> https://trac.torproject.org/projects/tor/wiki/doc/PluggableTransports
>
>> 
> It doesn't do anything special.

Yet (see below).

There are several reason for I2P not being blocked as much as Tor:

* Traffic - I2P is used by fewer "clients" (tens of thousands) than
Tor (hundreds of thousands to millions).
* Content - I2P doesn't provide easy access to clearnet resources like
Tor does.
* Easiness - non-bridged Tor uses TLS as its outside protocol, and can
therefore be easily identified using standard TLS identifiers for
firewalls. Identification of I2P traffic requires special-purpose
identifiers (which do exist, but add to the maintenance burden of the
firewall).

Thus, blocking I2P currently provides less value-for-effort than
blocking Tor.

> 
> The old TCP based protocol (NTCP) is trivially identifiable.

We have been (slowly) working on NTCP2, a replacement for NTCP, for
nearly 2 years now. We have two different proposals on the table [0],
and are also considering the benefits of the mutual-authentication
variant of Ace [1,2]. Anyone here interested in protocol design is
welcome to add to the discussion!

> 
> Blocking the more modern UDP protocol (SSU) would require looking
> for high-entropy UDP or doing statistical attacks IIRC.  Active
> probing is possible if they run a node that's part of the network
> and obtain enough key material (But, I'd need to look at the
> floodfill system again to figure out how many nodes for how long is
> realistically required).

Active probing of this kind essentially requires that the adversary
enumerate the entire netDB, because geographical information cannot be
used to index into the hash table. We estimate there to be about 750
floodfills at present, so it's not outside the realms of possibility.
However, in practice it isn't really viable:

* By default, routers in China (and several other countries, picked
based on the Press Freedom Index [3]) start in hidden mode, meaning
they don't publish their details in the netDB. So harvesting attacks
will not pick any of those up, and therefore won't be useful for
matching the source of UDP packets.

* I2P routers actively measure the performance of their peers, and
make routing decisions based on their measurements. If an adversary
dropped UDP packets based on matching their destination to the
harvested netDB, the router would simply use other routers that aren't
being blocked.

The most vulnerable point in the system is actually the reseed servers
- - blanket blocks on them can prevent a router from finding any initial
peers. However, if a router can connect to a reseed server, it has a
good chance of being able to connect to the network (HTTPS with
certificate pinning prevents snooping on or modifying what peers a
router is given).

Now that I think of it, the reseed system would be an ideal location
to start introducing PTs into I2P. We have been thinking about how to
leverage PTs in inter-node communication for several years, but
reseeding over PTs would be much easier to implement and would provide
noticeable benefits (making blanket bans much harder).

str4d

[0] http://zzz.i2p/topics/1577-ntcp2
[1] https://moderncrypto.org/mail-archive/curves/2014/000151.html
[2] https://moderncrypto.org/mail-archive/curves/2014/000163.html
[3]
https://github.com/i2p/i2p.i2p/blob/master/router/java/src/net/i2p/route
r/transport/BadCountries.java
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJWDc+cAAoJEBO17ljAn7Pgoq8P/iI2+qr6b65dYPpGCk8R2XA4
Dq2PxpjGX6n74PW96DWg7eHGGjCPLh22SnGSDoU7l6mDCAM9u7BTh1j/se5uMzuh
6Y2z3dml5L+I+JXd+WdqGQK8gFkAMXrVMc9waEY8bKC1/ENssUXBlN1Jfm3lcttj
BirJxyc7c14EX2gHsMLE/cbgeVUl+sf4/A2cXqjLmlnrUSiGRBPx7AAU/fPbSA0P
JgvYvbUQ0NCly8BSZkQRL5qh01DuF9ZD39JkOAvy+N0pW0EoCPjLVGsdY4RjWnSZ
zQF2IJoig35gi6Tqxk/jUS1b6+hoCacTN7Ly00WAykAjJqFF5OfIaD60HJizdlbX
5aAwncAJhaddaMVpekp4zBhjI07gvZW9k3Nzjy6yRcBGYxg96PU5fedk37HTMcyu
Ixpi2hu84FHDwE8YVfTVw9yrDzkp0azVsgS0CwJSONtrpfKDcU3z9L928N/abdMS
d7OBJo3omPfMmjMyGjqjQ0+348oTVarEV4hfqDIICbvIPfXRWkGKRMcNEXbjcg+f
+5gISZpZ+FX9UiyhWm4MP+B+fcyvT/QO5/wH0B1k9rBYO+1VUAFNKkzqBxqOy1QM
166irImK9kh5OTtdxww7guYx+h5zLOJSB3tcnEG5Ksu3rCY7iEnVV2C6bb8Irpg1
ItGd4ak9UDVtFN2HY0OX
=oTAv
-END PGP SIGNATURE-
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Expanding services: Single-onion and OnioNS

2015-10-01 Thread Hugo Maxwell Connery 
Hi,

Having reviewed the last couple of months of tor-dev mails,
i can see that there are many proposals afoot to expand the
uptake of tor hosted services.  These range from a new service
type, single-onion [0], to load balancing of tor hosted services
[1], to hosting new name/value pairs (x-namespace) [2], to new
name services (OnioNS [3] and better integration of Gnu NS [4]),
to name a few that caught my eye.

The fact that Facebook (which I wholely dislike) expended
considerable effort in generating a human readable location hidden
service address and then strongly participated in IETF discussions
to declare .onion as a special case TLD reservation indicates
that the perception of the validity and significance of the tor
network is growing.

I have comment on single-onion services and on name services.

For single onion services, in which client -> guard -> middle
-> middle -> single-onion, the role of the second middle relay
changes.  In the traditional sense it merely knows that it is
part of a circuit connecting two relays, and has no knowledge
at all about either source (client) or destination (normal web
service).  For single onion services the second middle relay
can know something about the service to which it is connecting.

As Yawning Angel points out [5] this may provide censorship
opportunities.  For this, I suspect that single onion service
operators need to be made aware of this risk.  If they are aware,
they can persue strategies to mitigate (e.g run multiple contact
points over a back end).

John Brooks identifies [6] a potential risk for the second
middle relay operator if the single onion service is malicious
(keeps detailed logs, runs a honeypot etc.).  For this case,
and to help peole who provide large capacity middle relays (e.g
Mozilla) and wish for no legal risk, a config flag may need to
be provided which allows middle relays to choose not to connect
to single onion services.  There may be other, better strategies.

I wish also to highlight the potential importance of Jesse V's
OnioNS [7].  I am highly supportive of alternatives to the DNS,
which despite efforts ongoing in the IETF, will never be secure
against surveillance.  OnioNS attempts to solve Zooko's triangle.
It seems a well considered name system, and I encourage
others to examine it.

The key benefits are that a service can choose a name for itself,
but must do work to do so, and must regularly do work to maintain
the name (thus costing squatters effort).  The name service
operates entirely within the location hidden services space and
thus offers the protections inherent in that.  Registration is
at the second level (e.g example.tor) but can also at the same
time register lower levels names (e.g xmpp.example.tor and
gopher.example.tor).

Regards,  Hugo

[0] https://lists.torproject.org/pipermail/tor-dev/2015-September/009408.html

[1] https://lists.torproject.org/pipermail/tor-dev/2015-September/009597.html

[2] https://lists.torproject.org/pipermail/tor-dev/2015-September/009588.html

[3] https://lists.torproject.org/pipermail/tor-dev/2015-September/009585.html

[4] https://lists.torproject.org/pipermail/tor-dev/2015-September/009560.html

[5] https://lists.torproject.org/pipermail/tor-dev/2015-September/009416.html

[6] https://lists.torproject.org/pipermail/tor-dev/2015-September/009415.html

[7] 
https://github.com/Jesse-V/OnioNS-literature/raw/master/conference/conference.pdf
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev