April 2018 - tor-dev - lists.torproject.org

Lets give every circuit its own exit IP?
by nusenu 18 Mar '20

18 Mar '20

The unbearable situation with Google's reCAPTCHA motivated this email (but it is not limited to this specific case). This idea came up when seeing a similar functionality in unbound (which has it for a different reason). Assumption: There are systems that block some tor exit IP addresses (most likely the bigger once), but they are not blocked due to the fact that they are tor exits. It just occurred that the IP got flagged because of "automated / malicious" requests and IP reputation systems. What if every circuit had its "own" IP address at the exit relay to avoid causing collateral damage to all users of the exit if one was bad? (until the exit runs out of IPs and starts to recycle previously used IPs again) The goal is to avoid accumulating a bad "reputation" for the single used exit IP address that affects all tor users of that exit. Instead of doing it on the circuit level you could do it based on time. Change the exit IP every 5 minutes (but do _not_ change the exit IPs for _existing_ circuits even if they live longer than 5 minutes). Yes, no one has that many IPv4 addresses but with the increasing availability of IPv6 at exits and destinations, this could be feasible to a certain extend, depending on how many IPv6 addresses the exit operator has. There are exit operators that have entire /48 IPv6 blocks. problems: - will not solve anything since reputation will shift to netblocks as well (How big of a netblock are you willing to block?) - you can tell two tor users easily apart from each other even if they use the same exit (or more generally: you can tell circuits apart). There might be all kinds of bad implications that I'm not thinking off right now. - check.tpo would no longer be feasible - how can do we still provide the list of exit IPs for easy blocking? Exits could signal their used netblock via their descriptor. What if they don't? (that in turn opens new kinds of attacks where an exit claims to be /0 and the target effectively blocks everything) - more state to track and store at the exit -... some random thoughts, nusenu -- https://mastodon.social/@nusenu twitter: @nusenu_

4 6

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

Proposal: Expose raw bwauth votes
by Tom Ritter 17 Jul '18

17 Jul '18

I'm not sure, but I think https://trac.torproject.org/projects/tor/ticket/21377 needed a proposal so I tried to write one up. -tom

5 8

HS v3 client authorization types
by Suphanat Chunhapanya 12 Jul '18

12 Jul '18

As I am currently implementing the client authorization for onion service v3 (https://github.com/torproject/tor/pull/36) I found some problems in how we should let the users configure the client auth for their services. Before getting into the problem, I will explain how it works first. -- Each client will have two private keys to authenticate with the service. One is x25519 key and the other is ed25519 key. The x25519 one is used to decrypt the descriptor when the client wants to access the service, so if the client is not authorized, it will never know the introduction points, the intro auth keys, and so on, and then it absolutely cannot access the service. The ed25519 one is for another layer of authentication. Even if the client can decrypt the descriptor using the x25519 private key, it still need to have the ed25519 to authenticate itself directly to the service using the extension field in INTRODUCE1 cell. At first glance, it seems that the ed25519 one is not necessary because, if the client is able to decrypt the descriptor, it already means the client is already authenticated. Why do we need to have another layer of authenticate? The answer is that the ed25519 provides more find-grained access control for example: 1) you could use it to revoke a client without the need to rotate all the intro points and push new descriptor. 2) you can have more fine-grained control on your users and potentially offer different types of access structure to different users using their ed25519 keys as identifier. -- The spec says that the client must have both keys and use both to authenticate, but, for me, these two things are quite independent. I think they can be considered two different authentication types. The service should be able to enable one and disable the other. For example, If I disable the x25519 while I enable ed25519, I can add a new client immediately without the need to rotate the intro points. If rotating intro points is not an issue and the only purpose of ed25519 is to have more fine-grained access control, the current spec is fine. But if rotating intro points is an issue, we should rethink about this. So, I created a PR for the change in torspec. https://github.com/torproject/torspec/pull/7 (in the PR, the x25519 auth is called 'basic' and the ed25519 auth is called 'intro') We need your opinions about this. Should we let the service enable one while disable the other? Or should we require the service to enable both for all clients? If you want to let the service be able to enable one while disable the other, do you have any opinion on how to configure the torrc? Cheers, haxxpop This is a discussion log that we had earlier. [22:39:23] <meejah> v3 "basic" auth is different from v2 "basic" auth, right? Perhaps a different name-string for the v3 one would be good? [22:39:44] <asn> meejah: good point [22:39:57] <asn> perhaps we can name it "pubkey" auth or something more UX-y [22:40:35] <meejah> asn: sounds good to me (my perspective is to avoid naming-weirdness for controllers and having to explain to users "well, this 'basic' is different from this other 'basic' because you said version=3") [22:40:43] <asn> right [22:40:44] <asn> makse sense [22:40:51] <asn> haxxpop: ^ what do u think [22:40:51] <asn> ? [22:45:01] <haxxpop> meejah, asn yes I agreed. maybe we should change it to something else [22:46:10] <haxxpop> meejah, asn In fact, the word 'basic' appears only once in the v3 spec ! [22:48:05] <asn> haxxpop: yeah... perhaps we can rename it to "pubkey" which describes it pretty well for nerds. or to "standard" which is a synonym for "basic" and it will confuse everyone. [22:50:59] <haxxpop> asn, I think both "basic" and "intro" use pubkeys. [22:51:26] <haxxpop> asn, I think if we call "basic" "pubkey", it may imply that "intro" doesn't use pubkeys. [22:51:35] <asn> true [22:52:20] <asn> i'm still not sure if i like: [22:52:20] <asn> + HiddenServiceAuthorizeClient basic client-name,client-name,... [22:52:20] <asn> + HiddenServiceAuthorizeClient intro client-name,client-name,... [22:52:30] <asn> mainly because it's gonna be quite hard to explain to people what these two lines mean [22:52:34] <asn> (to hs operators) [22:52:37] <asn> like what's the difference [22:52:42] <asn> and usually they should have both enabled [22:52:53] <asn> what i imagined initially is that we would keep the torrc logic the same [22:53:04] <asn> and maybe expose a torrc option for advanced users to do HiddenServiceDisableIntroAuth [22:53:07] <asn> or something [22:53:11] <asn> anyway i need to think about this! [22:53:25] <haxxpop> asn, Nice point [23:08:35] <meejah> asn: haxxpop: "pubkey" sounds good to me. People who are "just clients" probably don't care what the string is (? maybe? UX people?) and people running the services probably count as "nerds" :) [23:08:59] <asn> agreed [23:09:02] <meejah> (but, I don't personally understand what these schemes are so maybe I shouldn't be naming them ;) [23:09:08] <asn> ideally those things should not be exposed to the users anyway [23:09:19] <asn> they should be wrapped by the browser or something [23:11:46] <meejah> asn: in txtorcon at least, they aren't really; preferred new-API is "async with tor.onion_authentication(onion_host, some_auth_object)" for py3, or "tor.add_onion_authentication(..)" -- ideally this can be used by "actual application" to transmit the credentials to users in some way [23:11:52] <meejah> (e.g. maybe via magic-wormhole) [23:12:35] <meejah> I assume that *ideally* the clients generate keypairs, and send pubkeys to the service..? [23:22:45] <asn> meejah: yes ideally clients generate keypairs [23:23:00] <asn> meejah: but service-generated keypairs can also be done, to immitate current symmetric-key design [23:26:08] <dmr> asn: there's lots of reasons to keep v2 "basic" separate from v3 "basic" - limited bug reports, presentations, error/log messages, internet searches, ... [23:26:34] <dmr> like meejah I also don't know what the schemes are, so that's the extent of my input :) [23:26:51] <dmr> glad to hear it sounds like we're all in agreement to use something other than "basic" for v3 [23:46:12] <meejah> asn: okay, ack. It would be neat to see an application using magic-wormhole for an "invite a new client" flow; perhaps I'll try a PoC when v3-auth is available; is it in master already??

6 16

minor website update request: have the tor-relay guide ready for Ubuntu 18.04
by nusenu 29 Jun '18

29 Jun '18

Hi, I wanted to have the tor relay guide ready for the new Ubuntu LTS version 18.04 nearly at the same time when it is released. Thanks to the torproject debian maintainer we already have packages for bionic. Basically the only thing that is missing is the website update to include the new distro for the sources.list generator. For that I submitted an update on trac [1] a few days ago. From my personal experience, my website update requests (also trivial ones) take about two months to get committed, it would be great if we could speed things up for this specific request to have the relay guide ready for the new Ubuntu LTS nearly at the same time when the release is happening. (I won't be bothering you with non-tor-relay-guide related website updates anymore). thanks, nusenu [1] https://trac.torproject.org/projects/tor/ticket/25888 -- https://mastodon.social/@nusenu twitter: @nusenu_

3 4

BandwidthRate minimal values (was: Re: [tor-relays] Report on the FOSDEM relays meetup)
by nusenu 13 May '18

13 May '18

(from tor-relays) >> Content-wise, there were some pretty fruitful discussion, but we spent quite a bit >> of time on questions that recurr at other meetups too: >> >> - What's the most useful thing I can bring to the network? >> (TL;DR: Ideally, fast relays (if possible exits); if you can't contribute >> more than 1MB/s, make it a bridge) > > I like 1MByte/s (8MBit/s) as the "limit" between relay vs. bridge, currently we mention > 16MBit/s and 2MBit/s in the documentation: > > https://www.torproject.org/docs/faq.html.en#HowDoIDecide > https://trac.torproject.org/projects/tor/wiki/TorRelayGuide#RelayRequiremen… > > I'll go ahead and make 8 MBit/s the lower limit (and keep "It is recommended that a relay have at least 16 MBit/s (Mbps)") > unless there are strong opinions against it. Hi, to have all places consistent, are you open to increase the minimal values in the tor man page for relays to 8 MBit/s (and bridges to 1 MBit/s) or other greater than the current values? currently it says: BandwidthRate N [...] If you want to run a relay in the public network, this needs to be at the very least 75 KBytes for a relay (that is, 600 kbits) or 50 KBytes for a bridge (400 kbits) but of course, more is better; we recommend at least 250 KBytes (2 mbits) if possible. If you are open to it I'll submit a patch via trac. -- https://mastodon.social/@nusenu twitter: @nusenu_

1 1

Proposal #291 (two guards) IRC meeting Wed Apr 18, 17:00 UTC
by Mike Perry 09 May '18

09 May '18

Heyo. We're going to have a meeting to discuss Proposal 291. See this thread: https://lists.torproject.org/pipermail/tor-dev/2018-April/013053.html The meeting will be at 17:00 UTC, on Wednesday, April 18th, in #tor-meeting on irc.oftc.net. (That's 10:00 left coast, 12:00 middle coast, 13:00 right coast, and 19:00 in several socialist paradises that strangely do not have public water fountains.) https://www.timeanddate.com/worldclock/fixedtime.html?iso=20180415T1700 Things we need to decide: 1. Do we abandon Tor's path restrictions? 2. Do we use two guards? At the end of this meeting, we should commit to one or both of these things long-term. (Surprise twist: we're already doing #2!) Each of these choices is a nuanced thing. And just picking one or the other doesn't solve everything. I think it's best to think of them as a commitment to a plan over some timescale, based on the information we have available today. People who mos def should attend: George Kadianakis, Roger, Nick, Me People who probably maybe should attend: Aaron Johnson, Isis (and others concerned about guard fingerprinting), You? -- Mike Perry

3 11

Re: [tor-dev] Proposal: Tor bandwidth measurements document format
by juga 07 May '18

07 May '18

Hi, after teor's revision, second version pasted below. Changes can be seen: in https://github.com/juga0/torspec/commits/bandwidth-file-spec Best, juga ================================================================= Tor Bandwidth Measurements Document Format juga teor 1. Scope and preliminaries This document describes the format of Tor's bandwidth measurements document, version 1.0.0 and later. Since Tor version 0.2.4.12-alpha the directory authorities use the bandwidth measurements document called "V3BandwidthsFile" and produced by Torflow [1] (format described in README.spec.txt [2]). The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. 1.2. Acknowledgements The original bandwidth measurement scanner (Torflow) and format was created by mike. Teor suggested to write this specification while contributing on pastly's new bandwidth scanner implementation. This specification was revised after feedback from: XXX 1.3 Outline The bandwidth measurements mentioned in sections 3.4.1 and 3.4.2 of "Tor directory protocol" (dir-spec.txt) [3] are obtained by bandwidth authorities, which generate a file storing information on relays' measured bandwidth capacities. 1.4. Format Versions 1.0.0 - The legacy fallback bandwidth measurements document format 1.1.0 - Adds key_value lines to the header, format version, optional ones and section separator. 2. Format details Bandwidth measurements MUST contain the following sections: - Header (exactly once) - Relays measurements (zero or more times) 2.1. Definitions The following nonterminals are defined in dir-spec.txt, sections 1.2., 2.1.1., 2.1.3.: Int SP (space) NL (newline) Keyword ArgumentChar fingerprint (hexdigest) nickname Nonterminals defined in "Tor Directory List Format" (dir-list-spec.txt), section 2.2.1.: version_number We define the following nonterminals: value ::= ArgumentChar+ key_value ::= Keyword "=" value line ::= ArgumentChar* NL timestamp ::= Int bandwidth ::= Int relay_line ::= key_value (SP key_value)* NL 2.2. Header format Some header lines MUST appear in specific positions, as documented below. All other lines can appear in any order. There MUST NOT be multiple key_value header lines with the same key. It consists of: timestamp NL [At start, exactly once.] The Unix Epoch time in seconds when the file was created. "version=" version_number NL [In second position, zero or one time.] The specification document format version. It uses semantic versioning [5]. This line has been added in version 1.1.0 of this specification. Version 1.0.0 documents do not contain this line, and the version_number is considered to be "1.0.0". "software=" value NL [Zero or one time.] The name of the software that created the document. This line has been added in version 1.1.0 of this specification. Version 1.0.0 documents do not contain this line, and the software is considered to be "torflow". "software_version=" value NL [Zero or one time.] The version of the software that created the document. The version may be a version_number, a git commit, or some other version scheme. This line has been added in version 1.1.0 of this specification. "scanner_started=" timestamp NL [Zero or one time.] The Unix Epoch time in seconds when the scanner that generates the measurements document started. This line has been added in version 1.1.0 of this specification. "earliest_measurement=" timestamp NL [Zero or one time.] The Unix Epoch time in seconds when the first relay measurement was obtained. This line has been added in version 1.1.0 of this specification. key_value NL [Zero or more times.] Future format versions may include additional key_value header lines. Additional header lines will be accompanied by a minor version increment. Implementations MAY add additional header lines as needed. This specification SHOULD be updated to avoid conflicting meanings for the same header keys. Parsers MUST NOT rely on the order of these additional lines. Additional header lines MUST NOT use any keywords specified in the relay measurements format. If a header line does not conform to this format, the line SHOULD be ignored by parsers. NL [Zero or one time.] The header ends. This line has been added in version 1.1.0 of this specification. For version 1.0.0 documents, the header ends when the first relay measurement line is found conforming to the next section. 2.3. Relay measurements format It consists of zero or more relay_line with the measurement results of relays in arbitrary order. There can be at most one relay_line per relay identity (fingerprint). There MUST NOT be multiple key_value pairs with the same key in the same relay_line. Each relay_line MUST include the following key_value in arbitrary order: "node_id=" fingerprint [Exactly once.] The fingerprint of the relay being measured. "bw=" bandwidth [Exactly once.] The measured bandwidth of this relay. Tor accepts zero bandwidths, but they trigger bugs in older Tor implementations. Therefore, implementations SHOULD NOT produce zero bandwidths. Instead, they SHOULD use one as their minimum bandwidth. Multiple measurements can be aggregated using an averaging scheme, such as a mean, median, or decaying average. Torflow scales bandwidths to kilobytes per second. Other implementations SHOULD use kilobytes per second for their initial bandwidth scaling. If different implementations or configurations are used in votes for the same network, their measurements MAY need further scaling. See Appendix B for information about scaling, and one possible scaling method. key_value [Zero or more times.] Future format versions may include additional key_value pairs on a relay_line. Additional key_value pairs will be accompanied by a minor version increment. Implementations MAY add additional relay key_value pairs as needed. This specification SHOULD be updated to avoid conflicting meanings for the same relay keys. Parsers MUST NOT rely on the order of these additional key_value pairs. Additional key_value pairs MUST NOT use any keywords specified in the header format. If a relay line does not conform to this format, the line SHOULD be ignored by parsers. 2.4. Implementation notes 2.4.1. Simple Bandwidth Scanner Every relay measurement in sbws version 0.1.0 consists of: "node_id=" fingerprint SP As above. "bw=" bandwidth SP As above. "nick=" nickname SP [Exactly once.] The relay nickname. "rtt=" Int SP [Exactly once.] The Round Trip Time in milliseconds to obtain 1 byte of data. "time=" timestamp NL [Exactly once.] The Unix Epoch time in seconds when the last measurement was performed. 2.4.2. Torflow Torflow relay lines include node_id and bw, and other key_value pairs [2]. References: 1. https://gitweb.torproject.org/torflow.git 2. https://gitweb.torproject.org/torflow.git/tree/NetworkScanners/BwAuthority/… 3. https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt 4. https://metrics.torproject.org/onionoo.html#details 5. https://semver.org/ A. Sample data The following has not been obtained from any real measurement. A.1. Generated by Torflow This an example version 1.0.0 document: 1523911758 node_id=$68A483E05A2ABDCA6DA5A3EF8DB5177638A27F80 bw=760 nick=Test measured_at=1523911725 updated_at=1523911725 pid_error=4.11374090719 pid_error_sum=4.11374090719 pid_bw=57136645 pid_delta=2.12168374577 circ_fail=0.2 scanner=/filepath node_id=$96C15995F30895689291F455587BD94CA427B6FC bw=189 nick=Test2 measured_at=1523911623 updated_at=1523911623 pid_error=3.96703337994 pid_error_sum=3.96703337994 pid_bw=47422125 pid_delta=2.65469736988 circ_fail=0.0 scanner=/filepath A.2. Generated by sbws version 0.1.0 1523911758 version=1.1.0 software=sbws software_version=0.1.0 scanner_started=1523911756 earliest_measurement=1523911757 node_id=$68A483E05A2ABDCA6DA5A3EF8DB5177638A27F80 bw=760 nick=Test rtt=380 time=1523911725 node_id=$96C15995F30895689291F455587BD94CA427B6FC bw=189 nick=Test2 rtt=378 time=1523911623 B. Scaling bandwidths B.1. Scaling requirements Tor accepts zero bandwidths, but they trigger bugs in older Tor implementations. Therefore, scaling methods SHOULD perform the following checks: * If the total bandwidth is zero, all relays should be given equal bandwidths. * If the scaled bandwidth is zero, it should be rounded up to one. Initial experiments indicate that scaling may not be needed for torflow and sbws, because their measured bandwidths are similar enough already. B.2. A linear scaling method If scaling is required, here is a simple linear bandwith scaling method, which ensures that all bandwidth votes contain approximately the same total bandwidth: 1. Calculate the relay quota by dividing the total measured bandwidth in all votes, by the number of relays with measured bandwidth votes. In the public tor network, this is approximately 7500 as of April 2018. The quota should be a consensus parameter, so it can be adjusted for all scanners on the network. 2. Calculate a vote quota by multiplying the relay quota by the number of relays this bandwidth authority has measured bandwidths for. 3. Calculate a scaling factor by dividing the vote quota by the total unscaled measured bandwidth in this bandwidth authority's upcoming vote. 4. Multiply each unscaled measured bandwidth by the scaling factor. Now, the total scaled bandwidth in the upcoming vote is approximately equal to the quota. B.3. Quota changes If all scanners are using scaling, the quota can be gradually reduced or increased as needed. Smaller quotas decrease the size of uncompressed consensuses, and may decrease the size of consensus diffs and compressed consensuses. But if the relay quota is too small, some relays may be over- or under-weighted.

5 15

connectivity failure for top 100 relays
by dawuud 03 May '18

03 May '18

Out of 9900 possible two hop tor circuits among the top 100 tor relays only 935 circuit builds have succeeded. This is way worse than the last time I sent a report 6 months ago during the Montreal tor dev meeting. Here's the scanner I use: https://github.com/david415/tor_partition_scanner (I was planning on improving this testing methodology in collaboration with Katharina Kohls but was unable to travel to Bochum University because of visa limitations. It was either go to tor-dev meeting or Bochum but not both.) Here's the gist of my simple testing methodology: https://gist.github.com/david415/9875821652018431dd6d6c4407bb90c0#file-dete… Here's exactly how I performed the scan to get those results: wget https://collector.torproject.org/recent/relay-descriptors/consensuses/2018-… ./helpers/query_fingerprints_from_consensus_file.py 2018-03-1 3-01-00-00-consensus > top100.relays detect_partitions.py --tor-control tcp:127.0.0.1:9051 --log-dir ./ --status-log ./status_log \ --relay-list top100.relays --secret secretTorEmpireOfRelays --partitions 1 --this-partition 0 \ --build-duration .25 --circuit-timeout 60 --log-chunk-size 1000 --max-concurrency 100 echo "select first_hop, second_hop from scan_log where status = 'failure';" | sqlite3 scan1.db | wc -l 8942 echo "select first_hop, second_hop from scan_log where status = 'timeout';" | sqlite3 scan1.db | wc -l 23 echo "select first_hop, second_hop from scan_log where status = 'success';" | sqlite3 scan1.db | wc -l 935

5 14

onion v2 deprecation plan?
by nusenu 30 Apr '18

30 Apr '18

Hi, even though you are probably years away from deprecating onion v2 services it is certainly good to have a clear plan. I'm asking because the sooner onion v2 are deprecated the sooner some people can stop worrying about malicious HSDirs. thanks, nusenu -- https://mastodon.social/@nusenu twitter: @nusenu_

8 18