- tor-dev - lists.torproject.org

Special-use-TLD support
by Jeff Burdges 06 Oct '15

06 Oct '15

This is the first of two torspec proposals to help Tor work with Sepcial-Use TLDs, like the GNU Name system or NameCoin. The second part will be an anycast facility. - Jeff Filename: xxx-special-use-tld-support.txt Title: Special-Use TLD Support Author: Jeffrey Burdges Created: 20 Sept 2015 Status: Draft Implemented-In: ? Abstract Suppose Special-Use TLDs in Tor via external Domain Name System (DNS) suppliers, such as the GNU Name System and NameCoin. Background Special-use TLD supplier software integrates with the host operating system's DNS layer so that other software resolves the special-use TLD identically to standard DNS TLDs. On Linux for example, a Special-Use TLD package could create a plugin for the Name Service Switch (NSS) subsystem of the GNU C Library. Tor cannot safely use the local system's own DNS for name resolution, as doing so risks deanonmizing a user through their DNS queries. Instead Tor does DNS resolution at a circut's exit relay. It follows that Tor users cannot currently use special-use TLDs packages in a safe manor. In addition, there are projects to add public key material to DNS, like TLSA records and DNSSEC, that necessarily go beyond NSS. Design We denote by N an abstract name service supplier package. There are two steps required to integrate N safely with Tor : Of course, N must be modified so as to (a) employ Tor for it's own traffic and (b) to use Tor in a safe way. We deem this step outside the scope of the present document since it concerns modifications to N that depend upon N's design. We caution however that peer-to-peer technologies are famous for sharing unwanted information and producing excessively distinctive traffic profiles, making (b) problematic. Another proposal seeks to provide rudementary tools to asist with (a). We shall instead focus on modifying Tor to route some-but-not-all DNS queries to N. For this, we propose a NameService configuration option that tells Tor where to obtain the DNS record lying under some specific TLD. Anytime Tor resolves a DNS name ending in an Special-Use TLD appearing in an NameService configuration line then Tor makes an RPC request for the name record using given UNIX domain socket or address and port. We should allow CNAME records to refer to .onion domains, and to regular DNS names, but care must be taken in handling CNAME records that refer to Special-Use TLDs handled by NameSerice lines. Tor should reject CNAME records that refer to the .exit domains. Configuration We propose two Tor configuration options : NameSubstitution [.]source_dnspath [.]target_dnspath NameService [.]dnspath socketspec [noncannonical] [timeout=num] [-- service specific options] We require that socketspec be either the path to a UNIX domain socket or an address of the form IP:port. We also require that that each *dnspath be a string conforming to RFC 952 and RFC 1123 sec. 2.1. In other words, a dnsspec consists of a series of labels separated by periods . with each label of up to 63 characters consisting of the letters a-z in a case insensitive mannor, the digits 0-9, and the hyphen -, but hyphens may not appear at the beginning or end of labels. NameSubstitution rules are applied only to DNS query strings provided by the user, not CNAME results. If a trailing substring of a query matches source_dnspath then it is replaced by target_dnspath. NameService rules route matching query to to appropriate name service supplier software. If a trailing substring of a query matches dnspath, then a query is sent to the socketspec using the RPC protcol descrived below. Of course, NameService rules are applied only after all the NameSubstitution rules. There is no way to know in advance if N handles cahcing itself, much less if it handles caching in a way suitable for Tor. Ideally, we should demands that N return an approporaite expiration time, which Tor can respect without harming safety or performance. If this proves problematic, then configuration options could be added to adjust Tor's caching behavior. Seconds is the unit for the timeout option, which defaults to 60 and applies only to the name service supplier lookup. Tor DNS queries, or attempts to contact .onion addresses, that result from CNAME records should be given the full timeout alloted to standard Tor DNS queries, .onion lookups, etc. Any text following -- is passed verbatim to the name service suppllier as service specific options, according to the RPC protocol described below. Control Protocol An equivalent of NameService and NameSubstitution should be added to the Tor control protocol, so that multiple users using the same Tor daemon can have different name resolution rules. RPC protocol We require an RPC format that communicates two values, first any service specific options give on the NameService line, and second the query name itself of course. We might however discuss if there are any standardized flags, distinct from these options, and whether they should be communicated separately. In principle, Tor could make due with simply receiving a strong in return. We recommend however that Tor expect a return format as or more powerful than full DNS queries. In particular, we should endever to return TLSA records at the same time as the underlying DNS record, so that Tor Browser can utilize that key material. The GNS Record format used by the GNU Name System addresses this and other issues, so it should be taken as a candidate. See : https://github.com/GNUnet/gnunet/blob/gnunet/src/include/gnunet_gnsrecord_l… Sepcial-use tLD suppliers should internally process CNAME records that fall into their own domains, but they should return CNAME records to Tor that refer to .onion or .exit domains, or to normal DNS names. Initially, Tor should issue an error if it recieves a CNAME record that matches an NameService line. If however that NameService line contains the noncannonical option, then CNAME records should instead bypass it, and use Tor's DNS system. At present, alternative DNS packages should not pass CNAME records between themselves, despite speaking the same RPC protocol, as this creates unknown risks. As such forwarding can be done most safely by Tor itself, the Tor Project reserves the right to forward CNAME records between NameService lines in the future. Applications should therefore not depend upon the above error being returned. Variations Tor would conceivably benefit from externalizing its own DNS handling as a separate process. This might however require that Tor have the ability to start name service suppliers. A fuller consideration of this might alter our design of the NameService configuration option. Acknowledgments Based on extensive discussions with Christian Grothoff and George Kadianakis.

8 20

Proposal: HTTP header distinguish TBB users
by Virgil Griffith 04 Oct '15

04 Oct '15

Yesterday Lief compellingly argued that if a TBB user accidentally clicks on a link to my tor2web proxy (onion.link), that they should be redirected to the .onion address. It hadn't occurred before that a Tor user might accidentally click a onion.link URL, but yes I completely concur and I told Lief I would prioritize this and would owe him a Bitcoin if I didn't get this implemented within a week. Now the trouble starts. If the TBB user gets to the tor2web backend I check if they're coming from an Exit relay and redirect them---all good. But a CDN (Fastly.com) sits in front of my backends and right now it's unclear how to detect TBB at the CDN level. Going over my CDN's documentation. They do have the standard MaxMind database for geo-IP. So that's good. But plugging in an exit-node IP# merely reports as an "A1" for "Anonymous Proxy". Unfortunately there are many anonymous proxies other than Tor so that won't do. There are two ways to solve this. (1) For an given IP#, MaxMind reports numerous entries aside from the "A1" for country code. We could ask MaxMind to specify whatever else it knows about the Anonymous Proxy in the other fields such as the "Location" or "Organization" field. So when plugging in a Tor exit relay it would return something like: { "countrycode": "A1", "location": "Tor", "domain": "torproject.org" } or some such. This seems a reasonable request. Do we know someone at MaxMind to forward this request to? (2) If we (Tor Project) is going to ask MaxMind to do something special to distinguish TBB users, it seems reasonable we should make the same effort. I know in the past it's been proposed for TBB to include a special HTTP header, e.g., Tor-Browser-Bundle: true to distinguish TBB users. If this header existed, I could detect it at the CDN-level and do the appropriate redirect. Alternatively, We could do something equivalent with the "Via": HTTP header, but that seems overkill. Between these two options, I personally opt for (2) because it seems inappropriate to request MaxMind to help us do X when we have not done what we can do to achieve X. Q: Does anyone (especially Mike Perry) have any objections to (2)? If not, I will write the proposal. -V P.S. Lief... even if we go at maximum speed, it looks like I'm going to owe you that Bitcoin. Email me your BTC address? How embarrassing.

6 10

Notes+Action Items from Hidden Service Fingerprinting session
by Mike Perry 04 Oct '15

04 Oct '15

Our session on Friday about Hidden Service Fingerprinting wandered a lot. Ultimately, we concluded that it will be hard to fully defend against this attack without a more formally specified state machine that describes hidden service circuit usage fully. However, we may still be able to extend the Netflow Padding defense to pad more often during circuit setup, which should at least improve the situation against an adversary that is externally monitoring the Guard node. Here's the specific action items from the session yesterday: * Review Prop 224 and other proposals for distinguishes for client traffic * Specify a protocol state machine as part of the design * If it is more complicated than the TCP state machine, we should run in fear * Otherwise, researchers should be able to make use of this state machine to determine optimal padding * Netflow padding should have a state to cover circuit setup * Based on Circuit Build Timeout * This allows only 2-10 seconds or so of more frequent padding * The "HS's sometimes need to use a second Guard" distinguisher * The RP should never be a Guard node * The third level node should never be a Guard node * TBB Update pings over HS * Increases the Base Rate, since more clients are building hidden service circuits * This is far easier to do for the Torbutton RecommendedTBBVersions fetch since the updater has special cert pinning that would need to be altered for hidden services * Future Research: * Conflux + Guard Sets * Provides Redundancy against active delay and DoS attacks * May help against fingerprinting and correlation * However, still won't help against a datacenter adversary :/ -- Mike Perry

1 0

Hello, the obfs4 bridge which I got on October 1st is blocked in China today.
by Li Xiaodong 03 Oct '15

03 Oct '15

*Hello, the obfs4 bridge which I got on October 1st is blocked in China today. I think that the number of Tor bridges is limited. If China's firewall were to block all of Tor bridges, how Tor could work in China? Are there any better ways to connect to Tor network than bridges? 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. Thank you so much for your help again.*

1 0

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

03 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 02 Oct '15

02 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 02 Oct '15

02 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 02 Oct '15

02 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