tor-dev

tor-dev@lists.torproject.org

3581 discussions

Start a nNew thread

Hello, are there better ways to connect to the Tor network than bridges?
by Li Xiaodong 02 Oct '15

02 Oct '15

*Hello, are there any better ways to connect to the Tor network than bridges?*

2 1

Guidelines and processes for ethical Tor research
by Aaron Johnson 02 Oct '15

02 Oct '15

Hello, Today at the Tor developers’ meeting, we had a discussion about how to help ensure that Tor research is done ethically. We developed a set of general guidelines for ethical Tor research, and we sketched out a process that researchers should follow if they want to do work on the live Tor network. The guidelines at present are: 1. Only collect data that is acceptable to publish. In the case of encrypted or secret-shared data, it can be acceptable to assume that the keys or some shares are not published. 2. Only collect as much data as is needed (i.e. data minimization). 3. Limit the granularity of the data. For example, "noise" (i.e. added data inaccuracies) should almost certainly be added. 4. Make an explicit description of benefits and risks, and argue that the benefits outweigh the risks. 5. Consider auxiliary data when assessing the risk of your research. For example, data from snooping exit traffic can be combined with entry traffic to deanonymize users. 6. Use a test network when at all possible. The process we discussed is fairly lightweight. It amounts to notifying a Tor Review Group (TRG) of your plans and using the TRG's feedback to develop a research plan that respects the guidelines. This notification can be private to the TRG only (although public notification is preferred). The TRG would consist of Tor developers and researchers. We are going to continue developing the guidelines and process through the wiki: <https://trac.torproject.org/projects/tor/wiki/doc/ResearchEthics>. Please send any comments. Best, Aaron

1 0

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.)
by str4d 02 Oct '15

02 Oct '15

-----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-----

1 0

Hello, thank you very much for your help. I really appreciate it.
by Li Xiaodong 01 Oct '15

01 Oct '15

*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 <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.*

1 0

Hello, I am a Tor Browser user in China. Currently, many obfs4 bridges are blocked by China's firewall.
by Li Xiaodong 01 Oct '15

01 Oct '15

*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.*

3 2

Hello, thank you very much for your help. I really appreciate it.
by Li Xiaodong 01 Oct '15

01 Oct '15

*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.*

2 1

Hello, thank you very much for your help. I really appreciate it.
by Li Xiaodong 01 Oct '15

01 Oct '15

*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.*

1 0

Re: [tor-dev] Onion Services and NAT Punching
by Nathan Freitas 01 Oct '15

01 Oct '15

On Thu, Oct 1, 2015, at 01:15 AM, Andreas Krey wrote: > On Wed, 30 Sep 2015 17:12:53 +0000, 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

1 0

Expanding services: Single-onion and OnioNS
by Hugo Maxwell Connery 01 Oct '15

01 Oct '15

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/conferen…

1 0

Re: [tor-dev] Second release of OnioNS beta
by Jesse V 01 Oct '15

01 Oct '15

Heads-up everyone, After some debugging with s7r, it appears that sometimes the programs (onions-server, onions-hs, or onions-client) fail to start because they cannot load the common library. So if you run any of the programs in the terminal, you will see an error that libonions-common.so cannot be found, or they simply won't run if you start them without an active terminal. This is because that library is installed to /usr/lib/onions-common, but the loader is looking for it in /usr/lib/, among other locations. I do set the RPATH in CMake in an attempt to fix this, but in some cases (at least in my build for Debian Wheezy) it may not be set or installed correctly. I'm investigating and looking through https://cmake.org/Wiki/CMake_RPATH_handling If this occurs, there are two workarounds. The first is to run export LD_LIBRARY_PATH="/usr/lib/onions-common" before running any of the software. The second is to add "/usr/lib/onions-common/" (without quotes) to /etc/ld.so.conf Both should tell the loader to look for the library in the correct path. This issue might also occur on Fedora under the for the experimental .rpm, but I'm not sure. The issue doesn't occur on my computer, but if it also applies to Ubuntu or Mint, please let me know. It's always possible to compile from source and run the software from the build directory, but I would really like to identify the scope of this issue and then properly fix it. Thanks, Jesse V.

1 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-dev