- tor-dev - lists.torproject.org

Using fingerprint of cached relay bypasses bridge?
by David Fifield 02 Nov '16

02 Nov '16

Someone on #tor-project IRC reported that you can bypass your pluggable transport if you use the fingerprint of an ordinary relay already known to Tor in your bridge line. I would file a ticket but I haven't been able to reproduce it. The example the IRC user gave was this, meant to be pasted into Tor Browser as a custom bridge: Bridge meek 0.0.2.0:2 3C3A6134E4B5B7D1C18AD4E86EE23FAC63866554 url=https://d2zfqthxsdq309.cloudfront.net/ front=a0.awsstatic.com The fingerprint is the wrong one for this bridge. It should be B9E7141C594AF25699E0079C1F0146F409495296 for the bridge nicknamed TorLandMeek. It is instead for the relay nicknamed traffic70 at 188.138.1.166:9001. The claim is that if tor has already cached a descriptor with fingerprint 3C3A6134E4B5B7D1C18AD4E86EE23FAC63866554, then it will make a direct connection for the purpose of making a one-hop circuit. "it's about one hop tunnel when exit is entry" says the IRC user. They point to these parts of the source code: https://gitweb.torproject.org/tor.git/tree/src/or/circuituse.c?id=tor-0.2.8… r = node_get_by_nickname(conn->chosen_exit_name, 1); https://gitweb.torproject.org/tor.git/tree/src/or/circuituse.c?id=tor-0.2.8… extend_info = extend_info_from_node(r, conn->want_onehop ? 1 : 0); I wasn't able to reproduce it. I used this torrc file: DataDirectory datadir UseBridges 1 Bridge meek 0.0.2.0:2 3C3A6134E4B5B7D1C18AD4E86EE23FAC63866554 url=https://d2zfqthxsdq309.cloudfront.net/ front=a0.awsstatic.com ClientTransportPlugin meek exec ./meek-client --log meek-client.log First I tried with a cold cache, and got a fingerprint mismatch: Nov 01 18:00:53.000 [notice] Bootstrapped 10%: Finishing handshake with directory server Nov 01 18:00:54.000 [warn] Tried connecting to router at 0.0.2.0:2, but identity key was not as expected: wanted 3C3A6134E4B5B7D1C18AD4E86EE23FAC63866554 but got B9E7141C594AF25699E0079C1F0146F409495296. Nov 01 18:00:54.000 [warn] Problem bootstrapping. Stuck at 10%: Finishing handshake with directory server. (Unexpected identity in router certificate; IDENTITY; count 1; recommendation warn; host 3C3A6134E4B5B7D1C18AD4E86EE23FAC63866554 at 0.0.2.0:2) Then I commented out "UseBridges 1", let the bootstrap finish, and uncommented "Use Bridges 1" again. I got the same output: Nov 01 18:05:06.000 [notice] Bootstrapped 10%: Finishing handshake with directory server Nov 01 18:05:09.000 [warn] Tried connecting to router at 0.0.2.0:2, but identity key was not as expected: wanted 3C3A6134E4B5B7D1C18AD4E86EE23FAC63866554 but got B9E7141C594AF25699E0079C1F0146F409495296. Nov 01 18:05:09.000 [warn] Problem bootstrapping. Stuck at 10%: Finishing handshake with directory server. (Unexpected identity in router certificate; IDENTITY; count 1; recommendation warn; host 3C3A6134E4B5B7D1C18AD4E86EE23FAC63866554 at 0.0.2.0:2) I used tcpdump to check for connections to 188.138.1.166, and didn't see any.

3 6

ANN: OnionPy 0.3.3
by Lukas Erlacher 01 Nov '16

01 Nov '16

Hello all, I've updated OnionPy! In the last 12 months, it has gotten some clean-up work and an interface to the Django cache layer thanks to @ad-m on Github. This apparently also marks the first serious consumer of OnionPy! Woo! [1] Signed builds are on PyPI. [2] OnionPy is a pure-python OnionOO request wrapper that supports transparent caching. If you are planning to make something in python that uses the tor network status, accessing OnionOO [3] using OnionPy might be exactly what you need. If you are interested, check out the repo and readme. [4] Of course criticism, suggestions, and pull requests are always welcome. Best regards, Luke [1] https://github.com/ad-m/telescope/ [2] https://pypi.python.org/pypi/OnionPy [3] https://onionoo.torproject.org/ [4] https://github.com/duk3luk3/onion-py

1 0

handling TLS Session Ticket/Identifier for Android
by Hans-Christoph Steiner 31 Oct '16

31 Oct '16

Hey all, Since tor devs have thought about how to handle TLS Session Tickets and Identifiers, I want to capture that approach and stick it into our NetCipher library, which is also used in Orfox. As I understand it, the approach is: * disable TLS Session Tickets entirely * reset TLS Session Identifiers on NEWNYM Any plans to rethink this for TLS v1.3? Any other TLS tracking issues I should be addressing in NetCipher? I'd also appreciate any references on this topic (yes, I know how to find the relevant RFCs ;), like tor trac tickets. My searches have come up with very little. .hc -- PGP fingerprint: EE66 20C7 136B 0D2C 456C 0A4D E9E2 8DEA 00AA 5556 https://pgp.mit.edu/pks/lookup?op=vindex&search=0xE9E28DEA00AA5556

3 3

[Proposal] A simple way to make Tor-Browser-Bundle more portable and secure
by Daniel Simon 31 Oct '16

31 Oct '16

Hello. How it's currently done - The Tor Browser Bundle is dynamically linked against glibc. Security problem - The Tor Browser Bundle has the risk of information about the host system's library ecosystem leaking out onto the network. Portability problem - The Tor Browser Bundle can't be run on systems that don't use glibc, making it unusable due to different syscalls. Solution proposed - Static link the Tor Browser Bundle with musl libc.[1] It is a simple and fast libc implementation that was especially crafted for static linking. This would solve both security and portability issues. What is Tor developers' opinion about this? I personally don't see any drawbacks and would be interested in discussing this further. Sincerely, Daniel [1] https://www.musl-libc.org/

6 8

CollecTor Release 1.1.0
by iwakeh 28 Oct '16

28 Oct '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi there! CollecTor 1.1.0 is available: https://dist.torproject.org/collector/1.1.0/ The release provides many configuration improvements and enables CollecTor to sync descriptors from other instances, i.e. if the sync-run is configured, CollecTor fetches recent descriptors from one or more remote CollecTor instances, verifies these descriptors, and sorts them into the local descriptor store. Synchronization is implemented for relay descriptors (except microdescriptors), sanitized bridge descriptors, and exit lists. To get the most out of the new release it is highly advisable to read INSTALL.md from the release tarball [0]. If you have already a running CollecTor instance, be aware that the configuration is different now and you need to adapt to the new configuration. Please direct comments and questions to the metrics-team mailing list [2]. And, of course, bug reports [3] or feature requests [4] can be filed in trac. Cheers, iwakeh [0] https://dist.torproject.org/collector/1.1.0/ [1] https://collector.torproject.org [2] https://lists.torproject.org/cgi-bin/mailman/listinfo/metrics-team [3] https://trac.torproject.org/projects/tor/newticket?component=Metrics/Collec… [4] https://trac.torproject.org/projects/tor/newticket?component=Metrics/Collec… -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAlgTc8oACgkQsANAxTOj/abiQwD/YdmXRYVy7QTGUAEHh6Q8+QJL 3KpzsDGWsx3JoKnGgYEBAIT5T1E6yf+Rqj1c8X3JN1pDiP0bCNH3eHvMU2tGLsyv =JBqs -----END PGP SIGNATURE-----

1 0

Call for help on testing core tor releases
by isabela＠riseup.net 26 Oct '16

26 Oct '16

Hello Tor community! The Core Tor Team would like to improve our release process by getting it more tested so bugs are found earlier, so stable releases can get out faster and without any big bugs. During Tor's Meeting in Seattle a couple of weeks ago, we discussed this topic and decided to organize a QA team (with the help of the community) for core tor. So we decided to make a call for volunteers to help us with testing our 0.2.9 release so we can catch bugs asap. We are planning on freezing our alpha release this Monday, October 17th, the test period is from 17-31 of October. [release calendar: https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam#Releases ] But if you can test it on the week of the 17, please do so because the sooner the better for us to be able to fix the bugs. Also, please understand that giving so many things we have on our plates, we will have to triage and prioritize bugs reported. This means some might be defer to another release. Below you can read more about what we are asking from you ;) and what our goals are. If you think you can help us, please reply to this email letting us know. What we are asking volunteers: * Validate release signature/checksum * Does it build with _no_ Warnings? * Does "make test" pass? * Does "make test-network-all" pass? (you'll need chutney for this - chutney does not work on Windows) * Does it work as a client? As a relay? As a hidden service ? * Does it work if you drop the binary into (eg) torpbrowser? We are hoping to find enough people that we can test the releases on as many OS's as possible. Some OS-specific notes: * on Linux and BSD, Tor requires some dependencies (read INSTALL). * on OS X, you'll need to choose a package manager (HomeBrew, MacPorts, Fink), or install dependencies from source, * either way, you will need to tell configure where the dependencies are located. * on Windows, people sometimes have trouble building Tor. Help us update our build instructions for Windows! Our goals: * We hope to have tor alpha releases tested within a week of it going out * We hope to have people testing it on as many OS's as possible * Reduce the number of bugs found when we launch a release candidate and/or stable release * We want operating systems and configurations other than the ones we use in development to get tested BEFORE we declare the release stable. If you read so far, like the idea but, this is just bad timing for you to join us and help out with the project. No problem! luckily we will have more core tor releases in the future :) so that means there will always be an opportunity to help. We will keep this list updated as we move forward with this project so hopefully you can join us latter! Please let us know if you have any questions about this - and thank you in advance. Cheers, Isabela / on behalf of core tor ps: email from Nick on 0.2.9 freeze dates if you miss it https://lists.torproject.org/pipermail/tor-dev/2016-October/011513.html

8 11

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