- tor-dev - lists.torproject.org

Compiling tor against OpenSSL_1_0_2-stable
by Christian Kujau 29 Nov '12

29 Nov '12

Hi, while trying to compile the latest git-checkout against openssl-1.0.2, I've come across the following issues: ---- make[1]: Entering directory `/usr/local/src/tor-git' CC src/common/tortls.o cc1: warnings being treated as errors In file included from /opt/openssl/include/openssl/ssl.h:1382, from src/common/tortls.c:36: /opt/openssl/include/openssl/srtp.h:138: error: redundant redeclaration of ‘SSL_get_selected_srtp_profile’ /opt/openssl/include/openssl/srtp.h:135: note: previous declaration of ‘SSL_get_selected_srtp_profile’ was here make[1]: *** [src/common/tortls.o] Error 1 make[1]: Leaving directory `/usr/local/src/tor-git' make: *** [all] Error 2 ---- There is an open ticket[0] in the openssl bugtracker for this. While the proper solution is to fix openssl/include/openssl/srtp.h, I wanted to compile without -Werror. However, when adding CFLAGS="-Wno-error" during ./configure, -Werror is still added to the ./Makefile and overriding -Wno-error. When adding CFLAGS="-Wno-error" during "make" all the other CFLAGS are gone too. Thus I ended up removing -Werror from the Makefile and tortls.o compiled. While this is really an issue with openssl, I wanted to have this documented, just in case anybody else tries the same. If someone knows of a better workaround (i.e. compiling just tortls.c with -Wno-error and everything else with -Werror), please share! :-) A bit later, compilation stops again: ---- CCLD src/or/tor src/common/libor-crypto.a(aes.o): In function `aes_crypt': aes.c:(.text+0x860): undefined reference to `CRYPTO_ctr128_encrypt' collect2: ld returned 1 exit status make[1]: *** [src/or/tor] Error 1 make[1]: Leaving directory `/usr/local/src/tor-git' make: *** [all] Error 2 ---- Hm, this leaves me puzzled for now. CRYPTO_ctr128_encrypt is still included in openssl-1.0.2 and src/common/aes.o seems to be built with this function included as well, not sure why src/common/libor-crypto.a complains now: ---- $ grep -r CRYPTO_ctr128_encrypt /opt/openssl/ /opt/openssl/include/openssl/modes.h:void CRYPTO_ctr128_encrypt(const unsigned char *in, unsigned char *out, /opt/openssl/include/openssl/modes.h:void CRYPTO_ctr128_encrypt_ctr32(const unsigned char *in, unsigned char *out, Binary file /opt/openssl/bin/openssl matches Binary file /opt/openssl/lib/libcrypto.a matches $ grep -r CRYPTO_ctr128_encrypt . ./src/common/aes.c: CRYPTO_ctr128_encrypt((const unsigned char *)input, Binary file ./src/common/aes.o matches Binary file ./src/common/libor-crypto.a matches ---- Why do I (try to) build against openssl-1.0.2? I'm on Debian/stable which still ships openssl-0.9.8o and I wanted to get rid of this "use a more recent OpenSSL" message during startup :-) Otherwise, today's git-checkout of tor runs just fine when built against openssl-0.9.8 (on powerpc) - yay! Christian. [0] http://rt.openssl.org/Ticket/Display.html?id=2724 -- BOFH excuse #330: quantum decoherence

2 2

More TBB usability challenges
by Andrew Lewman 28 Nov '12

28 Nov '12

I was asked to meet with some people doing work in dangerous areas of Latin America. In general, these people can get around and work with Microsoft Windows competently. They are all fluent in English, Spanish, and various dialects found in Latin American countries. Most of them had Spanish-language versions of Windows 7 on their laptops. # Getting TBB During the discussion, an informal usability study happened. I thought having a discussion about this may be better than simply opening a trac ticket. Here's roughly the scenario. I asked people to download Tor Browser from our website. All found Tor's website via Bing. Interestingly, some searched for "tor", others for "tor browser", and one for "tor project". They were all using Internet Explorer and Bing because that's the default for Windows 7. Thankfully, our website is the top result for all three queries at Bing. They all found the big purple "Download Tor" button on the index page. Issue #1: Running TBB from the website. When clicking the orange "Download Tor Browser Bundle" button, IE prompts them to "Run", "Save", or "Cancel". All of them chose "Run". Issue #1A: When choosing "Run", a prompt appears, "The publisher of tor-browser-2.2.39-5_en-US.exe couldn't be verified. Are you sure you want to run the program?". All of them hit "Yes" and ignored the warning. Issue #1B: When the download completed, they were prompted with the 7zip self-extractor giving them a path similar to this: "C:\Users\tor\AppData\Local\Microsoft\Windows\Temporary Internet Files\Content.IE5\T868H68M\". All of them pushed the "Extract" button and let 7zip extract TBB into that temporary directory. A few of them went to the Downloads folder to try to find TBB. However, it's not there because it's extracted into a temporary folder. This folder is not reachable by the user through File Explorer. Issue #2: Downloading TBB. After some Q&A about what happened, I asked them to "Save" rather than "Run". TBB then downloads. The user is prompted with a warning box stating, "The publisher of tor-browser-2.2.39-5_en-US.exe couldn't be verified." And the user is left to choose between "Run" and "View downloads". When clicking "Run" the user is prompted with the 7-zip self-extractor prompt and "C:\Users\tor\Downloads\" is the default path. All of them hit the "Extract" button. None of them were sure what just happened nor why TBB needs to be extracted. Issue #2A: The self-extract completes and the user is left looking at their IE window with the TBB download page. Three of them went to their Downloads folder to find Tor. The other few waited for something to happen. When I asked the waiting few why they were waiting, they said because they "ran TBB" and expected the extraction to automatically start TBB for them. Issue #3: In the Downloads folder there are two things called "tor browser", one is an application the other is a file folder. See https://people.torproject.org/~andrew/2012-11-28-tbb-usability-test/2012-11… for an example. Most of the people had hundreds of files in the Download folder, so it wasn't as clear as this example screenshot. Some people wanted to run the application, because in their mind, you run an application. When asked to go into the Tor Browser folder, they all found "Start Tor Browser" and ran it (some double-left click, some right click and choose "Open"). See https://people.torproject.org/~andrew/2012-11-28-tbb-usability-test/2012-11… for what it looks like by default. Issue #4: Once TBB was started, the users would alt-tab between applications or choose various apps in their task bar at the bottom of the screen. They kept clicking the onion icon because they thought it was TBB, when it brings up the Vidalia control panel. This is what it looks like, https://people.torproject.org/~andrew/2012-11-28-tbb-usability-test/2012-11… Issue #5: No one knew what "Startpage" was nor why it was in the top bar. Just like IE, they all wanted to search from the awesome bar by default. This does work, and they can search via startpage.com via the awesome bar. From here on out, the normal TBB issues apply, as demonstrated by Greg's HotPETS paper, https://people.torproject.org/~andrew/hotpets12-1-usability.pdf # Feedback I asked how we can improve this entire process. The consensus is that TBB needs to be a single application people can just run and get the browser going. The extraction process was confusing and was sometimes called an installation process. They felt that "running" it from the tor download site was fine, so long as everything just worked and a browser window popped up. They also felt that the Vidalia control panel was unnecessary. It just confused them. The only thing they felt was valuable was the Network Map. A caveat is that we were on a US network which didn't censor. The Message Log and bridge/obfsproxy functionality wasn't needed in this case. I suspect it will be when they try this in Latin America. -- Andrew http://tpo.is/contact pgp 0x6B4D6475

1 0

Proposal: Tor Extended ORPort Authentication
by George Kadianakis 28 Nov '12

28 Nov '12

Greetings, I'm attaching a proposal for adding authentication to the Extended ORPort. The Extended ORPort is a yet unimplemented feature, that allows pluggable transports proxies to communicate with Tor; it's a prerequisite for pluggable transport statistics, rate limiting, and other cool things. Filename: XXX-ext-orport-auth.txt Title: Tor Extended ORPort Authentication Author: George Kadianakis Created: 28-11-2012 Status: Open Target: 0.2.5.x 1. Overview This proposal defines a scheme for Tor components to authenticate to each other using a shared-secret. 2. Motivation Proposal 196 introduced new ways for pluggable transport proxies to communicate with Tor. The communication happens using TCP in the same fashion that controllers speak to the ControlPort. To defend against cross-protocol attacks [0] on the transport ports, we need to define an authentication scheme that will restrict passage to unknown clients. Tor's ControlPort uses an authentication scheme called safe-cookie authentication [1]. Unfortunately, the design of the safe-cookie authentication was influenced by the protocol structure of the ControlPort and the need for backwards compatibility of the cookie-file and can't be easily reused in other use cases. 3. Goals The general goal of Extended ORPort authentication is to authenticate the client based on a shared-secret that only authorized clients should know. Furthermore, its implementation should be flexible and easy to reuse, so that it can be used as the authentication mechanism in front of future Tor helper ports (for example, in proposal 199). Finally, the protocol is able to support multiple authentication schemes and each of them has different goals. 4. Protocol Specification 4.1. Initial handshake When a client connects to the Extended ORPort, the server sends: AuthTypes [variable] EndAuthTypes [1 octet] Where, + AuthTypes are the authentication schemes that the server supports for this session. They are multiple concatenated 1-octet values that take values from 1 to 255. + EndAuthTypes is the special value 0. The client reads the list of supported authentication schemes and replies with the one he prefers to use: AuthType [1 octet] Where, + AuthType is the authentication scheme that the client wants to use for this session. A valid authentication type takes values from 1 to 255. A value of 0 means that the client did not like the authentication types offered by the server. If the client sent an AuthType of value 0, or an AuthType that the server does not support, the server MUST close the connection. 4.2. Authentication types 4.2.1 SAFE_COOKIE handshake Authentication type 1 is called SAFE_COOKIE. 4.2.1.1. Motivation and goals The SAFE_COOKIE scheme is pretty-much identical to the authentication scheme that was introduced for the ControlPort in proposal 193. An additional goal of the SAFE_COOKIE authentication scheme (apart from the goals of section 2), is that it should not leak the contents of the cookie-file to untrusted parties. Specifically, the SAFE_COOKIE protocol will never leak the actual contents of the file. Instead, it uses a challenge-response protocol (similar to the HTTP digest authentication of RFC2617) to ensure that both parties know the cookie without leaking it. 4.2.1.2. Cookie-file format The format of the cookie-file is: StaticHeader [32 octets] Cookie [32 octets] Where, + StaticHeader is the following string: "! Extended ORPort Auth Cookie !\x0a" + Cookie is the shared-secret. During the SAFE_COOKIE protocol, the cookie is called CookieString. Extended ORPort clients MUST make sure that the StaticHeader is present in the cookie file, before proceeding with the authentication protocol. Details on how Tor locates the cookie file can be found in section 5 of proposal 196. Details on how transport proxies locate the cookie file can be found in pt-spec.txt. 4.2.1.3. Protocol specification A client that performs the SAFE_COOKIE handshake begins by sending: ClientNonce [32 octets] Where, + ClientNonce is 32 octets of random data. Then, the server replies with: ServerHash [32 octets] ServerNonce [32 octets] Where, + ServerHash is computed as: HMAC-SHA256(CookieString, "ExtORPort authentication server-to-client hash" | ClientNonce | ServerNonce) + ServerNonce is 32 random octets. Upon receiving that data, the client computers ServerHash herself and validates it against the ServerHash provided by the server. If the server-provided ServerHash is invalid, the client MUST terminate the connection. Otherwise the client replies with: ClientHash [32 octets] Where, + ClientHash is computed as: HMAC-SHA256(CookieString, "ExtORPort authentication client-to-server hash" | ClientNonce | ServerNonce) Upon receiving that data, the server computers ClientHash herself and validates it against the ClientHash provided by the client. Finally, the server replies with: Status [1 octet] Where, + Status is 1 if the authentication was successfull. If the authentication failed, Status is 0. 4.3. Post-authentication After completing the Extended ORPort authentication successfully, the two parties should proceed with the Extended ORPort protocol on the same TCP connection. [0]: http://archives.seul.org/or/announce/Sep-2007/msg00000.html [1]: https://gitweb.torproject.org/torspec.git/blob/79f488c32c43562522e5592f2c19…

2 2

questions about parallel Tor circuits en masse & adoption drivers
by Simon 27 Nov '12

27 Nov '12

Hello, I'm interesting in discussing the development aspects of using Tor as a massively distributed anonymous file server where blocks (e.g. 4KB) of a particular file (e.g. even several GB in size) might be redundantly distributed on very many hidden service nodes (e.g. a unique 4KB block of a file redundantly duplicated on ~ x hidden nodes from y million total hidden service nodes) and access to the file would be high through-put because very many (e.g. cable bandwidth / 4KB, e.g. 50 Mbps is 6.25 MB/s or 1600 * 4KB blocks per second) concurrent but high latency Tor circuits. Thus each Tor circuit would still be the usual high latency, but very many Tor circuits in parallel would deliver fantastic through-put. What if Tor could handle several rolling window bundles of e.g. 1,600 parallel Tor circuits which request one small block of info from 1,600 unique hidden service nodes? Does Tor parallelized, high bandwidth file sharing already exist? Does Tor already handle a massively parallelized number of Tor circuits, on the scale of thousands or tens of thousands of Tor circuits? Is many concurrent Tor circuits desirable? Who is working on it? Would using Tor as a massively distributed anonymous file server dramatically increase the number of Tor nodes (due to file sharing being more desirable than anonymity) and therefore make the entire Tor system more resilient to attack due to high growth and orders of magnitude more nodes? Is such an expansion -- on the back of a new functional focal point; i.e. not anonymity -- politically desirable for the Tor project? Thanks, Simon Experienced network programming enthusiast from Vancouver, Canada

1 0

tor exit node modules in Tor source codes
by esolve esolve 27 Nov '12

27 Nov '12

I'm doing research on Tor and I want to modify the tor exit node functions. I downloaded the source codes from this link https://gitweb.torproject.org/tor.git/tree/b13c6becc892d9716d8645f16b5d03bd… but I can't find the modules/files which are related to tor exit functions(like receive cells from previous relay router, send HTTP/TCP connection request to webserver/remote_host, buffer management) can anyone give some hints? thanks!

1 0

Re: [tor-dev] RIAA v Verizon: 404
by Christian Kujau 27 Nov '12

27 Nov '12

On Mon, 26 Nov 2012 at 17:40, leez wrote: > The lost document was actually this one: > https://www.eff.org/document/dc-circuit-opinion-granting-verizons-motion-qu… > > I've added a redirect from the broken link, so either will get you > there now. Thanks for fixing this! Christian. -- BOFH excuse #171: NOTICE: alloc: /dev/null: filesystem full

1 0

[PATCH 1/2] New option LocalOutboundBindAddress
by Andrew Cady 27 Nov '12

27 Nov '12

This works just like OutboundBindAddress, but instead of excluding connections to loopback addresses, it affects only connections to loopback addresses. The whitespace in this commit is a bit nutty, in order to put whitespace changes into a separate commit. --- doc/tor.1.txt | 11 +++++++++++ src/or/config.c | 25 ++++++++++++++++--------- src/or/connection.c | 17 ++++++++++------- src/or/or.h | 6 ++++++ 4 files changed, 43 insertions(+), 16 deletions(-) diff --git a/doc/tor.1.txt b/doc/tor.1.txt index 1e1ff1e..f25234d 100644 --- a/doc/tor.1.txt +++ b/doc/tor.1.txt @@ -477,6 +477,17 @@ GENERAL OPTIONS This setting will be ignored for connections to the loopback addresses (127.0.0.0/8 and ::1). +**LocalOutboundBindAddress** __IP__:: + Like OutboundBindAddress, but _only_ for connections to loopback + addresses (e.g., inbound connections to local hidden services). + This is useful to distinguish Tor traffic from local traffic in + the log files of your hidden services. + + + + The IP should be in the 127.0.0.0/8 range for maximum compatibility. + I recommend using 127.84.111.114, since 84.111.114 is the ASCII + encoding of "Tor". I also recommend adding \'127.84.111.114 tor' to + your /etc/hosts file. + **PidFile** __FILE__:: On startup, write our PID to FILE. On clean shutdown, remove FILE. diff --git a/src/or/config.c b/src/or/config.c index 206ccc8..03e07f9 100644 --- a/src/or/config.c +++ b/src/or/config.c @@ -285,6 +285,7 @@ static config_var_t option_vars_[] = { OBSOLETE("IgnoreVersion"), V(KeepalivePeriod, INTERVAL, "5 minutes"), VAR("Log", LINELIST, Logs, NULL), + V(LocalOutboundBindAddress, LINELIST, NULL), V(LogMessageDomains, BOOL, "0"), OBSOLETE("LinkPadding"), OBSOLETE("LogLevel"), @@ -5556,15 +5557,20 @@ getinfo_helper_config(control_connection_t *conn, static int parse_outbound_addresses(or_options_t *options, int validate_only, char **msg) { - const config_line_t *lines = options->OutboundBindAddress; - int found_v4 = 0, found_v6 = 0; + int i; + for (i=0; i<2; ++i) { + + tor_addr_t *out4 = i ? &options->OutboundBindAddressIPv4_ : &options->LocalOutboundBindAddressIPv4_; + tor_addr_t *out6 = i ? &options->OutboundBindAddressIPv6_ : &options->LocalOutboundBindAddressIPv6_; if (!validate_only) { - memset(&options->OutboundBindAddressIPv4_, 0, - sizeof(options->OutboundBindAddressIPv4_)); - memset(&options->OutboundBindAddressIPv6_, 0, - sizeof(options->OutboundBindAddressIPv6_)); + memset(out4, 0, sizeof(*out4)); + memset(out6, 0, sizeof(*out6)); } + + const config_line_t *lines = i ? options->OutboundBindAddress : options->LocalOutboundBindAddress; + int found_v4 = 0, found_v6 = 0; + while (lines) { tor_addr_t addr, *dst_addr = NULL; int af = tor_addr_parse(&addr, lines->value); @@ -5577,7 +5583,7 @@ parse_outbound_addresses(or_options_t *options, int validate_only, char **msg) return -1; } found_v4 = 1; - dst_addr = &options->OutboundBindAddressIPv4_; + dst_addr = out4; break; case AF_INET6: if (found_v6) { @@ -5587,7 +5593,7 @@ parse_outbound_addresses(or_options_t *options, int validate_only, char **msg) return -1; } found_v6 = 1; - dst_addr = &options->OutboundBindAddressIPv6_; + dst_addr = out6; break; default: if (msg) @@ -5599,7 +5605,8 @@ parse_outbound_addresses(or_options_t *options, int validate_only, char **msg) tor_addr_copy(dst_addr, &addr); lines = lines->next; } - return 0; + } + return 0; } /** Load one of the geoip files, <a>family</a> determining which diff --git a/src/or/connection.c b/src/or/connection.c index dbcfc41..397a2dc 100644 --- a/src/or/connection.c +++ b/src/or/connection.c @@ -1451,14 +1451,17 @@ connection_connect(connection_t *conn, const char *address, make_socket_reuseable(s); - if (!tor_addr_is_loopback(addr)) { + { + const int is_local = tor_addr_is_loopback(addr); const tor_addr_t *ext_addr = NULL; - if (protocol_family == AF_INET && - !tor_addr_is_null(&options->OutboundBindAddressIPv4_)) - ext_addr = &options->OutboundBindAddressIPv4_; - else if (protocol_family == AF_INET6 && - !tor_addr_is_null(&options->OutboundBindAddressIPv6_)) - ext_addr = &options->OutboundBindAddressIPv6_; + const tor_addr_t *maybe_ext_addr4 = is_local ? &options->LocalOutboundBindAddressIPv4_ : &options->OutboundBindAddressIPv4_; + const tor_addr_t *maybe_ext_addr6 = is_local ? &options->LocalOutboundBindAddressIPv6_ : &options->OutboundBindAddressIPv6_; + + if (protocol_family == AF_INET && !tor_addr_is_null(maybe_ext_addr4)) + ext_addr = maybe_ext_addr4; + else if (protocol_family == AF_INET6 && !tor_addr_is_null(maybe_ext_addr6)) + ext_addr = maybe_ext_addr6; + if (ext_addr) { struct sockaddr_storage ext_addr_sa; socklen_t ext_addr_len = 0; diff --git a/src/or/or.h b/src/or/or.h index a8645f8..a832e4f 100644 --- a/src/or/or.h +++ b/src/or/or.h @@ -3181,6 +3181,12 @@ typedef struct { tor_addr_t OutboundBindAddressIPv4_; /** IPv6 address derived from OutboundBindAddress. */ tor_addr_t OutboundBindAddressIPv6_; + /** Local address to bind outbound sockets -- for loopback connections (e.g., hidden services) */ + config_line_t *LocalOutboundBindAddress; + /** IPv4 address derived from LocalOutboundBindAddress. */ + tor_addr_t LocalOutboundBindAddressIPv4_; + /** IPv6 address derived from LocalOutboundBindAddress. */ + tor_addr_t LocalOutboundBindAddressIPv6_; /** Directory server only: which versions of * Tor should we tell users to run? */ config_line_t *RecommendedVersions; -- 1.7.10.4

1 1

RIAA v Verizon: 404
by Christian Kujau 26 Nov '12

26 Nov '12

Hi, the Tor DMCA response[0] has a link inside for the RIAA v. Verizon case: https://www.eff.org/legal/cases/RIAA_v_Verizon/opinion-20031219.pdf But this document is no longer available at this address, thus producing a 404. @EFF Webmaster, could you please fix this or provide the new address of this document? Is this perhaps the following: https://www.eff.org/sites/default/files/filenode/RIAA_v_Verizon/20030121-ri… I've cc'ed tor-dev, because the link is included in contrib/tor-exit-notice.html for the Tor exit nodes to present. Thanks, Christian. [0] https://www.torproject.org/eff/tor-dmca-response -- BOFH excuse #60: system has been recalled

2 1

Re: [tor-dev] Request for comments on notes on parallel cell crypto
by Nick Mathewson 19 Nov '12

19 Nov '12

On Sun, Nov 18, 2012 at 7:43 PM, Andrea Shepard <andrea(a)torproject.org> wrote: > I've made some notes on parallelizing cell crypto on relays which I've > attached to this mail and added to the wiki page on this [1], which I > would like comment on. Particularly, I want to resolve the following > points: > > * Should we operate on cell_t or packed_cell_t? After reading your comments, I don't feel strongly that packed_cell_t is correct. Either would probably be okay. I think I might have said "packed_cell_t" on the grounds that we already have a specialized allocator for them, whereas we don't currently heap-allocate as many cell_t as we would need for this. I might also have said "packed_cell_t" on the theory that copying data from cell_t to packed_cell_t would waste cycles, but I'm not sure that's significant here. Or maybe I was thinking of the amount of space wasted in packed_cell_t vs cell_t, and worried about the number of queued cells we're likely to have at once. For queueing the cell_ts, and where to put a next pointer: I *think* (but can't be sure) that most of our cell_t objects are currently short-lived, and most of our long-lived cell objects are currently packed_cell_t. So adding fields to cell_t wouldn't hurt much, since they don't currently represent very much of our total allocation, I think. (We should double-check that!) > * Is it acceptable for the main thread to call functions to > manipulate job-dispatching data structures that need to > acquire a lock if we can be sure everything that ever > holds the lock only does so very briefly to manipulate > those structures and will never block while holding it, > or do we need to design something that's lock-free for > the main thread? I don't think the main thread needs to be lock-free so long as it won't often block for too long. I was initially planning to have locks protect the work-queues initially, and only substitute in a lock-free work-queue implementation if it turned out to matter. (How long the lock is held by the main thread is less important for performance IIUC than whether the main thread will spend much time blocked waiting for the lock, or how much lock contention there will be.) > * The functions that currently call relay_crypt()/ > relay_crypt_one_payload() will have to be split into > two parts, one that queues a cell to be crypted and > another that handles the finished, crypted cell. > How will the worker threads cause the second part to > be called in the main thread? (NickM, there's probably > some libevent voodoo I don't know about yet for this?) So, I'd suggest the we start with a work queue each way: one queue (or set of queues) to enqueue stuff for worker threads, and one to enqueue the crypted stuff for the main cell to process it. That said, we'll need a way to alert the main thread "Hey, you have more data on your queue!" The easiest way to do that is, using Libevent 2.0 or later, to just call event_active() on a "struct event" whose callback processes the data. (This needs to require Libevent 2.0 or later, since Libevent 1.4 and earlier didn't let you do this threadsafely.) The next easiest alternative would be to construct a socketpair, have the main thread listen on the read side of it (using a read event), and have the worker thread write a byte to the socketpair whenever the queue went from "observed" . There are faster ways to do all of the above, and more ways we could optimize libevent to help with our particular case, but for now I'll suggest we ignore them: getting even one extra core to do crypto with will more than pay for all the overhead in a v1 implementation. We can find the painful points and optimize them later -- and waiting to do so will ensure we don't waste time optimizing outside of critical paths. In fact, we should probably be doing this for the rest of the design: looking to see if there are cases where even if we think we might need to get complex eventually, we can still do them simply at first. (For the case of sending work to the worker threads, a mutex/condition-var pair will do. Windows Vista added real condition variables, and there's plenty of compat code around to fake them with earlier Windowses.) I suggest that for the first implementation of this, we can just make the multithreaded crypto stuff require Libevent 2.0 or later. We'll want a compile option to turn it off for old OpenBSDs anyway. Turning multithreaded cypto off should be easy, right? Instead of "Thread1: enqueue. Thread2: unqueue, encrypt, enqueue. Thread1: unqueue, process", you just replace the first "enqueue" operation with "encrypt and process" -- perhaps making a stub relaycrypt_dispatcher_t that doesn't actually dispatch anything, but just does the crypto operation immediately. This might even be a good intermediate step while refactoring the crypto. > Once these are resolved I'll be making a branch for this and > writing the headers with proposed data structures and interfaces > for review. Cool; thank you! Another observation about your design sketch: If we implement this nicely, I think it will be possible to stress-test it and load-test the relaycrypt_dispatcher_t part of it without actually requiring the rest of Tor to be running. IOW, we could have a performance-test for this component that didn't require any actual Tor traffic to be happening, or circuits to exist. IMO that would be a pretty good idea, since it would help us optimize as needed, and it would encourage loose coupling. cheers, -- Nick

3 3

Proposal 215: Let the minimum consensus method change with time
by Nick Mathewson 19 Nov '12

19 Nov '12

Filename: 215-update-min-consensus-ver.txt Title: Let the minimum consensus method change with time Author: Nick Mathewson Created: 15 Nov 2012 Status: Open 0. Overview This proposal suggests that we drop the requirement that authorities support the very old consensus method "1", and instead move to a wider window of recognized consensus methods as Tor evolves. 1. Background and Motivation When we designed the directory voting system, we added the notion of "consensus method" so that we could smoothly upgrade the voting process over time. We also said that all authorities must support the consensus method '1', and must fall back to it if they don't support the method that the supermajority of authorities will choose. Consensus method 1 is no longer viable for the Tor network. It doesn't result in a microdescriptor consensus, and omits other fields that clients need in order to work well. Consensus methods under 12 have security issues, since they let a single authority set a consensus parameter. In the future, new consensus methods will be needed so that microdescriptor-using clients can use IPv6 exits and ECC onion-keys. Rolling back from those would degrade functionality. We need a way to change the minimum consensus method over time. 2. Design I propose that we change the minimum consensus method about once per release cycle, or once per ever other release cycle. As a rule of thumb, let the minimum consensus method in Tor series X be the highest method supported by the oldest version that "anybody reasonable" would use for running an authority. Typically, that's the stable version of the previous release series. For flexibility, it might make sense to choose a slightly older method, if falling back to that method wouldn't cause security problems. For example, while Tor 0.2.4.x is under development, authorities should really not be running anything before Tor 0.2.3.x. Tor 0.2.3.x has supported consensus method 13 since 0.2.3.21-rc, so it's okay for 0.2.4.x to require 13 as the minimum method. We even might go back to method 12, since the worst outcome of not using 13 would be some warnings in client logs. Consensus method 12 was a security improvement, so we don't want to roll back before that. 2.1. Behavior when the method used is one we don't know The spec currently says that if an authority sees that a method will be used that it doesn't support, it should act as if the consensus method will be "1". This attempt will be doomed, since the other authorities will be computing the consensus with a more recent method, and any attempt to use method "1" won't get enough signatures. Instead, let's say that authorities fall back to the most recent method that they *do* support. This isn't any likelier to reach consensus, but it is less likely to result in anybody signing something they don't like. 3. Likely outcomes If a bunch of authorities were to downgrade to a much older version, all at once, then newer authorities would not be able to sign the consensus they made. That's probably for the best: if a bunch of authorities were to suddenly start running 0.2.0.x, consensing along with them would be a poor idea. 4. Alternatives We might choose a less narrow window of allowable method, when we can do so securely. Maybe two release series, rather than one, would be a good interval to do when the consensus format isn't changing rapidly. We might want to have the behavior when we see that everybody else will be using a method we don't support be "Don't make a consensus at all." That's harder to program, though.

1 0