tor-dev October 2016

tor-dev@lists.torproject.org

52 participants
32 discussions

Re: [tor-dev] Call for help on testing core tor releases
by Vinícius Zavam 25 Oct '16

25 Oct '16

2016-10-25 10:08 GMT-03:00, isabela <isabela(a)torproject.org>: > Hi there! hey. hi! > First, thanks again for offering to help test our 0.2.9.4-alpha release! > > This release came out actually last week but I was mostly offline and > could not send this note to you / sorry about that. 5 of these machines used to run 0.2.9.4-alpha since Oct 18 14:58; -dev since Oct 20 17:59; GMT-3. > I organized the information related to what to test and how to report > bugs here: > > https://pad.riseup.net/p/V5ysw5cWFIbz nice! thanks for sharing it. > A new thing you will find there is a link to download a nightly build of > Tor Browser with Tor 0.2.9.4-alpha -- this is actually the easiest way > to test it if you only have a few minutes. > > There are some instructions on how to submit a bug to us as well. that will help me a lot. I was "confused" about the sponsor stuff, but now it is okay though > This is the first time we are doing this (call for help testing) sorry > for the bumps along the way :) We will continue to ask for help and > hopefully get better over time. > > If you have some time this week, please do test our alpha release, this > will help us a lot! > > Thanks again for the help o/ > > Isabela > o/ -- Vinícius Zavam keybase.io/egypcio/key.asc

1 0

Potential regression when binding sockets to interface without default route
by René Mayrhofer 25 Oct '16

25 Oct '16

Dear Tor developers, [Please CC me in replies, I am not currently subscribed to tor-dev.] Context: At the Institute of Networks and Security at Johannes Kepler University Linz, we have been hosting Austria's fastest exit node for the last ca. 9 months. It used to be listed as https://atlas.torproject.org/#details/01A9258A46E97FF8B2CAC7910577862C14F2C… until very recently, and we tried to find out what went wrong when we saw traffic drop sharply a bit over a week ago. Unfortunately, two out of three people responsible for running this node were on holidays, so we could only start investigating today. Setup: Please note that our setup is a bit particular for reasons that we will explain in more detail in a later message (including a proposed patch to the current source which has been pending also because of the holiday situation...). Briefly summarizing, we use a different network interface for "incoming" (Tor encrypted traffic) than for "outgoing" (mostly clearnet traffic from the exit node, but currently still includes outgoing Tor relay traffic to other nodes). The outgoing interface has the default route associated, while the incoming interface will only originate traffic in response to those incoming connections. Consequently, we let our Tor node only bind to the IP address assigned to the incoming interface 193.171.202.146, while it will initiate new outgoing connections with IP 193.171.202.150. Problem: This worked nicely with Tor 0.2.5.12-1 on Debian Jessie. We upgraded about two weeks ago to 0.2.8.7-1 from the Tor apt repositories (mostly in response to https://blog.torproject.org/blog/tor-0287-released-important-fixes as a wakeup call that we were using old versions from Debian main). At first, it seemed to work well enough, but then the holidays came and we didn't actively watch it for the next week.... Now with 0.2.8.7-1, the traffic sent to our node started declining until it vanished completely. After a bit of debugging and rolling back to 0.2.5.12-1 (which is now active on our node as of a few hours ago, slowly approaching the 200MBit/s again), it seems that we discovered a regression concerning the handling of sockets. I can best summarize it with the relevant torrc config options and startup log lines from both versions: root@tor2 ~ # grep 193.171.202 /etc/tor/torrc ORPort 193.171.202.146:9001 ORPort 193.171.202.146:443 OutboundBindAddress 193.171.202.150 DirPort 193.171.202.146:9030 Sep 19 11:37:41.000 [notice] Tor 0.2.8.7 (git-cc2f02ef17899f86) opening log file. Sep 19 11:37:41.194 [notice] Tor v0.2.8.7 (git-cc2f02ef17899f86) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.1t and Zlib 1.2.8. Sep 19 11:37:41.194 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning Sep 19 11:37:41.194 [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc". Sep 19 11:37:41.194 [notice] Read configuration file "/etc/tor/torrc". Sep 19 11:37:41.197 [warn] You specified a public address '0.0.0.0:9050' for SocksPort. Other people on the Internet might find your computer and use it as an open proxy. Please don't allow this unless you have a good reason. Sep 19 11:37:41.198 [notice] Based on detected system memory, MaxMemInQueues is set to 2961 MB. You can override this by setting MaxMemInQueues by hand. Sep 19 11:37:41.198 [warn] Tor is running as an exit relay. If you did not want this behavior, please set the ExitRelay option to 0. If you do want to run an exit Relay, please set the ExitRelay option to 1 to disable this warning, and for forward compatibility. Sep 19 11:37:41.198 [warn] You specified a public address '0.0.0.0:9050' for SocksPort. Other people on the Internet might find your computer and use it as an open proxy. Please don't allow this unless you have a good reason. Sep 19 11:37:41.199 [notice] Opening Socks listener on 0.0.0.0:9050 Sep 19 11:37:41.199 [notice] Opening Control listener on 127.0.0.1:9051 Sep 19 11:37:41.199 [notice] Opening OR listener on 193.171.202.146:9001 Sep 19 11:37:41.199 [notice] Opening OR listener on 193.171.202.146:443 Sep 19 11:37:41.199 [notice] Opening Directory listener on 193.171.202.146:9030 Sep 19 11:37:41.000 [notice] Parsing GEOIP IPv4 file /usr/share/tor/geoip. Sep 19 11:37:41.000 [notice] Parsing GEOIP IPv6 file /usr/share/tor/geoip6. Sep 19 11:37:41.000 [notice] Configured to measure statistics. Look for the *-stats files that will first be written to the data directory in 24 hours from now. Sep 19 11:37:41.000 [warn] I have no descriptor for the router named "ins1" in my declared family; I'll use the nickname as is, but this may confuse clients. Sep 19 11:37:41.000 [warn] I have no descriptor for the router named "ins2" in my declared family; I'll use the nickname as is, but this may confuse clients. Sep 19 11:37:41.000 [notice] Your Tor server's identity key fingerprint is 'ins0 01A9258A46E97FF8B2CAC7910577862C14F2C524' Sep 19 11:37:41.000 [notice] Bootstrapped 0%: Starting Sep 19 11:37:49.000 [notice] Bootstrapped 80%: Connecting to the Tor network Sep 19 11:37:49.000 [notice] Signaled readiness to systemd Sep 19 11:37:50.000 [notice] Opening Control listener on /var/run/tor/control Sep 19 11:37:51.000 [notice] Bootstrapped 85%: Finishing handshake with first hop Sep 19 11:37:51.000 [notice] Bootstrapped 90%: Establishing a Tor circuit Sep 19 11:37:51.000 [notice] Tor has successfully opened a circuit. Looks like client functionality is working. Sep 19 11:37:51.000 [notice] Bootstrapped 100%: Done Sep 19 11:37:51.000 [notice] Now checking whether ORPort 193.171.202.150:9001 and DirPort 193.171.202.150:9030 are reachable... (this may take up to 20 minutes -- look for log messages indicating success) Sep 19 11:38:30.000 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Sep 19 11:38:34.000 [warn] You specified a server "ins1" by name, but the directory authorities do not have any key registered for this nickname -- so it could be used by any server, not just the one you meant. To make sure you get the same server in the future, refer to it by key, as "$CD9FD887A4572D46938640BA65F258851F1E418B". Sep 19 11:38:34.000 [warn] You specified a server "ins2" by name, but the directory authorities do not have any key registered for this nickname -- so it could be used by any server, not just the one you meant. To make sure you get the same server in the future, refer to it by key, as "$7C3AF46F77445A0B1E903A5AF5B730A05F127BFC". Sep 19 11:40:18.000 [notice] Performing bandwidth self-test...done. Sep 19 11:57:50.000 [warn] Your server (193.171.202.150:9030) has not managed to confirm that its DirPort is reachable. Relays do not publish descriptors until their ORPort and DirPort are reachable. Please check your firewalls, ports, address, /etc/hosts file, etc. Sep 19 12:00:27.000 [notice] Interrupt: we have stopped accepting new connections, and will shut down in 30 seconds. Interrupt again to exit now. Sep 19 12:00:57.000 [notice] Clean shutdown finished. Exiting. Sep 19 12:01:48.000 [notice] Tor 0.2.5.12 (git-3731dd5c3071dcba) opening log file. Sep 19 12:01:48.000 [notice] Configured to measure directory request statistics, but no GeoIP database found. Please specify a GeoIP database using the GeoIPFile option. Sep 19 12:01:48.000 [notice] Caching new entry debian-tor for debian-tor Sep 19 12:01:48.000 [notice] Caching new entry debian-tor for debian-tor Sep 19 12:01:48.000 [warn] I have no descriptor for the router named "ins1" in my declared family; I'll use the nickname as is, but this may confuse clients. Sep 19 12:01:48.000 [warn] I have no descriptor for the router named "ins2" in my declared family; I'll use the nickname as is, but this may confuse clients. Sep 19 12:01:48.000 [notice] Your Tor server's identity key fingerprint is 'ins0 01A9258A46E97FF8B2CAC7910577862C14F2C524' Sep 19 12:01:48.000 [notice] Bootstrapped 0%: Starting Sep 19 12:01:48.000 [notice] Bootstrapped 5%: Connecting to directory server Sep 19 12:01:51.000 [notice] We now have enough directory information to build circuits. Sep 19 12:01:51.000 [notice] Bootstrapped 80%: Connecting to the Tor network Sep 19 12:01:51.000 [notice] Bootstrapped 85%: Finishing handshake with first hop Sep 19 12:01:52.000 [notice] Bootstrapped 90%: Establishing a Tor circuit Sep 19 12:01:52.000 [notice] Tor has successfully opened a circuit. Looks like client functionality is working. Sep 19 12:01:52.000 [notice] Bootstrapped 100%: Done Sep 19 12:01:52.000 [notice] Now checking whether ORPort 193.171.202.146:9001 and DirPort 193.171.202.146:9030 are reachable... (this may take up to 20 minutes -- look for log messages indicating success) Sep 19 12:01:53.000 [notice] Self-testing indicates your DirPort is reachable from the outside. Excellent. Sep 19 12:01:53.000 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor. Sep 19 12:01:55.000 [notice] Performing bandwidth self-test...done. Please note the difference (0.2.8.7): Sep 19 11:37:51.000 [notice] Now checking whether ORPort 193.171.202.150:9001 and DirPort 193.171.202.150:9030 are reachable... (this may take up to 20 minutes -- look for log messages indicating success) vs. (0.2.5.12): Sep 19 12:01:52.000 [notice] Now checking whether ORPort 193.171.202.146:9001 and DirPort 193.171.202.146:9030 are reachable... (this may take up to 20 minutes -- look for log messages indicating success) I.e. 0.2.8.7 does not seem to honor the address the socket is bound to when starting the reachability checks from the outside (it seems to use the address that either the default route is associated with or the OutboundBindAddress) - although the socket binding itself is done correctly (i.e. the netstat output is exactly the same for both versions, with tor binding to the specific IP address only for the Dir and both OR ports). Consequently, the node is declared as non-reachable and drops off the globe/atlas... Has this change been intentional? I have to admit we have not yet checked the source code for further debugging, as we wanted to get the node back up as quickly as possible (after our unfortunately timed holidays, sorry for that). with best regards, Rene

5 20

strange ARM results
by Rob van der Hoeven 20 Oct '16

20 Oct '16

Hi folks, I'm on a quest to find the average circuit-creation rate of clients. I looked in path-spec.txt to find an answer, but it wasn't there. So I thought: lets take some measurements using ARM. This got me some strange results. I start ARM, do some browsing, and close my browser. During the browsing ARM reports 3 circuits with ID's: 398, 399 and 400. These circuits are still there 45 minutes after the browser was closed. If I then restart ARM it reports that there are only two circuits, with circuit ID's 405 and 406. It looks to me that ARM does not update the circuits page when old circuits are closed and replaced by new circuits. It's also possible that ARM keeps old circuits alive after they are not being used anymore by my Tor proxy. Note: I use ARM version: 1.4.5.0, Tor version: 0.2.5.12 Regards, Rob. https://hoevenstein.nl

3 7

metrics-lib/DescripTor 1.5.0 is released
by Karsten Loesing 20 Oct '16

20 Oct '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hello devs, we just released metrics-lib/DescripTor 1.5.0: https://dist.torproject.org/descriptor/1.5.0/ - From the change log: # Changes in version 1.5.0 - 2016-10-19 * Major changes - Make the DescriptorCollector implementation that uses CollecTor's index.json file to determine which descriptor files to fetch the new default. Applications must provide gson-2.2.4.jar or higher as dependency. * Minor changes - Avoid running into an IOException and logging a warning for it. All the best, Karsten -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBCAAGBQJYCImbAAoJEC3ESO/4X7XBKKkH/Rk+Umu8asLOv2UQYBBsU6Mx nQzhap6XbeO3sFVNUK5KXA2Q35MRGOdeE8GWuroOm/JZu6v8A4xONKaMJqLV4EPK HRpIrsHtcgZFZ5maBYpJ866DA4vi7pnmLLG0kGhx94gj8tIneZuQZs96bDbVgdUP 0GXbC75bkVRiFWTnTpCAzP2cN+kmEjpK7XE0FSmMvdaLse5e7+p93doCEdwT3vjw a91zOm9nEOJWtUGdYfDBPToCVN2U4xFCzxASgdfZt5n7Ez+KmcyxCb2xh3bU2RSH MJ7PBCkdoMNnZgENDmIZqPNQ/3dRCw0Q0QcmpoZIKxdYpf4r7+Vf4o1n5912iaU= =2Xwl -----END PGP SIGNATURE-----

1 0

Tor Relays on Whonix Gateway
by bancfc＠openmailbox.org 20 Oct '16

20 Oct '16

Should Whonix document/encourage end users to turn clients into relays on their machines?

5 7

[RELEASE] Torsocks 2.2.0 stable
by David Goulet 18 Oct '16

18 Oct '16

Greetings! This is the release of Torsocks 2.2.0 stable version. One of the major change between this version and the previous RC1 is that we added a check for Apple's System Integrity Protection (a.k.a the next step for DRM protection in OS X :P). This prevents torsocks to work for any binaries located in: /usr/* (with an exception of /usr/local/*), /System/* /sbin/* /bin/* A note maybe to the packagers, the tarball is now compressed with xz. Apart from that, mostly bug and portability fixes. Here is the ChangeLog: 2016-10-18 torsocks 2.2.0 * Use xz for dist tarball now * Remove TODO as we use the bugtracker for those * execve: only include xattr.h for Linux * syscall: sched_getaffinity is only Linux * close: Prefix debug messages with [close] * Add check for Apple's System Integrity Protection. * Quote the non-zero length check of $getcap. * compat: Fix bad use of defined macro for OS X * Use AC_USE_SYSTEM_EXTENSIONS to try to use POSIX extensions * log: Fix whitespace in log.h * syscall: OS X doesn't support sched_getaffinity() * Fix memcpy buffer overrun in gethostbyaddr() * Fix memcpy() buffer overrun in gethostbyname() * Fix typo: catched -> caught * syscall: Whitelist sched_getaffinity(2) Tarball: https://people.torproject.org/~dgoulet/torsocks/torsocks-2.2.0.tar.xz http://sbe5fi5cka5l3fqe.onion/~dgoulet/torsocks/torsocks-2.2.0.tar.xz Sig: https://people.torproject.org/~dgoulet/torsocks/torsocks-2.2.0.tar.xz.asc http://sbe5fi5cka5l3fqe.onion/~dgoulet/torsocks/torsocks-2.2.0.tar.xz.asc Please let us know if anything went wrong or any bugs! https://trac.torproject.org Huge thanks to everyone who contributed by reporting issues, making patches and testing! Cheers! David

1 0

[prop269] Further changes to the hybrid handshake proposal (and NTor)
by isis agora lovecruft 18 Oct '16

18 Oct '16

Hello, After discussion with John Schanck and Trevor Perrin over the last month, we've decided to make some alterations to the specification for hybrid handshakes in Tor proposal #269. It seems that John, Trevor, and I are mostly in agreement about most of the construction. First, I'll try to summarise a list of changes and the reasoning/concerns which provoked them. For what it's worth, these concerns mostly involve highly theoretical problems surrounding whether we model a hash function with a random oracle or try to make some stronger claims to its properties, and aren't due to any real world attacks (assuming that hash functions do what you'd expect them to do and aren't something crazy like a NULL op or a pineapple slicing machine). Changes: 1. [NTOR] Inputs to HKDF-extract(SALT, SECRET) which are not secret (e.g. server identity ID, and public keys A, X, Y) are now removed from SECRET and instead placed in the SALT. Reasoning: *Only* secret data should be placed into the HKDF extractor, and public data should not be mixed into whatever entropic material is used for key generation. This eliminates a theoretical attack in which the server chooses its public material in such a way as to bias the entropy extraction. This isn't reasonably assumed to be possible in a "hash functions aren't probablistically pineapple slicers" world. Previously, and also in NTor, we were adding the transcript of the handshake(s) and other public material (e.g. ID, A, X, Y, PROTOID) directly into the secret portion of an HMAC call, the output of which is eventually used to derive the key material. The SALT for HKDF (as specified in RFC5869) can be anything, even a static string, but if we're going to be adding transcript material into the handshake, it shouldn't be in the entropy extraction phrase. 2. [NTOR] The authentication of transcript data, i.e. (ID, A, X, Y, EPK, C) where EPK is the public and ephemeral portion which the client sends in the post-quantum KEM, and C is the reconciliation data, is now distinctly separate from the production of SALT for the extractor, and is first HMACed separately (where the key is derived from the same HKDF extraction which produces the seed) before being included within the expansion phase. Reasoning: The idea is to avoid attempting to do context-binding (of the transcript, in this case) and entropy extraction at the same time, in order to have a stronger argument that the shared key used for authenticating the context is secure, whereas (before, in NTor) things were a bit murky. The use of auth_input in ntor was designed to prevent a certain type of collision attack (see [Zav12, SZW16]). However the auth_input countermeasure is unnecessary if the authentication tag is of length 2*LAMBDA. A collision attack on a random function of output length 2*LAMBDA has cost 2^LAMBDA. This change additionally avoids the collision attack. 3. The hashing of first SALT has been removed. (Or, alternatively, it's still there, assuming you're following the specification for HKDF extraction in RFC5869 to the T and hashing any incoming SALT longer than 32 bytes. If you're using something like SHAKE-256 or similar… well, it's not exactly clear or specified yet how to use SHAKE as a dropin replacement for a KDF. Joan is apparently writing something.) Reasoning: It was originally included due to concerns that a malicious adverary could potentially choose some SALT such that when passed into the HKDF-extractor, it would "nullify" the SECRET input rather than extracting from it. However, the HKDF-extractor is HMAC(SALT, SECRET) and we assume the HMAC's underlying hash function is not a machine which factors discrete logarithms or a slices pineapples. Were you to replace your own hash function with a pineapple slicer, you'd simply be creating a vulnerability for yourself, and thus it doesn't really make sense in Tor's case to hash the SALT first because we're not living in the horrible world where hash functions can turn out to be pineapple slicers. (And even if it were possible for them to be pineapple slicers, it personally still doesn't make sense to me why you'd want to protect against potential pineapple slicers by putting your data through a pineapple slicer twice.) Best regards, -- ♥Ⓐ isis agora lovecruft _________________________________________________________ OpenPGP: 4096R/0A6A58A14B5946ABDE18E207A3ADB67A2CDB8B35 Current Keys: https://fyb.patternsinthevoid.net/isis.txt

5 5

Note on my GPG key update
by Nick Mathewson 18 Oct '16

18 Oct '16

Hi! Please see https://people.torproject.org/~nickm/key-transition-statement-2.txt for information on my updated GPG key. Thanks! (I wouldn't ordinarily send this here, but this new key signs the Tor source and tags these days, so it's a good idea to make sure people know about it. The most recent releases were signed with both my old key and my new key: this is the last time that I'm planning to be doing that, however, since it seemed to confuse a lot of software.)

1 1

Proposal 273: Exit relay pinning for web services
by Philipp Winter 18 Oct '16

18 Oct '16

The proposal is in draft state. We have several open questions that we are still wrestling with in Section 2.6. Any feedback is greatly appreciated. You can track the evolution of our proposal online: <https://github.com/NullHypothesis/exit-pinning> --- Filename: 273-exit-relay-pinning.txt Title: Exit relay pinning for web services Author: Philipp Winter, Tobias Pulls, Roya Ensafi, and Nick Feamster Created: 2016-09-22 Status: Draft Target: n/a 0. Overview To mitigate the harm caused by malicious exit relays, this proposal presents a novel scheme -- exit relay pinning -- to allow web sites to express that Tor connections should preferably originate from a set of predefined exit relays. This proposal is currently in draft state. Any feedback is appreciated. 1. Motivation Malicious exit relays are increasingly becoming a problem. We have been witnessing numerous opportunistic attacks, but also highly sophisticated, targeted attacks that are financially motivated. So far, we have been looking for malicious exit relays using active probing and a number of heuristics, but since it is inexpensive to keep setting up new exit relays, we are facing an uphill battle. Similar to the now-obsolete concept of exit enclaves, this proposal enables web services to express that Tor clients should prefer a predefined set of exit relays when connecting to the service. We encourage sensitive sites to set up their own exit relays and have Tor clients prefer these relays, thus greatly mitigating the risk of man-in-the-middle attacks. 2. Design 2.1 Overview A simple analogy helps in explaining the concept behind exit relay pinning: HTTP Public Key Pinning (HPKP) allows web servers to express that browsers should pin certificates for a given time interval. Similarly, exit relay pinning (ERP) allows web servers to express that Tor Browser should prefer a predefined set of exit relays. This makes it harder for malicious exit relays to be selected as last hop for a given website. Web servers advertise support for ERP in a new HTTP header that points to an ERP policy. This policy contains one or more exit relays, and is signed by the respective relay's master identity key. Once Tor Browser obtained a website's ERP policy, it will try to select the site's preferred exit relays for subsequent connections. The following subsections discuss this mechanism in greater detail. 2.2 Exit relay pinning header Web servers support ERP by advertising it in the "Tor-Exit-Pins" HTTP header. The header contains two directives, "url" and "max-age": Tor-Exit-Pins: url="https://example.com/pins.txt"; max-age=2678400 The "url" directive points to the full policy, which MUST be HTTPS. Tor Browser MUST NOT fetch the policy if it is not reachable over HTTPS. Also, Tor Browser MUST abort the ERP procedure if the HTTPS certificate is not signed by a trusted authority. The "max-age" directive determines the time in seconds for how long Tor Browser SHOULD cache the ERP policy. After seeing a Tor-Exit-Pins header in an HTTP response, Tor Browser MUST fetch and interpret the policy unless it already has it cached and the cached policy has not yet expired. 2.3 Exit relay pinning policy An exit relay pinning policy MUST be formatted in JSON. The root element is called "erp-policy" and it points to a list of pinned exit relays. Each list element MUST contain two elements, "fingerprint" and "signature". The "fingerprint" element points to the hex-encoded, uppercase, 40-digit fingerprint of an exit relay, e.g., 9B94CD0B7B8057EAF21BA7F023B7A1C8CA9CE645. The "signature" element points to an Ed25519 signature, uppercase and hex-encoded. The following JSON shows a conceptual example: { "erp-policy": [ "start-policy", { "fingerprint": Fpr1, "signature": Sig_K1("erp-signature" || "example.com" || Fpr1) }, { "fingerprint": Fpr2, "signature": Sig_K2("erp-signature" || "example.com" || Fpr2) }, ... { "fingerprint": Fprn, "signature": Sig_Kn("erp-signature" || "example.com" || Fprn) }, "end-policy" ] } Fpr refers to a relay's fingerprint as discussed above. In the signature, K refers to a relay's master private identity key. The || operator refers to string concatenation, i.e., "foo" || "bar" results in "foobar". "erp-signature" is a constant and denotes the purpose of the signature. "start-policy" and "end-policy" are both constants and meant to prevent an adversary from serving a client only a partial list of pins. The signatures over fingerprint and domain are necessary to prove that an exit relay agrees to being pinned. The website's domain -- in this case example.com -- is part of the signature, so third parties such as evil.com cannot coerce exit relays they don't own to serve as their pinned exit relays. After having fetched an ERP policy, Tor Browser MUST first verify that the two constants "start-policy" and "end-policy" are present, and then validate the signature over all list elements. If any element does not validate, Tor Browser MUST abort the ERP procedure. If an ERP policy contains more than one exit relay, Tor Browser MUST select one at random, weighted by its bandwidth. That way, we can balance load across all pinned exit relays. Tor Browser could enforce the mapping from domain to exit relay by adding the following directive to its configuration file: MapAddress example.com example.com.Fpr_n.exit 2.4 Defending against malicious websites The purpose of exit relay pinning is to protect a website's users from malicious exit relays. We must further protect the same users from the website, however, because it could abuse ERP to reduce a user's anonymity set. The website could group users into arbitrarily-sized buckets by serving them different ERP policies on their first visit. For example, the first Tor user could be pinned to exit relay A, the second user could be pinned to exit relay B, etc. This would allow the website to link together the sessions of anonymous users. We cannot prevent websites from serving client-specific policies, but we can detect it by having Tor Browser fetch a website's ERP policy over multiple independent exit relays. If the policies are not identical, Tor Browser MUST ignore the ERP policies. If Tor Browser would attempt to fetch the ERP policy over n circuits as quickly as possible, the website would receive n connections within a narrow time interval, suggesting that all these connections originated from the same client. To impede such time-based correlation attacks, Tor Browser MUST wait for a randomly determined time span before fetching the ERP policy. Tor Browser SHOULD randomly sample a delay from an exponential distribution. The disadvantage of this defence is that it can take a while until Tor Browser knows that it can trust an ERP policy. 2.5 Design trade-offs We now briefly discuss alternative design decisions, and why we defined ERP the way we did. Instead of having a web server *tell* Tor Browser about pinned exit relays, we could have Tor Browser *ask* the web server, e.g., by making it fetch a predefined URL, similar to robots.txt. We believe that this would involve too much overhead because only a tiny fraction of sites that Tor users visit will have an ERP policy. ERP implies that adversaries get to learn all the exit relays from which all users of a pinned site come from. These exit relays could then become a target for traffic analysis or compromise. Therefore, websites that pin exit relays SHOULD have a proper HTTPS setup and host their exit relays topologically close to the content servers, to mitigate the threat of network-level adversaries. It's possible to work around the bootstrapping problem (i.e., the very first website visit cannot use pinned exits) by having an infrastructure that allows us to pin exits out-of-band, e.g., by hard-coding them in Tor Browser, or by providing a lookup service prior to connecting to a site, but the additional complexity does not seem to justify the added security or reduced overhead. 2.6 Open questions o How should we deal with selective DoS or otherwise unavailable exit relays? That is, what if an adversary takes offline pinned exit relays? Should Tor Browser give up, or fall back to non-pinned exit relays that are potentially malicious? Should we give site operators an option to express a fallback if they care more about availability than security? o Are there any aspects that are unnecessarily tricky to implement in Tor Browser? If so, let's figure out how to make it easier to build. o Is a domain-level pinning granularity sufficient? o Should we use the Ed25519 master or signing key? o Can cached ERP policies survive a Tor Browser restart? After all, we are not supposed to write to disk, and ERP policies are basically like a browsing history. o Should we have some notion of "freshness" in an ERP policy? The problem is that an adversary could save my ERP policy for example.com, and if I ever give up example.com, the adversary could register it, and use my relays for pinning. This could easily be mitigated by rotating my relay identity keys, and might not be that big a problem. o Should we support non-HTTP services? For example, do we want to support, say, SSH? And if so, how would we go about it? o HPKP also defines a "report-uri" directive to which errors should be reported. Do we want something similar, so site operators can detect issues such as attempted DoS attacks? o It is wasteful to send a 60-70 byte header to all browsers while only a tiny fraction of them will want it. Web servers could send the header only to IP addresses that run an exit relay, but that adds quite a bit of extra complexity. o We currently defend against malicious websites by fetching the ERP policy over several exit relays, spread over time. In doing so, we are making assumptions on the number of visits the website sees. Is there a better solution that isn't significantly more complex?

13 14

Building Torsocks for Armv7 - Build error
by Luca Bertoni 18 Oct '16

18 Oct '16

Goodmorning, I hope this is the correct section where to ask about building Torsocks. If that is the wrong place I apoligize and ask for a reference that can help me. So, I am trying to build torsocks for my armv7 smartphone. What I'm talking about is a cross-compilation, done using autools. After I have generated the configure script executing autogen.sh I configure torsocks using "./configure --host=armv7" and that doesn't raise errors. When I try to build it (using gnu-make) I get an error: ../src/lib/.libs/libtorsocks.a(log.o):(.data+0x0): multiple definition of `tsocks_loglevel' test_connect.o:(.data+0x0): first defined here I know what the error means but I can not figure out if I'm doing something wrong (that is the first time I cross-compile something so I am a newbie) or if there is a bug in the software. If it is a bug in the software I would like to submit it I downloaded torsocks from github (latest tag/release) and I am trying to build it using Debian 8.6 and gcc (Debian 4.9.2-10) 4.9.2. Thanks, Luca. Luca Bertoni

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-dev October 2016