October 2015 - tor-dev - lists.torproject.org

UniformDH question
by Jeff Burdges 08 Oct '15

08 Oct '15

What is the advantage of using X or p-X in UniformDH in obfsproxy? https://gitweb.torproject.org/pluggable-transports/obfsproxy.git/tree/d oc/obfs3/obfs3-protocol-spec.txt#n65 Isn't just X itself dense pretty quickly anyways? Jeff

2 1

Re: [tor-dev] Trac priorities and severities
by Hugo Maxwell Connery 08 Oct '15

08 Oct '15

Hi, Yes, renaming to a more meaningful thing is great. Also, if only some group can grade entries, then it is wise to have an 'uncategorised' category which appears in a grading list towards, but not at the bottom. Field experience in these systems tells me that people get annoyed at being auto-classified at the bottom. I advise putting 'uncategorised' at 5 of 7 or something similar. e.g Critical, High Import, Import, Medium, Uncategorised, Small, Trivial. This also helps to raise the visibility of Uncategorised items; i.e Categorise them :) Regards, Hugo

1 0

Re: [tor-dev] Crux: Privacy-preserving statistics for Tor
by str4d 07 Oct '15

07 Oct '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Vasilios Mavroudis wrote: > Hello, > > I would like to introduce our project "Crux", which enables the > computation of privacy preserving statistics on sensitive data. The > project was developed at University College London (UCL) by me, in > close collaboration with George Danezis. This is fantastic work. Haven't read all of your thesis yet, but it looks similar to the stats collection system that we ran for a while inside I2P, but with the privacy protections that I wanted it to have. Well done! > > "Crux" was designed with Tor hidden services in mind (in accordance > with this > <https://research.torproject.org/techreports/hidden-service-stats-2015 - -04-28.pdf> > > Tor > Tech Report), but it can be applied on various kinds of data (given > an appropriate parser). Excellent. I want to use this in I2P :) > > It supports three statistics (i.e. mean, median, variance) and its > threat model is compatible Tor's (see technical document below). I will look into this, but I doubt there will be any insurmountable incompatibilities with I2P's threat model. > Currently, we don't have a parser specific for the data collected > by the Tor relays, but we plan to keep adding functionality. > > The source code can be found here: > https://github.com/mavroudisv/Crux The theoretical background, > threat model, security argument and technical details can be found > here: link <http://mavroudisv.eu/files/thesis.pdf> > > > Ideas, comments, feedback much appreciated! Firstly: needs more docs. I shouldn't have to read your entire thesis in order to figure out how to run it :P The README is a good start, but the command parameters need clarification/definitions, and it is not at all obvious how the relays work. An XLS file is also mentioned without explanation. Secondly, you could probably simplify configuration by managing hidden service connections yourself. I believe the Stem library can do this? I2P has a python library that can be used to listen on and connect to I2P Destinations, with a socket-like interface. It's not clear to me from your thesis whether you plan to merge the relay component into the Tor relay code (and have the Tor relays talk directly to the query processors), or have your relays running separately and interfacing with the Tor relays to fetch stats. This will potentially alter how it would be used with other networks. In I2P's case I'd imagine it would be easiest (in terms of usability by those setting up relays) to write an I2P plugin in Java that performs the relay role, but I wouldn't want to be duplicating a lot of logic that subsequently needs to be kept in-sync with upstream :) str4d > > Vasilis > > > > _______________________________________________ tor-dev mailing > list tor-dev(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJWFP9HAAoJEBO17ljAn7PgAq0P/jrjLnPxg2+rfOX1H46xClpG wfeeNuDltlrvTtNwtDO+lqSzpz+LY/PkUbHow2B7wprRgGvav2kCtGh3xga4BVEX SoYiNcWhRKFmrw6jNjAGPh060hcC7WzBbAjxQ28kotl7NiXO4ZbeMdQ5vqDVE5+K 2f0lSFnBYmj4SYxaVWIxGir3FRn+VdACWjQPL1JV4LDbAPXmNlg17nBwvj5g9lhS n9InsXUqoyhJ5zbVqwHoNl8N2IMui+i2ppF3ZiuHQCHw88+6qJxVW5u11zP2TccJ ycFNE5jcxxNtK9+1jwdfpen5yAnAlaaeKHkHZ+oNN1nb156QbLhcIwqt8IeRFcZv SzaCQk6NIAZFbOVPNzTJ6akXjajd7AbkdVnGBeziD8z8yD1Qa+OH0vBoT/jTP5Ec OdU9f0a3Vc3zftoSaRsCHaQX7+1OEKjDkyk6Gs6lt2PUWVvnNu2+ztXBttI2v8Ee UjEbAC7OR8NpyBAn0p+ja/353zCZU0TXzjccEFb7YtjCCy0hACQGuxwjEECcpbQH MKRZa0JmbSVbDsZoRuMNEwPzg4/sXTVaS8mGmOurotXR1iPgs80DxiAym0kLOe0d xllTDtf561gekxed/+Zm5hjH5FAR7uMI4cpywRUMqyCzJGSKZKr/2uxjnv832j4H ecujGrMEByFdgfG3co5P =etz3 -----END PGP SIGNATURE-----

2 1

#9623 [Tor Browser]: Referers being sent from hidden service websites
by Tim Wilson-Brown - teor 07 Oct '15

07 Oct '15

Hi All, Currently there’s an information leak in Tor Browser: it sends referrer headers containing .onion site addresses when the user clicks on a link on the .onion site. There’s a fix in the works, but we were wondering: Does anyone’s hidden service depend on the referrer header? The currently favoured fix is to stop sending referrers cross-origin (between different .onion sites, and between .onion sites and sites on the internet). But this may break sites that are set up with multiple .onion addresses and use referrers to check that requests are coming from the parent site. (People sometimes set up different .onion sites to serve different types of content, such as images.) In general, I would discourage people from using referrers in this way, because they aren’t secure and can be faked. But does anyone have a compelling use case for cross-origin referrers, or is using them at the moment? We could include a preference if removing them would break too many sites. Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F

4 3

[Measurement Team] Next IRC meeting happens on Thursday, Oct 8, 14:00 UTC in #tor-dev
by Karsten Loesing 07 Oct '15

07 Oct '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello list, This is an announcement/reminder that there will be an IRC meeting of the Measurement Team on Thursday, October 8, 2015, 14:00 UTC in #tor-dev https://www.timeanddate.com/worldclock/fixedtime.html?iso=20151008T14 This will be the first IRC meeting since the Berlin dev meeting, and we're going to talk about the outcomes of that, among other things. For example, we talked about meeting every two weeks on IRC, instead of every week, and moving more communication to email. Be sure to be around tomorrow if you want to discuss things like that. Talk to you tomorrow! All the best, Karsten -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJWFKklAAoJEJD5dJfVqbCrgV4H/3DoPjbDOk+mMmbCnc5ui0rM sihlWNx7xgKSAKJ5fK6BfCBnSeBHdWC3AzzpZGre21JpZp7FgQqkVOq65z70tANG WaGDHuHmNvtmu45nIDgSDZrgt3teHG2T5EALTcBy7bo3JdBKIVICkheBhO99tvCE Do4/MzHUF4kQ6EMD9bo2n7ASnIi7Tr/RPwA/mNDvHYGlGztJOkH9um+HK99+PLDf hx0c7G3jL2/jiItH+NnBFAoXAahC7F6x3Pga5EhhQ5gy1C4mT//ZWECMAEo5eMDg m9t2y+30ecpJ0x0HIXvx6v5XH0rjOHWu6ASaMim63goQJ1NYy8GAL5dvQZjCR+w= =JnLB -----END PGP SIGNATURE-----

1 0

Networks Blocking Tor's SSL Connections
by Tim Wilson-Brown - teor 07 Oct '15

07 Oct '15

Hi All, This morning I observed a “free wifi” network blocking tor’s SSL connections. While other SSL connections from my machine went through, I observed multiple network traces of tor completing a TCP 3-way handshake, and then getting no reply to the first SSL packet it sent. I think they may have been blocking unknown or untested certificates, but I can’t be sure. Still, I was able to use meek(-google) to access tor. Has anyone else seen this kind of blocking behaviour? (Is this the right list?) Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F

2 1

Crux: Privacy-preserving statistics for Tor
by Vasilios Mavroudis 07 Oct '15

07 Oct '15

Hello, I would like to introduce our project "Crux", which enables the computation of privacy preserving statistics on sensitive data. The project was developed at University College London (UCL) by me, in close collaboration with George Danezis. "Crux" was designed with Tor hidden services in mind (in accordance with this <https://research.torproject.org/techreports/hidden-service-stats-2015-04-28…> Tor Tech Report), but it can be applied on various kinds of data (given an appropriate parser). It supports three statistics (i.e. mean, median, variance) and its threat model is compatible Tor's (see technical document below). Currently, we don't have a parser specific for the data collected by the Tor relays, but we plan to keep adding functionality. The source code can be found here: https://github.com/mavroudisv/Crux The theoretical background, threat model, security argument and technical details can be found here: link <http://mavroudisv.eu/files/thesis.pdf> Ideas, comments, feedback much appreciated! Vasilis -- Vasilios Mavroudis

1 0

Re: [tor-dev] Networks Blocking Tor's SSL Connections
by Tim Wilson-Brown - teor 07 Oct '15

07 Oct '15

> On 7 Oct 2015, at 10:52, Brandon Wiley <brandon(a)blanu.net> wrote: > > Hello! I am a researcher focusing on blockability of Tor connections. If you have pcap files that you would like to share showing Tor SSL connections that have been blocked and non-Tor SSL connections that have not been blocked, this would be helpful for my research. I have this pcap analysis framework: https://github.com/blanu/AdversaryLab-offline <https://github.com/blanu/AdversaryLab-offline> as well as this transport for Tor that uses the analysis to find an optimal encoding so that Tor connections are not blocked: https://github.com/blanu/Dust <https://github.com/blanu/Dust> So essentially given two sets of pcaps, one for blocked connections and one for unblocked connections, I can automatically unblock Tor connections. I’m sorry, I only have a pcap file for blocked Tor connections. > If you don't have pcap files or you don't want to share them, if you have access to a network that blocks Tor in a reproducible way, perhaps we could run some tests I’m sorry, I no longer have access to that network. > Let me know if you're interested! > > On Tue, Oct 6, 2015 at 6:06 PM, Tim Wilson-Brown - teor <teor2345(a)gmail.com <mailto:teor2345@gmail.com>> wrote: > Hi All, > > This morning I observed a “free wifi” network blocking tor’s SSL connections. While other SSL connections from my machine went through, I observed multiple network traces of tor completing a TCP 3-way handshake, and then getting no reply to the first SSL packet it sent. > > I think they may have been blocking unknown or untested certificates, but I can’t be sure. > > Still, I was able to use meek(-google) to access tor. > > Has anyone else seen this kind of blocking behaviour? > (Is this the right list?) > > 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(a)lists.torproject.org <mailto:tor-dev@lists.torproject.org> > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev <https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev> > > Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F

1 0

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