- tor-dev - lists.torproject.org

Removing Countries with Low Counts from Metrics
by teor 07 Nov '16

07 Nov '16

Hi, Have we considered removing countries with low counts from metrics? (This probably means removing the metrics at the relays, not just the graphs.) For example, two places that are close to home for me: https://metrics.torproject.org/userstats-relay-country.html?graph=userstats… https://metrics.torproject.org/userstats-relay-country.html?graph=userstats… If you suspected that someone was one of the few users on either of these small islands, it would be easy to monitor these graphs and determine when they were using Tor. Particularly in combination with the Australian Government's ISP-based metadata retention. T -- Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org ------------------------------------------------------------------------------

2 1

Different trust levels using single client instance
by bancfc＠openmailbox.org 07 Nov '16

07 Nov '16

Summarized question: Do you recommend allowing Workstation VMs of different security levels to communicate with the same Tor instance? Note that they connect via separate internal networks to the Gateway and have different interfaces & controlports so inter-workstation communication should not be possible. Single Tor Gateway, Multiple Workstations Pros: *Same guard node means less chance of picking a malicious one *Single Gateway VM uses less resources Cons: *Some unforeseen way malicious VM "X" can link activities of or influence traffic of VM "Y" **Maybe sending NEWNYM requests in a timed pattern that changes exit IPs of VM Y's traffic, revealing they are behind the same client? **Maybe eavesdropping on HSes running on VM Y's behalf? **Something else we are not aware of? Multi-Tor Gateways mapped 1:1 to Workstation VMs Pros: *Conceptually simple. Uses a different Tor instance so no need to worry about all these questions. Cons: *Uses a different entry guard which can increase chance of running into a malicious relay that can deanonymize some of the traffic. * Uses extra resources (though not much as a Tor Gateway can run with as little as 192MB RAM)

4 6

Revisiting prop224 client authorization
by George Kadianakis 04 Nov '16

04 Nov '16

Hello, we've reached the point in prop224 development where we need to pin down the precise cell formats, so that we can start implementing them. HS client authorization has been one of those areas that are not yet finalized and are still influencing cell format. Here are some topics based on special's old notes, plus some further recent discussion with David and Yawning. a) I think the most important problem here is that the authorization-key logic in the current prop224 is very suboptimal. Specifically, prop224 uses a global authorization-key to ensure that descriptors are only read by authorized clients. However, since that key is global, if we ever want to revoke a single client we need to change the keys for all clients. The current rend-spec.txt does not suffer from this issue, hence I adapted the current technique to prop224. Please see my torspec branch `prop224_client_auth` for the proposed changes: https://gitweb.torproject.org/user/asn/torspec.git/log/?h=prop224_client_au… Some further questions here: i) Should we fake the client-auth-desc-key blob in case client authorization is not enabled? Otherwise, we leak to the HSDir whether client auth is enabled. The drawback here is the desc size increase (by about 330 bytes). Alternatively, we can try to put it in the encrypted part of the descriptor. So that we require subcredential knowledge to access the encrypted part, and then client_auth_cookie knowledge to get the encryption key to decrypt the intro points etc. I feel that this double-encryption design might be too annoying to implement, but perhaps it's worth it? ii) Should we use the descriptor ASCII format to encode all the client-auth-desc-key data? Or is that weird binary format OK? iii) Should we use a fresh IV for each ENCRYPTED_DESC_COOKIE? rend-spec.txt does not do that, and IIUC that's OK because it uses a fresh key for every encryption (even though the plaintext and IV is the same). b) Do we want a NACK from the HS for when client authorization fails? Currently the only way for a client to learn that they are not authorized (or that their keys changed or got revoked) is that they never complete the rendezvous. To achieve that we would need a whole new cell (INTRODUCE_SERVICE_NACK) from the hidden service all the way to the client. Worth it? c) Another suggestion here by special, is to introduce an additional layer of access control at the HSDir request level, such that HSDirs don't even serve descriptors to clients that do not prove knowledge of a pre-shared fetch key. This way unauthorized clients cannot even learn presense information of hidden services. This might be quite useful for applications like Ricochet, who want to hide their presense from revoked clients. Of course this assumes that the HSDir is honest and will honor the fetch key protocol. However, even if the HSDir is dishonest we are just back to the current security level. We started sketching out a solution in the bottom of these notes: https://people.torproject.org/~asn/hs_notes/client_auth.jpg but the solution is not trivial to implement and we are not sure whether it's worth complicating the protocol further (e.g. we need to design a way for apps like Ricochet to get access to the fetch key). d) It might be worthwhile padding the encrypted part of INTRODUCE1 to obscure whether client authorization is in place. As you can see I have mainly worked on point (a) which I consider the most urgent. I welcome feedback on all points, so that we move forward with the design here. Thanks :)

5 14

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 30 Oct '16

30 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