- tor-dev - lists.torproject.org

Re: [tor-dev] The Onion Name System (OnioNS)
by teor 02 Jun '15

02 Jun '15

> Date: Mon, 18 May 2015 15:48:50 -0800 > From: OnioNS Dev <kernelcorn(a)riseup.net> > > ... > > I introduce several data structures, but the most important one is the Pagechain, a distributed structure of linked Pages. Pages contain Records, Records contain .tor -> onion associations. Anyone who is familiar with blockchains will recognize the behavior and application of this structure immediately. However, here the head of the Pagechain is not managed by miners, but rather by a short-lived subset of Tor nodes called a Quorum. They receive Records and merge them into the Pagechain. At the moment I've decided to use 127 Quorum members and rotate them every week. They are randomly selected, but the process is deterministic; I am using the cached-certs + cached-microdesc-consensus documents, which everyone has, to seed a PRNG that then derives the Quorum. What's to stop a sybil attack where the malicious relays try to occupy likely site(s) for the next Quorum? Is the consensus unpredictable enough to thwart this attack? Even during quiet times? (Does Tor have quiet times?) Can we ensure the Quorum servers have to be long-lived and high-capacity (for example, guards) to make it harder to spin up servers and immediately be added to the Quorum? I'm not convinced the Stable flag is hard enough to get. Of course, there's a trade-off where making the set of Quorum Candidates too small makes the Quorum easier to predict, too. By the way, in your ACM paper 5.4.2 you switch from Charlie to Alice, but I think they're meant to be the same Quorum Candidate. > Clients don't need a copy of the Pagechain to use the DNS, but rather they can just rely on their existing trust of the Tor network (including the Quorum and name servers) and verify their signatures on data structures. > Also unlike a blockchain, my Pagechain has a finite length: the oldest Page will eventually drop off, which forces domains to be renewed periodically. I have also introduced mechanisms that 1) allows clients to authenticate the domain name to the hidden service, 2) allow clients to authenticate a denial-of-existence claim from a name server, and 3) prevent name servers from forging .tor -> .onion associations. These vulnerabilities are still generally open on the Internet DNS. I have also tried to minimize networking costs, since Tor circuits are slow. > > To reduce CPU and network requirements, I want Tor routers to have Ed25519 keys. Let this project add additional pressure on that item on the to-do list. > > Recommended readings: > http://onions55e7yam27n.onion -- the official hidden service for this project, but a work in progress. > https://github.com/Jesse-V/Thesis/blob/master/conference/acm-ccs.pdf -- the ACM paper pending peer review > I no longer recommending reading my original thesis, please use the above links instead. > The HS is down, and has been for some days. For those having trouble accessing the paper through the direct link, try clicking on acm-ccs.pdf on: https://github.com/Jesse-V/Thesis/tree/master/conference I got a format error from GitHub when I tried the direct link in Tor Browser 4.5. > … > > I am asking for help with the client-side functionality. I'm currently doing the *.tor interception and lookup resume in connection_edge.c but the software frequently crashes with this approach, (I've learned why) and I'd like to migrate it to Stem for now. I need to intercept .tor domains, pause the lookup (letting the Tor Browser spin), send the hostname over a named pipe or TCP socket, read back a .onion address, then tell Tor to resume the lookup under the .onion address. This way, the HS loads under a .tor domain. I have two questions about the Stem-based approach: 1. Applications which use Tor via SOCKS won't be able to use .tor domains without using Stem. This adds another dependency to apps which want to use .tor addresses, and confuses users by making .tor addresses work with some torified apps, and not others. Is your final goal to have .tor lookups contained within the Tor client? I'm sure someone could help with the C coding if that's the issue, particularly given a working implementation in Python/Stem. 2. I always feel nervous when people say "letting app X spin". I assume Tor Browser just looks like it's doing a DNS lookup or similar? teor teor2345 at gmail dot com pgp 0xABFED1AC https://gist.github.com/teor2345/d033b8ce0a99adbc89c5 teor at blah dot im OTR D5BE4EC2 255D7585 F3874930 DB130265 7C9EBBC7

1 1

Proposal 245: Deprecating and removing the TAP circuit extension protocol
by Nick Mathewson 02 Jun '15

02 Jun '15

Filename: 245-tap-out.txt Title: Deprecating and removing the TAP circuit extension protocol Author: Nick Mathewson Created: 2015-06-02 Status: Draft 0. Introduction This proposal describes a series of steps necessary for deprecating TAP without breaking functionality. TAP is the original protocol for one-way authenticated key negotiation used by Tor. Before Tor version 0.2.4, it was the only supported protocol. Its key length is unpleasantly short, however, and it had some design warts. Moreover, it had no name, until Ian Goldberg wrote a paper about the design warts. Why deprecate and remove it? Because ntor is better in basically every way. It's actually got a proper security proof, the key strength seems to be 20th-century secure, and so on. Meanwhile, TAP is lingering as a zombie, taking up space in descriptors and microdescriptors. 1. TAP is still in (limited) use today for hidden service hops. The original hidden service protocol only describes a way to tell clients and servers about an introduction point's or a rendezvous point's TAP onion key. We can do a bit better (see section 4), but we can't break TAP completely until current clients and hidden services are obsolete. 2. The step-by-step process. Step 1. Adjust the parsing algorithm for descriptors and microdescriptors on servers so that it accepts MDs without a TAP key. See section 3 below. Target: 0.2.7. Step 1b. Optionally, when connecting to a known IP/RP, extend by ntor. (See section 4 below.) Step 2. Wait until proposal 224 is implemented. (Clients and hidden services implementing 224 won't need TAP for anything.) Step 3. Begin throttling TAP answers even more aggressively at relays. Target: prop224 is stable. Step 4. Wait until all versions of Tor without prop224 support are obsolete/deprecated. Step 5. Stop generating TAP keys; stop answering TAP requests; stop advertising TAP keys in descriptors; stop including them in microdescriptors. Target: prop224 has been stable for 12-18 months, and 0.2.7 has been stable for 2-3 years. 3. Accepting descriptors without TAP keys. (Step 1) Our microdescriptor parsing code uses the string "onion-key" at the start of the line to identify the boundary between microdescriptors, so we can't remove it entirely. Instead, we will make the body optional. We will make the following changes to dir-spec: - In router descriptors, make the onion-key field "at most once" instead of "exactly once." - In microdescriptors, make the body of "onion-key" optional. Until Step 4, authorities MUST still reject any descriptor without a TAP key. If we do step 1 before proposal 224 is implemented, we'll need to make sure that we never choose a relay without a TAP key as an introduction point or a rendezvous point. 4. Avoiding TAP earlier for HS usage (Step 1b) We could begin to move more circuits off TAP now by adjusting our behavior for extending circuits to Introduction Points and Rendezvous Points. The new rule would be: If you've been told to extend to an IP/RP, and you know a directory entry for that relay (matching by identity), you extend using the node_t you have instead. This would improve cryptographic security a bit, at the expense of making it possible to probe for whether a given hidden service has an up-to-date consensus or not, and learn whether each client has an up-to-date consensus or not. We need to figure out whether that enables an attack. (For reference, the functions to patch would be rend_client_get_random_intro_impl and find_rp_for_intro.)

1 0

Re: [tor-dev] Quick logjam/Tor analysis.
by teor 02 Jun '15

02 Jun '15

> Date: Tue, 26 May 2015 09:25:22 -0400 > From: Nick Mathewson <nickm(a)torproject.org> > > I posted this on a blog comment, but others may be interested too. > > > As near as I can tell, the "logjam"/"weakdh" attacks should not affect > current Tor software very much, for a few reasons: > > * All currently supported Tor versions, when built with OpenSSL 1.0 or > later, prefer 256-bit elliptic-curve Diffie Hellman for their TLS > connections, not the 1024-bit Diffie Hellman over Z_p as discussed in > this paper. > > … > > Recommendations: > > … > > * If you're running OpenSSL 0.9.8 or earlier, you should consider upgrading > to 1.0.0 or later. (Mac) OS X Yosemite 10.10 and earlier ship with OpenSSL 0.9.8 and 0.9.7. For Yosemite 10.10.3 (14D136) in particular, these are: $ ls -l /usr/lib/libssl.* -rwxr-xr-x 1 root wheel 400608 10 Sep 2014 /usr/lib/libssl.0.9.7.dylib -rwxr-xr-x 1 root wheel 616512 20 Mar 13:16 /usr/lib/libssl.0.9.8.dylib lrwxr-xr-x 1 root wheel 18 28 Jan 23:16 /usr/lib/libssl.dylib -> libssl.0.9.8.dylib $ strings /usr/lib/libssl.0.9.8.dylib | grep "OpenSSL 0.9.8" OpenSSL 0.9.8zd 8 Jan 2015 … $ strings /usr/lib/libssl.0.9.7.dylib | grep "OpenSSL 0.9.7" … OpenSSL 0.9.7l 28 Sep 2006 … (As an aside, please avoid running strings on any untrusted binaries.) While it's possible to build or install OpenSSL 1.0 or 1.1 on OS X, it's not the default. How does this affect Tor and/or Tor Browser on OS X? teor teor2345 at gmail dot com pgp 0xABFED1AC https://gist.github.com/teor2345/d033b8ce0a99adbc89c5 teor at blah dot im OTR D5BE4EC2 255D7585 F3874930 DB130265 7C9EBBC7

2 1

Did GuardFraction stuff break bandwidth weights?
by Karsten Loesing 01 Jun '15

01 Jun '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi asn, hi weasel, could it be that the recently added GuardFraction stuff broke something that led to removing the "bandwidth-weights" line? All the best, Karsten $ grep -c bandwidth-weights 2015-05-31-* 2015-05-31-00-00-00-consensus:1 2015-05-31-01-00-00-consensus:1 2015-05-31-02-00-00-consensus:1 2015-05-31-03-00-00-consensus:1 2015-05-31-04-00-00-consensus:1 2015-05-31-05-00-00-consensus:1 2015-05-31-06-00-00-consensus:1 2015-05-31-07-00-00-consensus:1 2015-05-31-08-00-00-consensus:1 2015-05-31-09-00-00-consensus:1 2015-05-31-10-00-00-consensus:1 2015-05-31-11-00-00-consensus:1 2015-05-31-12-00-00-consensus:1 2015-05-31-13-00-00-consensus:0 2015-05-31-14-00-00-consensus:0 2015-05-31-15-00-00-consensus:0 2015-05-31-16-00-00-consensus:0 2015-05-31-17-00-00-consensus:0 2015-05-31-18-00-00-consensus:0 2015-05-31-19-00-00-consensus:0 2015-05-31-20-00-00-consensus:0 2015-05-31-21-00-00-consensus:0 2015-05-31-22-00-00-consensus:0 2015-05-31-23-00-00-consensus:0 $ grep -c GuardFraction 2015-05-31-* 2015-05-31-00-00-00-consensus:0 2015-05-31-01-00-00-consensus:0 2015-05-31-02-00-00-consensus:0 2015-05-31-03-00-00-consensus:0 2015-05-31-04-00-00-consensus:0 2015-05-31-05-00-00-consensus:0 2015-05-31-06-00-00-consensus:0 2015-05-31-07-00-00-consensus:0 2015-05-31-08-00-00-consensus:0 2015-05-31-09-00-00-consensus:0 2015-05-31-10-00-00-consensus:0 2015-05-31-11-00-00-consensus:0 2015-05-31-12-00-00-consensus:0 2015-05-31-13-00-00-consensus:1587 2015-05-31-14-00-00-consensus:1588 2015-05-31-15-00-00-consensus:1584 2015-05-31-16-00-00-consensus:1574 2015-05-31-17-00-00-consensus:1573 2015-05-31-18-00-00-consensus:1574 2015-05-31-19-00-00-consensus:1571 2015-05-31-20-00-00-consensus:1572 2015-05-31-21-00-00-consensus:1568 2015-05-31-22-00-00-consensus:1568 2015-05-31-23-00-00-consensus:1569 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJVbDmWAAoJEJD5dJfVqbCrKMQH/28Li11R/z+JmP1pxUwN0tgB rUWlxJSmMNBWUWnASeIlMNy/QJyR/gvVINxiT6YbsesyLZMg+0Unxqs95h20QMLc taa+Du/z936uw7b+O190C1HwEPbReqjoXtGuUGYSmGety4ycm7d9dQwvIxvbWoEi Vc/qrRGL7K0JJoZTJpKxYzWgq4HWlFTW0NFmBPk6rG1/3uFAc7wS3wJ3ycJo2T31 Ye/lC6HsGx2y5nSgsgsZ9w+Iyg39lkxLEX5KnRS+LEdrGBhh9PBfQ3HL3E5jCau4 t58z1i1CPrCaoXIlX/C/J28+2gwT7I21eDGyGeMDSsB70/5+8zWHthEMm62yiuk= =mGTz -----END PGP SIGNATURE-----

2 1

Tor Browser IsolateSOCKSAuth behavior questions.
by Yawning Angel 01 Jun '15

01 Jun '15

Hello, I've been working on a dumb hack that lets me do things like this: https://imgur.com/3mah244 (Yes, that's a single Tor Browser instance, separate windows used for illustrative purposes.) It's still very raw and doesn't do everything I want it to do, so I'm not really releasing the code yet, but I have some questions regarding how Tor Browser behaves when setting the SOCKS username for isolation purposes. Ideally I want my shim to enforce isolation between the various upstreams (Tor, I2P, whatever) correctly to avoid cross-protocol probing (and to shield the I2P administration interface from eeevil websites). This appears to be straight forward if the application is Tor Browser because IsolateSOCKSAuth is always used at first glance (I will assume for now that if users decide to use things like torsocks that do not use isolation this way that they know what they are doing). My question is, what causes Tor Browser to set the SOCKS username to "--unknown--" and what the behavior should be in that case if: * The destination is a ".onion" address. * The destination is a ".i2p" address. * The destination is the I2P management console. I'm fairly sure this should be "deny". * The destination is any other address (will be dispatched over Tor if running, I don't think I will attempt to support I2P outproxies because they suck). (I think allow because things break otherwise?) For destinations that are ".onion"/".i2p", I plan to be fairly strict about making sure the SOCKS5 target and the username matches (I need to be more relaxed for sites on the regular intertubes since cross-site resources are loaded (I may make this behavior configurable...). Is this dumb? Is it common for "foo.onion" to load resources off "bar.onion"? How about in I2P land? The final form of my shim will support running with any combination of "nothing" (Tor Browser just for the "privacy benefits", probably unsafe, I may reconsider this), I2P, and Tor (Though the most useful configuration is probably I2P + Tor). Thanks in advance, -- Yawning Angel

2 2

Re: [tor-dev] valid MyFamily syntax variations ('$FP=nick' ?)
by l.m 31 May '15

31 May '15

Hi again, Although, as you've noticed, the the node you mention, Konata lists *itself* in the Family Members. That would be a bug. At least compared to the other possibilities. Onionoo checks for the bidirectional relationship and, in other cases, excludes the current node being viewed. If the current node being viewed lists itself... --leeroy

1 0

valid MyFamily syntax variations ('$FP=nick' ?)
by nusenu 31 May '15

31 May '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi, according to the spec [1] relay ops can choose between fingerprint (with and without $ prefix) and nicknames when constructing their MyFamily configs. The man page recommends fingerprints. Now I'm faced with [2][3] families that use a combination: $fp=nick Are they actually valid or is this a bug or can one actually specify arbitrary strings there? (dir auths and onionoo apparently accept them) thanks [1] https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n504 [2] https://atlas.torproject.org/#details/2B76359D3AAA94CA107F447D2D14E481A99EB… (search for KosakaKirino) [3] https://collector.torproject.org/recent/relay-descriptors/server-descriptor… (this url has a lifetime) -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVa2WkAAoJEFv7XvVCELh0jEwQAJqdeZaFpRWPfI9/17o7aEKI Jx8Lp811GGwr4STO41ixwOIQ69hjNuav47apcmR4AsUVAq8zkSnzljKyYtVnp7qH 4EHx0kqIop92s9de1AFKg2XDnZ3u4eSN6z53VXeO2+/jFl2CgMVarzLYPHNBBF/x ev3zMk8gYsGA7K5TowZ+HnMalXhHLpTvO+iPPzNF6eY3/pG31hImFfHvhkJ5nrzB gex9wmCTXigM6I1mcT8mK8OH/2+MkNFra2h4tcEmqzmzRdWx1UWDTgl97Jp2injL UxuHL1RkoGLqlZ/MDiMiZPa4JurNRKgBXdZNsASOvcX8ZiPiCzqbbCm4hN4Rsidi ROWR8AcadA/9a5Ovi0z8IhxUiF8Ks2Wadeovp4w+E2NuYvFNmUpvkH0jVSViSE8n v+XClj0DX8oHirRqp80M0o5GpOB2hsRzT0+QhRFKYbikW2CRziM1ECWknw3aj3/z VPohoo6bkkLLBfrrXdgqclvgtoG/zPl8Ef203pmyTjPCFEdx4mJTLzq+hmjoaPsI h+RweF+HvDc0qM+6fiYeHExQl7YMNuT6GbG58lK6V8c+r++FIrPwfyOepAddoE0p dTAHfqYMYhDL952z916tmNNPnHXsUu8hVaIVuB9RvYjAU9FpPAz5Q5CDaIu+F4TY kb9dxHK1c8IHOGamYMOD =tbZE -----END PGP SIGNATURE-----

3 3

Damian's Status Report - May 2015
by Damian Johnson 31 May '15

31 May '15

Squirrels! Five newborn squirrels are in our tree! And they... oh right, code. Talk about code, Damian, like a professional. ... awww, but damn they're cute. -------------------------------------------------------------------------------- Stem Release 1.4.1 -------------------------------------------------------------------------------- Though not as adorable as baby squirrels the new release of Stem is still pretty sweet. Ephemeral hidden services, substantially faster descriptor parsing, and a host of other improvements can all be yours with a simple upgrade! https://blog.torproject.org/blog/stem-release-14 -------------------------------------------------------------------------------- Nyx Log Panel Rewrite -------------------------------------------------------------------------------- No, Nyx isn't done but its log panel is! This is the third major curses component to be rewritten, and I'm delighted to say it now sucks less! How did it suck, you ask? Though casual users may not have noticed arm had a laughably inefficient O(n^3) approach to log deduplication. This was in fact so terrible arm simply turned off deduplication when it started bogging down the system too much. This is just one of they myriad of improvements, but in Nyx deduplication is O(n^2) and can easily be made linear (... though fuzzy matching makes this grosser than I'd like so first seeing if further improvement is warranted). -------------------------------------------------------------------------------- Few other noteworthy things were... * Thanks to DonnchaC Stem's tor message parsing is now a dramatic 300x faster when using python3! https://github.com/DonnchaC/stem/pull/1 * Wrote a simple bandwidth scanner to exemplify manual circuit construction for our tutorials... https://stem.torproject.org/tutorials/to_russia_with_love.html#custom-path-… * Sambuddha both made our tutorial examples downloadable (#10411) and more easily testable (#16191)! Cheers! -Damian

1 0

Visualising similarities between relay descriptors
by Philipp Winter 31 May '15

31 May '15

Visualising the similarity between two Tor relay descriptors helps with finding Sybil attacks. I added code to sybilhunter [0] that takes as input relay descriptors, determines all (n^2)/2 pairwise similarities, and outputs DOT code (part of Graphviz) that illustrates relay clusters and what makes them similar. For now, this functionality is just a set of hard-coded rules that determine, e.g.: - Do the relays have the same, non-default exit policy? - Do the relays have a similar uptime? - Do the relays run on the same platform? To give you an idea of what this looks like, I took all relay descriptors archived by CollecTor [1] for 2015-05-30 and calculated similarities by running: $ sybilhunter -data 2015-05-30/ -cumulative -matrix -threshold 6 -visualise > sim.dot $ dot -o sim.svg -Tsvg sim.dot The resulting graph is online [2]. Vertices are relays (nickname in the first line, followed by the first eight hex digits), and the edge labels show the similarities. Unsurprisingly, there are several relay clusters that probably should be in a family, but aren't. For example, the "startor*", "torpids*", "manningsnowden*", and "Montharkan*" relays. There are, however, also several relay clusters, often named "default", that share the first two hex digits of their fingerprint. This is unlikely to be a coincidence, so they might have wanted to position themselves in the DHT. Please let me know if you have any suggestions on how to improve the tool or its visualisation. [0] <https://gitweb.torproject.org/user/phw/sybilhunter.git/> [1] <https://collector.torproject.org/recent/relay-descriptors/server-descriptor…> [2] <https://www.nymity.ch/sybilhunting/svg/2015-05-30_similarities.svg> Cheers, Philipp

1 0

How to connect test tor network from remote host.
by Mohiuddin Ebna Kawsar 30 May '15

30 May '15

Hi, I setup Tor Test-Network in my laptop using chutney with basic-min configuration and i also configured tor-browser with this test network to browse internet. But now i want to bootstrap Test Tor-Network inside Virtual Machine. (Virtual Machine 1 = (3 AUTHORITY + 1 RELAY) IP= *10.0.2.11* (Virtual Machine 2 = (tor-browser) IP= *10.0.2.9* But this time tor-browser is not bootstrapping. I can ping from (11 to 9) torbrowser torrc config () ############################################### AllowSingleHopExits 1 CircuitIdleTimeout 100 DataDirectory tor-browser_en-US/Browser/TorBrowser/Data/Tor DirReqStatistics 0 DirAuthority test000a orport=5000 no-v2 hs v3ident=32D2EB75473AB923F63D0D3C4B6929FC1BB658AE *10.0.2.11*:7000 1DB6AEADE945A2EE1722A203CFED30478D0C8C82 DirAuthority test001a orport=5001 no-v2 hs v3ident=0D6042A1C288C7891888248CDDAA58D9B907ECF1 *10.0.2.11* :7001 84B06F3CF268D941CD11E725AACA287152C90C70 DirAuthority test002a orport=5002 no-v2 hs v3ident=AD22661D7D85F72D3D24B789092F8BE4454EFFAC *10.0.2.11* :7002 2AFD392AC496045351CCF8CBF148944FEF0AEAE4 DisableDebuggerAttachment 0 ExitNodes test000a GeoIPFile tor-browser_en-US/Browser/TorBrowser/Data/Tor/geoip GeoIPv6File tor-browser_en-US/Browser/TorBrowser/Data/Tor/geoip6 KeepalivePeriod 100 TestingTorNetwork 1 ProtocolWarnings 1 SafeLogging 0 StrictNodes 1 ########################################################################### Please help..

2 7