September 2016 - tor-dev - lists.torproject.org

Reducing initial onion descriptor upload delay (down to 0s?)
by Ivan Markin 29 Sep '16

29 Sep '16

Hi tor-dev@! Moving the discussion on the future of rendinitialpostdelay from ticket #20082 [1] here. Transcribing the issue: > At the moment descriptor is getting posted at > MIN_REND_INITIAL_POST_DELAY (30) seconds after onion service > initialization. For the use case of real-time one-time services > (like OnionShare, etc) one has to wait for 30 seconds until this > onion service can be reached. Besides, if a client tries to reach > the service before its descriptor is ever published, tor client gets > stuck preventing user from reaching this service after descriptor is > published. Like this: Could not pick one of the responsible hidden > service directories to fetch descriptors, because we already tried > them all unsuccessfully. > It has jumped to 30s from 5s due to "load on authorities". > 11d89141ac0ae0ff371e8da79abe218474e7365c: > > + o Minor bugfixes (hidden services): + - Upload hidden service > descriptors slightly less often, to reduce + load on > authorities. > > "Load on authorities" is not the point anymore because we don't use > V0 since 0.2.2.1-alpha. Thus I think it's safe to drop it back to at > least 5s (3s?) for all services. Or even remove it at all? The questions are: * Can we drop this delay? Why? * Can we set it back to 5s thus avoiding issues that can arise after removing the delay? * Should we do something now or postpone it to prop224? [1] https://trac.torproject.org/projects/tor/ticket/20082 -- Ivan Markin

6 10

prop224: Ditching key blinding for shorter onion addresses
by George Kadianakis 29 Sep '16

29 Sep '16

Hello people, this is an experimental mail meant to address legitimate usability concerns with the size of onion addresses after proposal 224 gets implemented. It's meant for discussion and it's far from a full blown proposal. Anyway, after prop224 gets implemented, we will go from 16-character onion addresses to 52-character onion addresses. See here for more details: https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-ng.t… This happens because we want the onion address to be a real public key, and not the truncated hash of a public key as it is now. We want that so that we can do fun cryptography with that public key. Specifically, we want to do key blinding as specified here: https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-ng.t… As I understand it the key blinding scheme is trying to achieve the following properties: a) Every HS has a permanent identity onion address b) Clients use an ephemeral address to fetch descriptors from HSDir c) Knowing the ephemeral address never reveals the permanent onion address c) Descriptors are encrypted and can only be read by clients that know the identity onion key d) Descriptors are signed and verifiable by clients who know the identity onion key e) Descriptors are also verifiable in a weaker manner by HSDirs who know the ephemeral address In this email I'm going to sketch a scheme that has all above properties except from (e). The suggested scheme is basically the current HSDir protocol, but with clients using ephemeral addresses for fetching HS descriptors. Also, we truncate onion address hashes to something larger than 80bits. Here is a sketch of the scheme: ------ Hidden service Alice has a long-term public identity key: A Hidden service Alice has a long-term private identity key: a The onion address of Alice, as in the current scheme, is a truncated H(A). So let's say: onion_address = H(A) truncated to 128 bits. The full public key A is contained in Alice's descriptor as it's currently the case. When Alice wants to publish a descriptor she computes an ephemeral address based on the current time period 't': ephemeral_address = H(t || onion_address) Legitimate clients who want to fetch the descriptor also do the same, since they know both 't' and 'onion_address'. Descriptors are encrypted using a key derived from the onion_address. Hence, only clients that know the onion_address can decrypt it. Descriptors are signed using the long-term private key of the hidden service, and can be verified by clients who manage to decrypt the descriptor. --- Assuming the above is correct and makes sense (need more brain), it should maintain all the security properties above except from (e). So basically in this scheme, HSDirs won't be able to verify the signatures of received descriptors. The obvious question here is, is this a problem? IIUC, having the HSDirs verify those signatures does not offer any additional security, except from making sure that the descriptor signature was actually created using a legitimate ed25519 key. Other than that, I don't see it offering much. So, what does this additional HSDir verification offer? It seems like a weak way to ensure that no garbage is uploaded on the HSDir hash ring. However, any reasonable attacker will put their garbage in a descriptor and sign it with a random ed25519 key, and it will trivially pass the HSDir validation. So do we actually care about this property enough to introduce huge onion addresses to the system? Please discuss and poke holes at the above system. Cheers!

11 23

Paper on how DNS affects Tor's anonymity
by Philipp Winter 28 Sep '16

28 Sep '16

My colleagues and I published a (not yet peer-reviewed) research paper on how DNS affects Tor's anonymity. The key parts of our work are: - We measure the DNS setup of exit relays over time, showing that at times Google got to see almost 40% of DNS requests coming out of Tor. - We show how website fingerprinting attacks can be augmented with observed DNS requests, resulting in precise attacks for unpopular websites. - Similar to the "Users Get Routed" work, we simulate the impact of our attack at Internet-scale using the TorPS simulator. The PDF is available online: <https://nymity.ch/tor-dns/tor-dns.pdf> Our project page has code, data, and replication instructions: <https://nymity.ch/tor-dns/>

2 1

onion moshing
by David Stainton 25 Sep '16

25 Sep '16

I was inspired by onioncat to write a twisted python implementation. Onionvpn doesn't have as many features as onioncat. I've successfully tested that onionvpn and onioncat can talk to each other and play nice. Both onionvpn and onioncat implement a virtual public network. Anyone can send packets to you if they know your onion address or ipv6 address... however injection attacks are unlikely since the attacker cannot know the contents of your traffic without compromising the tor process managing the onion service. I've also tested with mosh; that is, you can use mosh which only works with ipv4 over an ipv4-to-ipv6 tunnel over onionvpn/onioncat. Like this: mosh-client -> udp/ipv4 -> ipv6 -> tun device -> tcp-to-tor -> onion service decodes ipv6 to tun device -> ipv6 -> udp/ipv4 -> mosh-server https://github.com/david415/onionvpn If an onionvpn/onioncat operator were to NAT the onion ipv6 traffic to the Internet then that host essentially becomes a special IPv6 exit node for the tor network. The same can be done for IPv4. Obviously operating such an exit node might be risky due to the potential for abuse... however don't you just love the idea of being about to use low-level network scanners over tor? I wonder if Open Observatory of Network Interference would be interested in this. david

4 3

More tor browser sandboxing fun.
by Yawning Angel 22 Sep '16

22 Sep '16

Hi, Note: * Don't use this unless you are capable of debugging it. * Don't use this if you need strong security (though the author believes it is an improvement over unsandboxed Tor Browser, and the previous sandboxing attempts). * Don't re-package it, it's not ready for that. In addition to stewing in my infinite self-loathing, I made a serious attempt at sandboxing Tor Browser again. It works, is kind of neat, and isn't totally horrible, so I'm showing what's available. Where: https://git.schwanenlied.me/yawning/sandboxed-tor-browser This builds a lightweight launcher process that will: * Handle installing/updating Tor Browser, while being rather paranoid about having a good trust root (hard copies of PGP keys, the update service's cert chain, and the MAR signing key are included and enforced). * Run the updater in a sandboxed environment without network access. * Run Tor Browser in a sandboxed enviornment with the Tor SocksPort being the only way to get beyond the host. There's a bunch of caveats, and some functionality that's intentionally broken, and certain annoyances that require a Tor Browser patch or two to fix, but it appears to work fairly well. The README.md file has more detailed documentation on how it works, the sandbox environment, and the various caveats. -- Yawning Angel

3 5

More changes to CollecTor's sanitized bridge descriptors: sanitized TCP ports, tarballs per descriptor type
by Karsten Loesing 19 Sep '16

19 Sep '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi devs, lots of changes to CollecTor's sanitized bridge descriptors these weeks. A few weeks ago there was the switch from Tonga to Bifroest change: https://lists.torproject.org/pipermail/tor-dev/2016-August/011336.html This message is about two unrelated changes that may impact whoever uses CollecTor's sanitized bridge descriptors. From the change log: - Replace TCP ports with hashes in @type bridge-network-status 1.1 and @type bridge-server-descriptor 1.2. - Split up bridge descriptor tarballs into one tarball per month and descriptor type: bridge-statuses-YYYY-MM.tar.xz, bridge-server-descriptors-YYYY-MM.tar.xz and bridge-extra-infos-YYYY-MM.tar.xz. You can find more details on the CollecTor page: https://collector.torproject.org/#bridge-descriptors Sorry for any inconvenience caused by this! All the best, Karsten -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJX4APZAAoJEC3ESO/4X7XBZ70H/i854yW5aaAld294w/SRXG+f 3GzQYMs6CEikTcN8g5ZgYXyIYV1Bf+SuwfrZCwoLiKl8AqUY4gAxhj9ZbldkcFdu u3cGDJDM5qVmghCoIfpdq8BsqXpfk8PnyYhHSc8rmZaMG8hReKMUsKNO1Mp7BQHT a62n9PIV3CnZal43f5o3y/XssK/qY+CVlDtsnHzB1fEYap7txszgC9yXMlMeCuOn +eyDEkWo+EVQP2OLle+uvKLow7ywgXAsI7IwUQtU4l588cUlWv9UNkC6NYV4ydf0 8EwPqdGe7ecDvj/jsu9ZuK6LnZwmZChYep9nGTK1xC6LDDghRS9d6mnOnStCo14= =tv4B -----END PGP SIGNATURE-----

1 0

Please consider allowing /48 for VirtualAddrNetworkIPv6
by Alex Elsayed 17 Sep '16

17 Sep '16

Hi, I'm using Tor in transparent mode, and I'm running into a rather inconvenient behavior. VirtualAddrNetworkIPv6 refuses to parse unless the network address given is a /40 or broader. However, IPv6 ULA, which makes it very easy to give Tor its own subnet no-strings-attached, strictly grants a /48 prefix. As a result, I am faced with a choice between deeply suboptimal options: 1.) Use VirtualAddrNetworkIPv4, as I've done in the past. This results in _fewer_ addresses being available to Tor than an IPv6 /48, which I feel illustrates the issues with requiring a /40 quite clearly. 2.) Squat on some portion of the IPv6 address space I don't actually own. This is entirely unpalatable

3 5

OnionView : A GUI to view circuits & streams
by Kevin Steen 16 Sep '16

16 Sep '16

I wanted a way to watch the streams being created while using TorBrowser, so I've created a Python Tk GUI to show the circuits and their associated streams: https://github.com/skyguy/onionview Each circuit is shown with the relays' country codes and nicknames. Streams are listed below the circuit they're attached to, showing the domain name and resolved IP. The view scrolls automatically when a circuit or stream is first shown. It's quite simple, without any bells and whistles yet, but quite useful to see what's going on while waiting for a webpage to display, so I thought I'd put it out there in case someone else finds it useful. OnionView uses the excellent Stem library, so make sure you have that installed. It works with Python 2 and 3. All feedback and advice welcome! -Kevin

3 3

Reg:https-everywhere
by AKASH DAS 15 Sep '16

15 Sep '16

Respected all, Can I ask my doubts regarding https-everywhere and any bugs issue in this mailing list as I already posted one bug but I didn't get any reply regarding that error. So any help would be very helpful to me. -- *Akash Das* *Student Systems Admin* *Indian Institute Of Information Technology* *Sricity*

2 1

"old style" hidden services after Prop224
by Razvan Dragomirescu 14 Sep '16

14 Sep '16

Hello everyone, I've pretty much completed a proof of concept of my SIM4Things project (an IP6 overlay for the Internet of Things running on top of Tor with persistent secure cryptographic identities tied to physical SIM cards). I've developed against the current hidden service infrastructure and it appears to work like a charm, but I'm a bit worried about Prop224. That will break both the OnionBalance-like service re-registration that I'm using _and_ the OnionCat HS to IP6 mapping. I know that efforts are in place to upgrade the two in view of Prop224 but I'm wondering if there's any good reason to drop support for "old style" hidden services once Prop224 is fully deployed. What does everyone think? My vote would obviously be to keep it around, even if it's no longer the default. Do you see any security implications in doing so? Is there any hard reason to drop the existing model altogether at some point and if so, what is the plan for transition? My hidden services would be very low traffic (Internet of Things, sensor measurements, etc) but hard to upgrade in the field. Also, by design, we have no control over the endpoints once deployed (only their owner can access them), so we cannot force an upgrade, we can just suggest it to the owner and come up with a procedure for them to do so. Any ideas? Thank you, Razvan -- Razvan Dragomirescu Chief Technology Officer Cayenne Graphics SRL

6 15