- tor-dev - lists.torproject.org

A few wtf-pad/prop254 questions
by Nick Mathewson 07 Nov '18

07 Nov '18

Hi! I'm looking over prop254 and I have a few questions or clarification requests that I hope will make things clearer to me. Some of these are probably "wrong questions" that stem from a misunderstanding of the underlying proposal. 1) What does "ito" stand for? Is it documented? 2) How is RTT measurement meant to work? It seems to me from reading section 3.1 that middle if a middle node sees a delay of N ms between getting a cell in the forward direction, and getting a cell in the backward direction, then it will conclude that the RTT is at least N ms. But that doesn't make sense to me -- the latter cell might have been sent in response to a different cell, or sent asynchonously, and not in response to the first cell at all. AFAICT unless we can be reasonably sure that we are seeing a packet that is sent in response to an earlier cell, be sure that we're actually measuring min(rtt). Maybe some pseudocode would help me understand better. 3) In section 3.1, I'm assuming that "cell sent" and "cell received" refer to a cell that we are originating, and a cell that we are receiving, recognizing, and processing: relayed cells don't count. Is that correct? 4) I like that section 3.1.1 specified delays in terms of microseconds, but we should be aware that with current implementation restrictions, microsecond-level precision is unlikely to actually be realistic. I hope that's okay. 5) In section 3.1.1, can we include a formula for the bounds of the n'th bin? 6) In section 3.1.1, why is a uniform distribution used, and not some other distribution? 7) In section 3.1 (I'm not sure where) can we specify how bins are initialized, and how they are refilled (if at all)? 8) For machine negotiation (in section 3.3), I'd suggest that we have the client send a list of acceptable machines in preference order, rather than demanding a particular machine. I think a 16-bit identifier is safer than an 8-bit one. We should reserve an area of the identifier space for experimental use. 9) Can we include an example definition of one of these state machines, with pseudocode included? 10) Should clients (eventually) begin killing circuits if they receive padding from an unexpected place? cheers, -- Nick

3 2

Proposal 298: Putting family lines in canonical form
by Nick Mathewson 31 Oct '18

31 Oct '18

Filename: 298-canonical-families.txt Title: Putting family lines in canonical form Author: Nick Mathewson Created: 31-Oct-2018 Status: Open Target: 0.3.6.x 1. Introduction With ticket #27359, we begin encoding microdescriptor families in memory in a reference-counted form, so that if 10 relays all list the same family, their family only needs to be stored once. For large families, this has the potential to save a lot of RAM -- but only if the families are the same across those relays. Right now, family lines are often encoded in different ways, and placed into consensuses and microdescriptor lines in whatever format the relay reported. This proposal describes an algorithm that authorities should use while voting to place families into a canonical format. This algorithm is forward-compatible, so that new family line formats can be supported in the future. 2. The canonicalizing algorithm To make a the family listed in a router descriptor canonical: For all entries of the form $hexid=name or $hexid~name, remove the =name or ~name portion. Remove all entries of the form $hexid, where hexid is not 40 hexadecimal characters long. If an entry is a valid nickname, put it into lower case. If an entry is a valid $hexid, put it into upper case. If there are any entries, add a single $hexid entry for the relay in question, so that it is a member of its own family. Sort all entries in lexical order. Remove duplicate entries. Note that if an entry is not of the form "nickname", "$hexid", "$hexid=nickname" or "$hexid~nickname", then it will be unchanged: this is what makes the algorithm forward-compatible. 3. When to apply this algorithm We allocate a new consensus method number. When building a consensus using this method or later, before encoding a family entry into a microdescriptor, the authorities should apply the algorithm above. Relay MAY apply this algorithm to their own families before publishing them. Unlike authorities, relays SHOULD warn about unrecognized family items.

1 0

Updates and review on "Proposal 254: Padding Negotiation"
by George Kadianakis 30 Oct '18

30 Oct '18

Hey Mike, I took another look at prop#254 and made some changes of my own in my torspec branch circuitpadding-proposal-updates (see commit ab37543). Let me know if they look right to you. Some of those I had to look into the code to understand, and I hope I got them right. Furthermore, I opened a pull request with a few questions and comments for further improvements and clarifications: https://github.com/torproject/torspec/pull/39 Cheers!

1 0

Re: [tor-dev] obfs4, meek, active probing and the timeline of pluggable transports
by Piyush Kumar Sharma 29 Oct '18

29 Oct '18

Hello all, I have a few specific questions related to the pluggable transports. 1.) I believe that obfs4 stops active probing(the latest problem as brought to notice by Ensafi et al, IMC 2015 and Shinying Cho, FOCI 2018), and hence discovering obfs4 Tor bridges using active probing is not possible. Is that true? If so, then we are good to go and hence we don't need any other pluggable transport to work for us as long as obfs4 is working? 2.) What was the motivation to bring in meek as a pluggable transport, given the fact that obfs4 works great to cover all the existing problems with Tor detection. Was the motivation just the fact that, it will be much easier for the users to use meek than obfs4 or something other than this? 3.) I searched a lot but could not find the timeline in which pluggable transports were built. As in what was developed and deployed first, obfs4 or meek? Regards Piyush IIITD

7 6

Add EVENT message to pt-spec.txt and control-spec.txt
by David Goulet 29 Oct '18

29 Oct '18

Greetings tor-dev! We've been working on improving PT reporting towards Tor so for instance Tor Browser can better inform the user or take actions based on the PT state when connecting to the network. The following ticket summarize it: https://trac.torproject.org/projects/tor/ticket/28180 To achieve this, we are submitting these to torspec.git patches to extend both the pt-spec.txt and control-spec.txt to support such mechanism. This is the first draft. Below is the link to the PT spec patch. It adds the EVENT message that for now is only used, as you will see, for reporting connection status message. However, you should see this EVENT message as extendable to whatever the PT would like to report to Tor that we can think of in the future: https://gitweb.torproject.org/user/dgoulet/torspec.git/commit/?h=ticket2818… The second, is simpler, it is how Tor will send it back to the control port: https://gitweb.torproject.org/user/dgoulet/torspec.git/commit/?h=ticket2818… Please, any questions or feedbacks is very welcome! The main idea here is to keep things simple and extendable. Note that since Tor doesn't implement the PT 2.0 spec yet, we haven't done anything for that spec but after skimming the version 2, I think we can easily move this EVENT message concept if we want it. Cheers! David -- t2Mtu4qBote14xSTFee/xnHlXp1eabwHFbehBlktnus=

2 2

(no subject)
by sarpedon montecarlo 26 Oct '18

26 Oct '18

Hi! I am supposed to implement, a python application that runs tor in background. The running tor is under direct control of the python app via control port. This running tor, is the proxy for the Tor Browser; By this I mean, when the Tor Browser starts, it will connect to this process, instead of the bundled tor provided by itself. The controlling features I am into, are as below: A) I want to attach streams coming from each tabs of the Tor Browser, attached to a separate circuit; By this I mean each tab of the browser, use a separate circuit, and do not share circuits with each other.(just like the way ordinary TBB does that) for this I am aware that Tor Button plugin does something with the streams to separate streams of a specific tab from other streams. Then by using IsolateSocksStream option on the tor side, tor will successfully isolate each tabs streams. My problem here, is that I am handling the routing and stream attaching all by myself and I can not use the provided IsolateSocksStream option because I am handling the circuit generation by myself because of the specific policies I am using for generating circuits, and their related paths. So if I am facing a bunch of streams, and I have a bunch of circuits myself, How am I going to detect that Stream A is from tab A of TBB and Stream B is from tab B of TBB, so I attach stream A to circuit A, and attach stream B to circuit B. Thanks in advance.

2 1

UX improvement proposal: Onion auto-redirects using Alt-Svc HTTP header
by George Kadianakis 26 Oct '18

26 Oct '18

UX improvement proposal: Onion auto-redirects using Alt-Svc HTTP header ======================================================================== 1. Motivation: Lots of high-profile websites have onion addresses these days (e.g. Tor , NYT, blockchain, ProPublica). All those websites seem confused on what's the right way to inform their users about their onion addresses. Here are some confusion examples: a) torproject.org does not even advertise their onion address to Tor users (!!!) b) blockchain.info throws an ugly ASCII page to Tor users mentioning their onion address and completely wrecking the UX (loses URL params, etc.) c) ProPublica has a "Browse via Tor" section which redirects to the onion site. Ideally there would be a consistent way for websites to inform their users about their onion counterpart. This would provide the following positives: + Tor users would use onions more often. That's important for user education and user perception, and also to partially dispell the darkweb myth. + Website operators wouldn't have to come up with ad-hoc ways to advertise their onion services, which sometimes results in complete breakage of the user experience (particularly with blockchain) This proposal specifies a simple way forward here that's far from perfect, but can still provide benefits and also improve user-education around onions so that in the future we could employ more advanced techniques. Also see Tor ticket #21952 for more discussion on this: https://trac.torproject.org/projects/tor/ticket/21952 2. Proposal Websites use the Alt-Svc HTTP header to specify their onion counterpart: http://httpwg.org/http-extensions/alt-svc.html The Tor Browser intercepts that header (if any) and auto-redirects the user to the onion site. Tor Browser only does so if the header is served over HTTPS. (That's it.) 3. Improvements 3.1. User education through notifications To minimize the probability of users freaking out about auto-redirects Tor Browser could inform the user that the auto-redirect is happening. This could happen with a small notification bar [*] below the URL bar informing users that "Tor Browser is auto-redirecting you to the secure onion site". The notification bar could also have a question mark button that provides the user with additional information on the merits of onion sites and why they should like them. [*]: like this one: http://www.topdreamweaverextensions.com/UserFiles/Image/firefox-bar.jpg 3.2. Auto-redirects too intrusive? Make them optional. If we think that auto redirects are too intrusive, we should consider making them optional, or letting the website specify the desired behavior. If a website wants to specify an onion address but doesn't like auto-redirects, it could specify that as part of Alt-Svc and we could still inform the user that an onion is available using a notification bar again. 4. Drawbacks This proposal is far from the perfect solution of course. Here are a few reasons why: 4.1. Auto-redirects are scary Novice users or paranoid users might freak out with auto-redirects since it's unexpected. They might think they are under attack or they got hacked. An argument against that is that we are already using HTTPS-everywhere which is basically a redirection layer, and while its redirection technique is simpler, sometimes the derivative URL is not similar to the original URL, and we still don't see people freaking out. I think that's because people trust Tor Browser to do the right thing. Combining this knowledge with section 3.1 might solve this problem. 4.2. No security/performance benefits While we could come up with auto-redirect proposals that provide security and performance benefits, this proposal does not actually provide any of those. As a matter of fact, the security remains the same as connecting to normal websites (since we trust its HTTP headers), and the performance gets worse since we first need to connect to the website, get its headers, and then also connect to the onion. Still _all_ the website approaches mentioned in the "Motivation" section suffer from the above drawbacks, and sysadmins still come up with ad-hoc ways to inform users abou their onions. So this simple proposal will still help those websites and also pave the way forward for future auto-redirect techniques. 4.3. Alt-Svc does not do exactly what we want I read in a blog post [*] that using Alt-Svc header "doesn’t change the URL in the location bar, document.location or any other indication of where the resource is; this is a “layer below” the URL.". IIUC, this is not exactly what we want because users will not notice the onion address, they will not get the user education part of the proposal and their connection will still be slowed down. I think we could perhaps change this in Tor Browser so that it rewrites the onion address to make it clear to people that they are now surfing the onionspace. [*]: https://www.mnot.net/blog/2016/03/09/alt-svc 5. The future As I said this is just a simple proposal to introduce the auto-redirect concept to people, and also to help some sysadmins who are currently coming up with weird ways to inform people about their onions. It's not the best way to do this, but it's definitely one of the simplest ways. In the future we could implement with more advanced auto-redirect proposals like: a) Have a "domains to onions" map into HTTPS-everywhere and have it do the autoredirects for us (performance benefits, and security benefits under many threat models). b) Bake onion addresses into SSL certificates and Let's Encrypt as suggested by comment:42 in #21952. But both of the designs above require non-trivial engineering/policy work and would still confuse people. So I think starting with a simple approach that will educate users and then moving to more advanced designs is a more normative way to go. ====================================================================== Let me know what you think :) (Should this be part of torspec?)

10 25

Domain Fronting, Meek, Cloudflare, and Encrypted SNI...
by Nathaniel Suchy 23 Oct '18

23 Oct '18

Hi everyone, Cloudflare has added support to TLS 1.3 for encrypted server name indication (SNI). This mailing list post is a high level overview of how meek could take advantage of this in relation to Cloudflare who until just now wasn’t an option for domain fronting. What this means: Effectively domain fronting works by sending a different SNI and host header. CDN providers like Cloudflare started double checking to make governments happy, scratch that line, I mean to protect their customers from fraud and abuse. They seem to of backtracked now. Encrypted SNI means that a firewall or coffee shop owner won’t be able to use SNI to see the real origin of TLS traffic. Why this matters: With the right adjustments for TLS 1.3 and Encrypted SNI support, Cloudflare may be a viable option for Meek. Risks: * Firewall products could always use DPI and block TLS 1.3 altogether. * Firewall products could block all requests with encrypted SNI. Thoughts anyone? References: * https://blog.cloudflare.com/encrypted-sni/ * https://blog.cloudflare.com/esni

4 10

Temporary hidden services
by Michael Rogers 22 Oct '18

22 Oct '18

Hi all, The Briar team is working on a way for users to add each other as contacts by exchanging links without having to meet in person. We don't want to include the address of the user's long-term Tor hidden service in the link, as we assume the link may be observed by an adversary, who would then be able to use the availability of the hidden service to tell whether the user was online at any future time. We're considering two solutions to this issue. The first is to use a temporary hidden service that's discarded after, say, 24 hours. The address of the temporary hidden service is included in the link. This limits the window during which the user's activity is exposed to an adversary who observes the link, but it also requires the contact to use the link before it expires. The second solution is to include an ECDH public key in the link, exchange links with the contact, and derive a hidden service key pair from the shared secret. The key pair is known to both the user and the contact. One of them publishes the hidden service, the other connects to it. They exchange long-term hidden service addresses via the temporary hidden service, which is then discarded. The advantage of the second solution is that the user's link is static - it doesn't expire and can be shared with any number of contacts. A different shared secret, and thus a different temporary hidden service, is used for adding each contact. But using a hidden service in such a way that the client connecting to the service knows the service's private key is clearly a departure from the normal way of doing things. So before pursuing this idea I wanted to check whether it's safe, in the sense that the hidden service still conceals its owner's identity from the client. Attacks against the availability of the service (such as uploading a different descriptor) are pointless in this scenario because the client is the only one who would connect to the service anyway. So I'm just interested in attacks against anonymity. Can anyone shed any light on this question? Or is this way of using hidden services too disgusting to even discuss? :-) Thanks, Michael

6 13

Information on Pluggable Transports
by Pritam Kadasi 15 Oct '18

15 Oct '18

Hi all, i'am currectly working on a project on tor. can you help me to get enough resources for Pluggable Transports. i would like to know more on how obfuscation happens in detail. thanking you. Pritam

4 4

[release] CollecTor 1.8.0
by Karsten Loesing 15 Oct '18

15 Oct '18

Hi, everyone! A new release is available: https://dist.torproject.org/collector/1.8.0/ From the change log: * Medium changes - Properly clean up sanitized web server logs in the recent/ directory when they turn older than three days. * Minor changes - Once more, fix the bug in the tarball-creation script where tarballs are not compressed in a run following an aborted run. - Improve logging to find possible issue with missing server descriptors. - Update directory authority IP addresses in default properties file. This CollecTor release is already deployed on all Tor Metrics CollecTor instances. Please direct comments and questions to the metrics-team mailing list: https://lists.torproject.org/cgi-bin/mailman/listinfo/metrics-team All the best, Karsten

1 0

Re: [tor-dev] Characterizing Tor flows using DPI
by Piyush Kumar Sharma 15 Oct '18

15 Oct '18

Hello all, I have some confusion regarding the characterization of Tor traffic using DPI. I was following the link ( https://trac.torproject.org/projects/tor/wiki/org/projects/Tor/TLSHistory ) and understood that Tor did TLS renogotiation at some point and then discontinued doing it. As an improvement there are basically two handshakes that are done. (i) "outer handshake" which is made to look as real as possible. (ii) "inner handshake" which is actually used to authenticate and exchange "real" certificates. I am just not able to understand as to why we need two handshakes, also why do we need "real" and "fake" certificates. Or if i am missing something, can someone point me to the right resources where i can get the current tor TLS implementation details. Regards Piyush PhD CSE IIITD

2 1

Idea which may or may not of been discussed
by Nathaniel Suchy 13 Oct '18

13 Oct '18

Currently tor traffic uses an TLS handshake hostname like the following: $ sudo tcpdump -An "tcp" | grep "www" listening on pktap, link-type PKTAP (Apple DLT_PKTAP), capture size 262144 bytes .............". ...www.odezz26nvv7jeqz1xghzs.com......................#.!...www.bxbko3qi7vacgwyk4ggulh.com..........6....m.....>...:.........|../* Z....W....X=..6...C../....................................0...0..0.......'....F./0.. *.H........0%1#0!..U....www.b6zazzahl3h3faf4x2.com0...160402000000Z..170317000000Z0'1%0#..U....www.tm3ddrghe22wgqna5u8g.net0..0.. A network observer could run a DNS lookup on the hostnames and see if they are real or not. So my idea would be to register a set of random hostnames which are legitimate and point the IPs somewhere to avoid looking for an NX Domain response and dropping the stream. You could even give each relay a unique subdomain and rotate these every few weeks. This may be expensive to implement but could make blocking Tor traffic with this method harder. Thoughts? Cordially, Nathaniel Suchy

3 2

Orbot 16.0.3-BETA-2 (tor-0.3.4.8) release for testing
by Nathan Freitas 12 Oct '18

12 Oct '18

Highlights - Tor 0.3.4.8 / OpenSSL 1.0.2p with dirauth module disabled (not used for client devices) - Updated Obfs4/Meek pluggable transport support and built-in bridges - Simplified (less memory, network & battery intensive) notification with "New Identity" button APKs up here: https://github.com/n8fr8/orbot/releases/tag/16.0.3-BETA-2 https://guardianproject.info/releases/Orbot-16.0.3-BETA-2-tor-0.3.4.8-fullp… (.asc) **** @n8fr8 n8fr8 released this just now Assets 6 Orbot-16.0.3-BETA-2-tor-0.3.4.8-fullperm-armeabi-release.apk 8.77 MB Orbot-16.0.3-BETA-2-tor-0.3.4.8-fullperm-armeabi-release.apk.asc 862 Bytes Orbot-16.0.3-BETA-2-tor-0.3.4.8-fullperm-universal-release.apk 17.8 MB Orbot-16.0.3-BETA-2-tor-0.3.4.8-fullperm-universal-release.apk.asc 862 Bytes Source code (zip) Source code (tar.gz) f06939b (HEAD -> master, tag: 16.0.3-BETA-2-tor-0.3.4.8, public/master, origin/master, origin/HEAD, dev/master) update build 16030020 9d3bd82 udpate default bridges c207a1e update new simpler notification with "new identity" button bcae003 add permission to service manifest a7130ab update to latest tor android 0.3.4.8 a5d1978 update default bridges ffda769 update NDK build script 3349454 update to latest Pluto obfs4proxy builds 048ed9f Merge branch 'master' of github.com:n8fr8/orbot 84e0433 (tag: 16.0.3-BETA-1-tor-0.3.4.8) update version to 16.0.3-BETA-1-tor-0.3.4.8 and build to 16030010 66cc8ad improve service checking for running Tor instance 6bc161b update to Tor 0.3.4.8 0ff8d7c Merge pull request #173 from haghighi-ahmad/patch-1 772e0db Improve Persian translation and fix grammar. 129b55a Merge branch 'master' of github.com:n8fr8/orbot 1bef963 Merge branch 'Unpublished-deprecated_torrc' b2bf3d9 Merge branch 'deprecated_torrc' of https://github.com/Unpublished/orbot into Unpublished-deprecated_torrc 06c343c update launcher web graphic 3433112 update launcher graphics bd61739 update version and constrains library 9a866aa update gradle tooling 31238af update tor to 0.3.4.7 RC

1 0

deb.tpo 0.3.5 repos intentionally empty?
by nusenu 08 Oct '18

08 Oct '18

Hi, the tor 0.3.5.x repos (example [1]) exist since some time but are empty since then, is that intentional? kind regards, nusenu [1] https://deb.torproject.org/torproject.org/dists/tor-experimental-0.3.5.x-st… -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu

2 2

Network team meeting postponed to Tuesday
by Nick Mathewson 07 Oct '18

07 Oct '18

Hi! A lot of people are off on Monday, so we'll try to have our weekly meeting on Tuesday Oct 9, at the regular time. best wishes, -- Nick

1 0

txtorcon 18.3.0
by meejah 05 Oct '18

05 Oct '18

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hot on the heels of 18.2.0 comes 18.3.0 because I forgot to add the "single_hop=" feature to endpoint-strings: * add `singleHop={true,false}` for endpoint-strings as well You can download the release from PyPI or GitHub (or of course "pip install txtorcon"): https://pypi.python.org/pypi/txtorcon/18.3.0 https://github.com/meejah/txtorcon/releases/tag/v18.3.0 Releases are also available from the hidden service: http://timaq4ygg2iegci7.onion/txtorcon-18.3.0.tar.gz http://timaq4ygg2iegci7.onion/txtorcon-18.3.0.tar.gz.asc Or via a "version 3" service: http://fjblvrw2jrxnhtg67qpbzi45r7ofojaoo3orzykesly2j3c2m3htapid.onion/txtor… http://fjblvrw2jrxnhtg67qpbzi45r7ofojaoo3orzykesly2j3c2m3htapid.onion/txtor… You can verify the sha256sum of both by running the following 4 lines in a shell wherever you have the files downloaded: cat <<EOF | sha256sum --check 5601956b3a2452526cd1ea31662696a51ddbf8ed6452633ee464fc1ff275f8b0 dist/txtorcon-18.3.0.tar.gz 8edac3b6d9c633b9182b4e5a2ed3ac86953ed44b9ea230aac3e0708c30b73861 dist/txtorcon-18.3.0-py2.py3-none-any.whl EOF thanks, meejah -----BEGIN PGP SIGNATURE----- iQFFBAEBCAAvFiEEnVor1WiOy4id680/wmAoAxKAaacFAlu37ycRHG1lZWphaEBt ZWVqYWguY2EACgkQwmAoAxKAaafaFAf/e4pVR7bL+gDMq2sJVaFVFzsQqPTV2RLi 9e5A7RRfCPfDSPMyJg71I5qnXXY7aXMP5kBOmK1WF7hN06NRrYGuVifWzijogosP l/2KIGp1I6nK77JTNdjPqnSfQ9N+/ZXaXK3ILzlmSiyI3PMaLgPjB0x2JM6NhcfQ pPPKuL9K0bw94slGSTJa29py4yBV4VhAG0qwHEigw3Zwie2iAejk1GwSW9UEhJnp GBDECiaBdgDZZozn43Q9WXoVIcTnsjTBIN9Km3gNgIcn+ZbwH461HKDXvW7yDfsV oZ7thGr5xD9ENErOzWgU52kMOOuo/pM50vAlzJC518iV39deCD1GQA== =6d14 -----END PGP SIGNATURE-----

1 0

txtorcon 18.2.0
by meejah 05 Oct '18

05 Oct '18

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I'm glad to announce txtorcon 18.2.0. This adds or fixes the following: * add `privateKeyFile=` option to endpoint parser (ticket 313) * use `privateKey=` option properly in endpoint parser * support `NonAnonymous` mode for `ADD_ONION` via `single_hop=` kwarg You can download the release from PyPI or GitHub (or of course "pip install txtorcon"): https://pypi.python.org/pypi/txtorcon/18.2.0 https://github.com/meejah/txtorcon/releases/tag/v18.2.0 Releases are also available from the hidden service: http://timaq4ygg2iegci7.onion/txtorcon-18.2.0.tar.gz http://timaq4ygg2iegci7.onion/txtorcon-18.2.0.tar.gz.asc Or via a "version 3" service: http://fjblvrw2jrxnhtg67qpbzi45r7ofojaoo3orzykesly2j3c2m3htapid.onion/txtor… http://fjblvrw2jrxnhtg67qpbzi45r7ofojaoo3orzykesly2j3c2m3htapid.onion/txtor… You can verify the sha256sum of both by running the following 4 lines in a shell wherever you have the files downloaded: cat <<EOF | sha256sum --check b1714dfa633cb4097c9ea649c8c49657d9d22a990cc465bb904620428c5e684e dist/txtorcon-18.2.0.tar.gz 9d05f2b1144dfbc63844e78fbc51a195e3b39a79f280db50a81b346476c47e7b dist/txtorcon-18.2.0-py2.py3-none-any.whl EOF thanks, meejah -----BEGIN PGP SIGNATURE----- iQFFBAEBCAAvFiEEnVor1WiOy4id680/wmAoAxKAaacFAlu2qS0RHG1lZWphaEBt ZWVqYWguY2EACgkQwmAoAxKAaafvxAgAxsqlJ7LcnX2SxU89NHXJZ/og9ZkcKF89 RCAdYm/G1R4cJpqX9wjd0Kt38NJJyt/SuT95wGtYInLjrrTs3lzg7ToLoRxIodaF rXdlnUKaNJBStpIW62oJ1WRq8AFsjtjnxFv9iuIyUCA7BMh/nkKwCMoEOqtQ/KbO V43DjZpTr9cQmn62c1b6H+x+TVXhyZxiTK0d7WTHrrKbMOIpSKIJTezZvOfDV7MC dQdmLlhE1qxW8X5UjlNeWApuGWtY6U9aSVJcglN6Ecp8bZcvvS9LSWxn+KHkbzFX uLOgTyfp9/mQsAeVosp9HQ7iB+6BD27blJlMIBFPNLoBaFNjX91H7A== =v2ac -----END PGP SIGNATURE-----

1 0

Information on the handling of relays churn
by Adrien Luxey 28 Sep '18

28 Sep '18

Dear Tor developers, As a PhD student in distributed systems, I am studying onion routing. We would like to investigate an onion routing system that would run on users devices, i.e. a lot of nodes with crappy bandwidth and intermittent connection. To compare against Tor, I have been looking for information about how you currently handle the disconnection of relays, but I found no "digest" on the Web. Your code seems to point to the direction of core/or/circuit*, that I need to investigate further. I still would love some first-hand high-level description from you guys. I have the following questions: * When an OR disconnects while supporting active circuits, how is the failure detected? * How are the paths subsequently rebuilt? * To which extent would you say that Tor is resilient to churn? What would be the effects of a massive churn of relays? Where would be the bottleneck? If you have any questions on my work, I will be pleased to answer (though a little ashamed, because I know our system will never hold your security properties so tight)! With much respect for your work and philosophy, Adrien Luxey

4 4

txtorcon 18.1.0
by meejah 27 Sep '18

27 Sep '18

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I'm very pleased to announce txtorcon 18.1.0. This adds or fixes the following: * better error-reporting (include REASON and REMOTE_REASON if available) when circuit-builds fail (thanks David Stainton) * more-robust detection of "do we have Python3" (thanks Balint Reczey) * fix parsing of Unix-sockets for SOCKS * better handling of concurrent Web agent requests before SOCKS ports are known * allow fowarding to ip:port pairs for Onion services when using the "list of 2-tuples" method of specifying the remote vs local connections. You can download the release from PyPI or GitHub (or of course "pip install txtorcon"): https://pypi.python.org/pypi/txtorcon/18.1.0 https://github.com/meejah/txtorcon/releases/tag/v18.1.0 Releases are also available from the hidden service: http://timaq4ygg2iegci7.onion/txtorcon-18.1.0.tar.gz http://timaq4ygg2iegci7.onion/txtorcon-18.1.0.tar.gz.asc Or via a "version 3" service: http://fjblvrw2jrxnhtg67qpbzi45r7ofojaoo3orzykesly2j3c2m3htapid.onion/txtor… http://fjblvrw2jrxnhtg67qpbzi45r7ofojaoo3orzykesly2j3c2m3htapid.onion/txtor… You can verify the sha256sum of both by running the following 4 lines in a shell wherever you have the files downloaded: cat <<EOF | sha256sum --check b61cf175a5f1d4092609caf05d178fcdcabf513928eec98d38125c501afea43c dist/txtorcon-18.1.0.tar.gz 98aba4a96c355c55ee5d8290b67a09380b02e1044fb2e76737f47f5a33659dce dist/txtorcon-18.1.0-py2.py3-none-any.whl EOF thanks, meejah -----BEGIN PGP SIGNATURE----- iQFFBAEBCAAvFiEEnVor1WiOy4id680/wmAoAxKAaacFAlusMDQRHG1lZWphaEBt ZWVqYWguY2EACgkQwmAoAxKAaadz3wgAk+UbYuw0lIwEqQZbhQ6oTk0cTu5GrB5q WkSbqPkj5Ph+y1iYMQoEgAZdD97zjpfGR+/JcyXbPyh4ZDcqkL8Hhay9yF2/PAkd agu1LBuBjVXOFvcw3D8Xi91miFwjmMKznAuR1Jv9gp66emw3qbZRZE9g1S9o1lCX 3Cx6o3kLiq8h7UmOiqFfCFGjNBFsaiDqf35P7FH7Btg4FYIGtI5/uQ3qgDtyqlhD YKA91KxZQoZFGiAhp5h84WXrvtuQ5tDjRNiIfh76xRFiFRnWe9ofELidKqEgnyzF shBqdGpaIT0g0NTQRhCnzBM7m3u0RHxkRblJWBLa6t4KYNFTMJ8Pag== =z+Lo -----END PGP SIGNATURE-----

1 0

[release] Tor Metrics Library 2.5.0 and Tor Metrics Website 1.2.0
by Karsten Loesing 26 Sep '18

26 Sep '18

Hi, we just released new versions of the Tor Metrics Library, metrics-lib 2.5.0, and Tor Metrics Website, metrics-web 1.2.0. The primary reason for these new releases is that libraries contained in the tarball match the ones needed to build current master. Downloads are available at: https://dist.torproject.org/metrics-lib/2.5.0/ https://dist.torproject.org/metrics-web/1.2.0/ Please direct comments and questions to the metrics-team mailing list: https://lists.torproject.org/cgi-bin/mailman/listinfo/metrics-team All the best, Karsten -- on behalf of the Metrics Team.

1 0

I
by john loughlin 24 Sep '18

24 Sep '18

Sent from my iPhone b

1 0

Memory usage on 0.3.4.8
by r1610091651 24 Sep '18

24 Sep '18

Hi devs After upgrade from 3.3.7 -> 3.4.8, I've noticed that memory usage is erratic. Please consult the image below, showing memory available in green and memory used in blue on a tor dedicate system. [image: image.png] The upgrade to 3.4.8 took place on Saturday in week 37. The connection count / load was relativity stable: [image: image.png] (green inbound, blue outbound) I was wondering if there were any changes from 3.3.7 to 3.4.8 which might impact memory behaviour on a middle-relay. I'm also wander what is the "source" of this usage? Potentially relevant config entries (remainder is port/ip, accounting & exit(no)): MaxConsensusAgeForDiffs 4 hours DirCache 0 MaxMemInQueues 64 MB (but "defaulting" to 256mb now) Thanks in advance Seb

2 1

Strong Flow Correlation Attacks on Tor Using Deep Learning
by procmem 21 Sep '18

21 Sep '18

Hi I wanted to bring your attention to this recent Tor attack paper published at the CCS conference: https://arxiv.org/pdf/1808.07285.pdf > We show that with moderate learning, DeepCorr can correlate Tor connections (and therefore break its anonymity) with accuracies significantly higher than existing algorithms, and using substantially shorter lengths of flow observations. For instance, by collecting only about 900 packets of each target Tor flow (roughly 900KB of Tor data), DeepCorr provides a flow correlation accuracy of 96% compared to 4% by the state-of-the-art system of RAPTOR using the same exact setting. > > We hope that our work demonstrates the escalating threat of flow correlation attacks on Tor given recent advances in learning algorithms, calling for the timely deployment of effective countermeasures by the Tor community. It has an extremely high true positive rate under real world conditions. The two main suggested countermeasures are padding and AS-aware path selection. I think you are working on the former but no practical implementation of the latter is ready?

1 0

Proposal 297: Relaxing the protover-based shutdown rules
by Nick Mathewson 21 Sep '18

21 Sep '18

Filename: 297-safer-protover-shutdowns.txt Title: Relaxing the protover-based shutdown rules Author: Nick Mathewson Created: 19-Sep-2018 Status: Open Target: 0.3.5.x 1. Introduction In proposal 264 (now implemented) we introduced the subprotocol versioning mechanism to better handle forward-compatibility in the Tor network. Included was a mechanism for safely disabling obsolete versions of Tor that no longer ran any supported protocols. If a version of Tor receives a consensus that lists as "required" any protocol version that it cannot speak, Tor will not start--even if the consensus is in its cache. The intended use case for this is that once some protocol has been provided by all supported versions for a long time, the authorities can mark it as "required". We had thought about the "adding a requirement" case mostly. This past weekend, though, we found an unwanted side-effect: it is hard to safely *un*-require a currently required protocol. Here's what happened: - Long ago, we created the LinkAuth=1 protocol, which required direct access to the ClientRandom and ServerRandom fields. (0.2.3.6-alpha) - Later, once we implemented Ed25519 identity keys, we added an improved LinkAuth=3 protocol, which uses the RFC5705 "key export" mechanism. (0.3.0.1-alpha) - When we added the subprotocols mechanism, we listed LinkAuth=1 as required. (backported to 0.2.9.x) - While porting Tor to NSS, we found that LinkAuth=1 couldn't be supported, because NSS wisely declines to expose the TLS fields it uses. So we removed "LinkAuth=1" from the required list (backported to 0.3.2.x), and got a bunch of authorities to upgrade. - In 0.3.5.1-alpha, once enough authorities had upgraded, we removed "LinkAuth=1" from the supported subprotocols list when Tor is running with NSS. [*] - We found, however, that this change could cause a bug when Tor+NSS started with a cached consensus that was created before LinkAuth=1 was removed from the requirements. Tor would decline to start, because the (old) consensus told it that LinkAuth=1 was required. This proposal discusses two alternatives for making it safe to remove required subprotocol versions in the future. [*] There was actually a bug here where OpenSSL removed LinkAuth=1 too, but that's mostly beside the point for this timeline, other than the fact it would have made things waaay worse if people hadn't caught it. 2. Recommended change: consider the consensus date. I propose that when deciding whether to shut down because of subprotocol requirements, a Tor implementation should only shut down if the consensus is dated to some time after the implementation's release date. With this change, an old cached consensus cannot cause the implementation to shut down, but a newer one can. This makes it safe to put out a release that does not support a formerly required protocol, so long as the authorities have upgraded to stop requiring that protocol. (It is safe to use the *scheduled* release date for the implementation, plus a few months -- just so long as we don't plan to start requiring a subprotocol that's not supported by the latest version of Tor.) 3. Not-recommended change: ignore the cached consensus. Was it a mistake to have Tor consider a cached consensus when deciding whether to shut down? The rationale for considering the cached consensus was that when a Tor implementation is obsolete, we don't want it hammering on the network, probing for new consensuses, and possibly reconnecting aggressively as its handshakes fail. That still seems compelling to me, though it's possible that if we find some problem with the methodology from section 2 above, we'll need to find some other way to achieve this goal.

5 6