- tor-dev - lists.torproject.org

[release] CollecTor 1.7.0
by Iain Learmonth 15 Jul '18

15 Jul '18

Hi, A new release is available: https://dist.torproject.org/collector/1.7.0/ The main change in this release is to recognise the new bridge authority, Serge. There are also additional minor fixes. Full details can be found in the changelog [1]. This CollecTor release is already deployed on all Tor Metrics CollecTor instances. Please direct comments and questions to the metrics-team mailing list [2]. Thanks, Iain -- on behalf of the Metrics Team. [1] https://gitweb.torproject.org/collector.git/tree/CHANGELOG.md?h=collector-1… [2] https://lists.torproject.org/cgi-bin/mailman/listinfo/metrics-team

1 0

Tor browser for Chrome OS
by Keifer Bly 13 Jul '18

13 Jul '18

Hello, So I am wondering, are there plans to develop a version of tor browser that will run on Chromebooks? I though that might be a good idea as those are getting somewhat popular in the US. Thanks.

3 2

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

lets make 'working DNS' an exit flag requirement
by nusenu 11 Jul '18

11 Jul '18

I'd like to see 'working DNS' as a requirement for the exit flag. If there are no major objections and if I'm able to find someone to implement it I'd like to proceed with writing a small proposal. Would anyone be willing to implement it in tor? https://trac.torproject.org/projects/tor/ticket/26691 -- https://twitter.com/nusenu_ https://mastodon.social/@nusenu

3 5

Re: [tor-dev] The case with Tor2Web
by Giovanni Pellerano 11 Jul '18

11 Jul '18

Hello George! no problem exists at all and an thank you so much for letting us know. definitely the safety of Tor has always to come first with no compromises :) take care, Giovanni 2018-07-11 12:06 GMT+02:00 Fabio Pietrosanti <fabio(a)pietrosanti.it>: > Hey George, > > not a problem if the Tor2webMode goes away, as it was an optimisation introduced years ago. > > Nowadays performance of Tor has greatly improved, so I really feel it will not be an issue for Tor2web use-case, especially now that the one-hop server-side is optimizable for Onion sites that wish to have such an performance improvement! :-) > > Fabio > >> On 9 Jul 2018, at 18:32, George Kadianakis <desnacked(a)riseup.net> wrote: >> >> Hello! >> >> It's a semi-secret that tor2web traffic has been blocked from the Tor >> network when we introduced the DoS subsystem this March [0]. The reason >> is that a big part of the DoS traffic was coming from one-hop clients >> continuously hammering onion services. >> >> This is something that we've been considering doing for a while (for >> security and code-complexity reasons), and it just happened naturally >> during the DoS incident. >> >> As part of this, and since the DoS subsystem is going to stick around, >> we are planning to permanently kill the Tor2Web subsystem of Tor, in an >> effort to simplify our codebase and our feature list. >> >> If you've been relying on tor2web for something, please consider >> switching to a normal 3-hop client indeed. This is a heads up so that >> you can let us know if that won't work for you, or you need help >> transitioning out. >> >> Cheers and hope we are not making you sad. >> >> [0]: https://trac.torproject.org/projects/tor/ticket/24902 >> https://blog.torproject.org/new-stable-tor-releases-security-fixes-and-dos-… >> > -- Ing. Giovanni Pellerano - Founding Member and CTO giovanni.pellerano(a)hermescenter.org | +39.328.9590046 HERMES - Center for Transparency and Digital Human Rights Associazione No Profit | Via Aretusa 34, IT-20129 Milan, Italy t. +39-02-87186005 (voicemail) | f. +39-02-87162573 TaxCode: IT-97621810155 | EuropeAid: IT-2012-AOD-0806909254 w. https://www.hermescenter.org | m. info(a)hermescenter.org

1 0

Anonymous local count statistics
by Saurav Malani 09 Jul '18

09 Jul '18

Hello Everyone, I am 4th year student at IIIT-H, India. I want to contribute to TOR project specifically to "*Anonymous local count statistics". *I am done with building TOR. I looked at the ticket and had an overview of Tor documentation. But, I feel like being lost. So, it would be great if someone here can guide me on this further, as I am a bit novice in this field, by providing links with relevant info related to the project and also by guiding me on what to do next? and what is done till now? Thank-you, Regards, Saurav Malani

2 1

The case with Tor2Web
by George Kadianakis 09 Jul '18

09 Jul '18

Hello! It's a semi-secret that tor2web traffic has been blocked from the Tor network when we introduced the DoS subsystem this March [0]. The reason is that a big part of the DoS traffic was coming from one-hop clients continuously hammering onion services. This is something that we've been considering doing for a while (for security and code-complexity reasons), and it just happened naturally during the DoS incident. As part of this, and since the DoS subsystem is going to stick around, we are planning to permanently kill the Tor2Web subsystem of Tor, in an effort to simplify our codebase and our feature list. If you've been relying on tor2web for something, please consider switching to a normal 3-hop client indeed. This is a heads up so that you can let us know if that won't work for you, or you need help transitioning out. Cheers and hope we are not making you sad. [0]: https://trac.torproject.org/projects/tor/ticket/24902 https://blog.torproject.org/new-stable-tor-releases-security-fixes-and-dos-…

2 1

locked out of my bug report #26675
by starlight.2018q2＠binnacle.cx 08 Jul '18

08 Jul '18

Today I opened a ticket regarding difficult to understand Torflow behavior. Subsequently I figured out the behavior, realizing it is a non-material bug that has no serious implication. However I can no longer revise the ticket, possibly due to https://trac.torproject.org/projects/tor/ticket/26675#comment:2 or perhaps due to the next change which somehow reversed >Date: Sat, 07 Jul 2018 01:33:46 -0000 >Changes (by cypherpunks): > * status: new => closed > * resolution: => fixed I find this troubling.

2 2

is that the correct URL in the TBB design document?
by nusenu 06 Jul '18

06 Jul '18

Hi, https://www.torproject.org/projects/torbrowser/design/#identifier-linkabili… writes: > While the vast majority of web requests adheres to the circuit and > connection unlinkability requirement there are still corner cases we > need to treat separately or that lack a fix altogether. "lack a fix altogether" links back to the design document itself: https://www.torproject.org/projects/torbrowser/design/ is that the correct URL or a copy-paste error? thanks! -- https://mastodon.social/@nusenu twitter: @nusenu_

2 4

Nearly everything in the Tor source code is moving in 0.3.5
by Nick Mathewson 05 Jul '18

05 Jul '18

Hello, friends! For quite a while now, the program "tor" has been built from source code in just two directories: src/common and src/or. This has become more-or-less untenable, for a few reasons -- most notably of which is that it has led our code to become more spaghetti-ish than I can endorse with a clean conscience. So to fix that, we've gone and done a huge code movement in our git master branch, which will land in a release once Tor 0.3.5.1-alpha is out. Here's what we did: * src/common has been turned into a set of static libraries. These all live in the "src/lib/*" directories. The dependencies between these libraries should have no cycles. The libraries are: arch -- Headers to handle architectural differences cc -- headers to handle differences among compilers compress -- wraps zlib, zstd, lzma container -- high-level container types crypt_ops -- Cryptographic operations. Planning to split this into a higher and lower level library ctime -- Operations that need to run in constant-time. (Properly, data-invariant time) defs -- miscelaneous definitions needed throughout Tor. encoding -- transforming one data type into another, and various data types into strings. err -- lowest-level error handling, in cases where we can't use the logs because something that the logging system needs has broken. evloop -- Generic event-loop handling logic fdio -- Low-level IO wrapper functions for file descriptors. fs -- Operations on the filesystem intmath -- low-level integer math and misc bit-twiddling hacks lock -- low-level locking code log -- Tor's logging module. This library sits roughly halfway up the library dependency diagram, since everything it depends on has to be carefully crafted to *not* log. malloc -- Low-level wrappers for the platform memory allocation functions. math -- Higher-level mathematical functions, and floating-point math memarea -- An arena allocator meminfo -- Functions for querying the current process's memory status and resources net -- Networking compatibility and convenience code osinfo -- Querying information about the operating system process -- Launching and querying the status of other processes sandbox -- Backend for the linux seccomp2 sandbox smartlist_core -- The lowest-level of the smartlist_t data type. Separated from the rest of the containers library because the logging subsystem depends on it. string -- Compatibility and convenience functions for manipulating C strings. term -- Terminal-related functions (currently limited to a getpass function). testsupport -- Macros for mocking, unit tests, etc. thread -- Higher-level thread compatibility code time -- Higher-level time management code, including format conversions and monotonic time tls -- Our wrapper around our TLS library trace -- Formerly src/trace -- a generic event tracing API wallclock -- Low-level time code, used by the log module. * To ensure that the dependency graph in src/common remains under control, there is a tool that you can run called "make check-includes". It verifies that each module in Tor only includes the headers that it is permitted to include, using a per-directory ".may_include" file. * The src/or/or.h header has been split into numerous smaller headers. Notably, many important structures are now declared in a header called foo_st.h, where "foo" is the name of the structure. * The src/or directory, which had most of Tor's code, had been split up into several directories. This is still a work in progress: This code has not itself been refactored, and its dependency graph is still a tangled web. I hope we'll be working on that over the coming releases, but it will take a while to do. The new top-level source directories are: src/core -- Code necessary to actually perform or use onion routing. src/feature -- Code used only by some onion routing configurations, or only for a special purpose. src/app -- Top-level code to run, invoke, and configure the lower-level code The new second-level source directories are: src/core/crypto -- High-level cryptographic protocols used in Tor src/core/mainloop -- Tor's event loop, connection-handling, and traffic-routing code. src/core/or -- Parts related to handling onion routing itself src/core/proto -- Support for encoding * The "tor" executable is now built in src/app/tor rather than src/or/tor. * There are more static libraries than before that you need to build into your application if you want to embed Tor. Rather than maintaining this list yourself, I recommend that you run "make show-libs" to have Tor emit a list of what you need to link.

1 1