- tor-dev - lists.torproject.org

BridgeDB IPv6 Support (!)
by Aaron 17 Dec '11

17 Dec '11

code is here: https://gitweb.torproject.org/user/aagbsn/bridgedb.git/shortlog/refs/heads/… running code is here: https://tor.extc.org/ and here (ipv6): https://tor.extc.org/ipv6 None of the bridges at these addresses are valid, except by coincidence. Any feedback or questions are very welcome. Thanks! --Aaron

1 0

Draft Proposal for BridgeDB IPv6 Support
by Aaron 17 Dec '11

17 Dec '11

Attached is a draft document describing proposed changes to BridgeDB to accommodate the new or-address spec (186-multiple-orports.txt) and IPv6 bridges. I am especially interested in comments on sections tagged #XXX. Thanks! --Aaron

4 5

Tor on TV (hemm, on WDTV!)
by Fabio Pietrosanti (naif) 15 Dec '11

15 Dec '11

Hi all, i got a WDTV Live (http://support.wdc.com/product/install.asp?groupid=1003&lang=en) that's part of bigger family of consumer mediaplayer from Western Digital (http://support.wdc.com/product/install.asp?level1=10&lang=en) It seems it can run Tor without any major issue. There is a very nice hacked firmware community around WDTV users, that's a very cheap hardware (retail price 70-80EUR). What's about making a "promotional" campaign like for the Tor Cloud to have people running Tor Relay "right on their TV" ? I mean, the "hacked firmware" installation process of WDTV works that way: - Plug an USB Key formatted FAT32 with 3 files (boot, kernel, image) on WDTV - Poweron So it may be possible to make a campaign where users are invited to "run their tor relay" on their TV in 3 simple steps: - Get a USB Key - Load that files on it - Plug to your WDTV - Poweron your WDTV You are now helping poor sirian, iranian and chinese censored people. That way even the average fat guy sitting on his couch drinking beer and eating wing chicken can support freedom of speech. That kind of user can just "poweron" the WDTV and with his "remote control" after seeing his favorite telefilm on paytv, can just "zap" to see how his Tor Router is working: On TV! This could be defined as the "very lazy Tor user" who doesn't even want to use a computer, but just do TV zapping :P So, the idea could be to do a custom hacked firmware of WDTV and a WDTV Apps that you can "click" via remote control, seeing the statistics of your Tor Relay. # uname -a Linux WDTVLIVE 2.6.22.19-19-4 #28 PREEMPT Mon Mar 22 20:08:14 CST 2010 mips GNU/Linux # tor --version Jan 01 15:41:37.533 [notice] Tor v0.2.2.32 (git-877e17749725ab88). This is experimental software. Do not rely on it for strong anonymity. (Running on Linux mips) Tor version 0.2.2.32 (git-877e17749725ab88). # free total used free shared buffers Mem: 199056 193664 5392 0 10832 Swap: 0 0 0 Total: 199056 193664 5392 # cat /proc/cpuinfo system type : Sigma Designs TangoX processor : 0 cpu model : MIPS 24K V7.12 FPU V0.0 Initial BogoMIPS : 332.59 wait instruction : yes microsecond timers : yes tlb_entries : 32 extra interrupt vector : yes hardware watchpoint : yes ASEs implemented : mips16 shadow register sets : 1 VCED exceptions : not available VCEI exceptions : not available System bus frequency : 333000000 Hz CPU frequency : 499500000 Hz DSP frequency : 333000000 Hz -naif

4 6

Two questions about dir-spec.txt
by Karsten Loesing 14 Dec '11

14 Dec '11

Hi Nick, as the subject says, two quick questions about dir-spec.txt: 1. The "s" lines of network status entries are specified as: "s" SP Flags NL Now, when a relay has no flags at all, which can happen in a vote or could happen in older consensus methods, that relay would have an "s" line just consisting of "s", not "s ". I think it makes sense to omit the SP, but should this be specified? If so, how? There are other lines where it's not specified whether a trailing SP is permitted or not. But I think I only encountered "s" lines without any list elements so far. (I ran into problems here a while ago, when I looked for lines starting with "s " to overwrite an sLine string variable. But there was no "s " line for some relays, so the program used the "s " line from the previous relay. Went unnoticed. Ugh.) 2. The "m" lines in votes are not in dir-spec.txt. I haven't looked at proposal 158 yet. Is that proposal up-to-date? Thanks, Karsten

2 1

Purpose Controller Bug
by Tarik Karaoglu 14 Dec '11

14 Dec '11

Hi, I am trying to create circuits for use of my controller application however I got the following warning after my unsuccessful attempt. Dec 14 02:43:35.239 [warn] circuit_launch_by_extend_info(): Bug: unexpected purpose 19 when cannibalizing a circ. If I don't specify any purpose, I am able to create general purpose circuits. Another problem is that, is there a way to tell Tor to use separate circuits for each flow if possible when Tor attaches streams to circuits? Currently I am trying to attach streams to circuits using my controller but I am facing Proxy timeout issues like below: Dec 14 02:45:35.690 [notice] Tried for 120 seconds to get a connection to [scrubbed]:40000. Giving up. (waiting for controller) Any help will be appreciated. Thanks, Tarik

1 0

How to try out the new shiny IPv6 bridge support
by Linus Nordberg 13 Dec '11

13 Dec '11

Hi, With great help from Jeroen Massars address independence patch posted to this list earlier this year, a first milestone of IPv6 support in tor was reached in the 0.2.3.9-alpha release. Clients can now connect to private bridges over IPv6 if configured for that. If you are at all interested in trying out the new IPv6 support, this short HOWTO is for you. Please note that this is new code. Be prepared to run into bugs, hunt them down, report them, help out solve them and earn eternal fame and glory. It's a pain, but someone's got to do it. As part of proposal 186 ("Multiple addresses for one OR or bridge"), the ORPort configuration option has changed and ORListenAddress will be deprecated. We can use this for adding an IPv6 address to a bridge already running on an IPv4 address. (Another option is to run a bridge listening _only_ to IPv6 but note that every relay need IPv4 too, in order to speak to other OR's in the Tor network.) In order to configure a bridge to listen to an IPv6 address, add an ORPort option with an IPv6 address within square brackets and a port number like this: ORPort [2001:DB8::42]:4711 In order to have your client connect to a bridge over IPv6, simply state the address of the bridge within square brackets and a port number in a Bridge line: Bridge [2001:DB8::42]:4711 Note that there's still no support for IPv6 in BridgeDB. There is no harm in specifying PublishServerDescriptor 1 but nothing good will come out of it. You will have to find other ways of getting your bridge addresses to your users. Note also that if you configure your client with two (or more) addresses belonging to the very same bridge, your client will pick one of them and try to use that. This behaviour is not perfect and will change in future versions of tor. This behaviour isn't even bug free and should not be counted on -- especially when an IPv6 address is preferred over an IPv4 address, in which case the IPv4 address in many cases is the one being used anyway. Short story: Don't configure your client with more than one address per bridge. Please let me know if there are any questions about this and if you run in to any trouble setting it up. Then, when you run into the bugs, please go to https://trac.torproject.org/ and fire away. Thanks, Linus

1 0

Uploading video over Orbot
by Nathan Freitas 11 Dec '11

11 Dec '11

Some progress to share on Tor-related efforts with our Secure Smart Cam project with WITNESS. (More here: https://guardianproject.info/apps/securecam/ ) I know that "uploading HD video over a mobile network on Tor" has long been one of these cringe-inducing requests from NGOs, but at least for short clips, it seems to be working fairly well, both to YouTube and to the self-hostabled Videobin.org software. SSCXfer is my reduction of the Vidiom.mobi (http://vidiom.mobi/) app to be a focused, clean secure video uploader for YouTube and the self-hostable videobin.org software. Vidiom is pretty fantastic, but is a bit too kitchen sink, and also included features like FTP and Facebook upload which I don't feel comfortable putting a "secure" stamp on. The YouTube upload code comes from the very interesting "YouTube Direct" project's Android client: http://code.google.com/p/ytd-android/ The basic user story for SSCXfer is: "Alice has sensitive video evidence of a human rights crime recorded on her smartphone and wants to upload it to YouTube, but is in a country where YouTube is often blocked, and always monitored." a more complex one is: "Bob is a trained human rights defender working in a restrictive region, using his smartphone to interview victims about their experiences, and he needs to safely offload the videos from his phone to a secure private site as soon as possible, without raising any flags in the internet monitor systems." In this case "secure" and "safe", mean it will 1) use HTTPS as available, 2) store any local data in SQLCipher, and 3) support upload over proxy servers, specifically Orbot's built-in SOCKS or HTTP proxy without requiring root. In addition, the uploader must support low-bw, high latency connections, and support resumeable uploads. Finally, since videobin.org can be self-hosted, it is possible that a server could be run by WITNESS or any organization on a Tor hidden service .onion address, or at least on their own, https site. At this point, I've implemented support for Orbot/Tor working by enabling HTTP proxying support in all the HTTP connection code, and it is working quite well for both uploads to YouTube and the default Videobin.org site instance. Resume and retry seem to work, but I have not done extensive testing. I think the most extreme test scenario is uploading over Tor over EDGE network, and then going up and down into the subway. We'll see how we do in that case. Best, Nathan

1 1

AES_ctr128_encrypt() on Windows
by Gisle Vanem 07 Dec '11

07 Dec '11

Seems that this function isn't available in OpenSSL 1.1.0. On Windows at least. The function is enclosed in a "#if 0" in OpenSSL's <aes.h> and util/libeay.num also has this: AES_ctr128_encrypt 3216 NOEXIST::FUNCTION: So should we make an exception for Windows in common/aes.c: --- Git-latest/src/common/aes.c Mon Dec 05 16:54:55 2011 +++ src/common/aes.c Wed Dec 07 18:42:37 2011 @@ -17,7 +17,7 @@ #include <openssl/aes.h> #include <openssl/evp.h> #include <openssl/engine.h> -#if OPENSSL_VERSION_NUMBER >= 0x10000000L +#if (OPENSSL_VERSION_NUMBER >= 0x10000000L) && !defined(MS_WINDOWS) /* See comments about which counter mode implementation to use below. */ #include <openssl/modes.h> #define USE_OPENSSL_CTR --gv

2 2

Reduce TBB/OSX from 32MB to 23MB
by Fabio Pietrosanti (naif) 06 Dec '11

06 Dec '11

Hi all, made the following tricks that you can find attached to reduce the size of TBB/OSX from 32MB to 23MB . With this tricks it's possible to send TBB/OSX via Gmail using Gettor. It goes from: 32M /tmp/TorBrowser-2.2.34-3-dev-osx-x86_64-en-US.zip to 23M /tmp/TorBrowser-7z-wrap2.2.34-3-dev-osx-x86_64-en-US.zip Probably it would require some better cleanup and integration, that's just a working poc. -naif

1 0

routers as bridges
by Rob van der Hoeven 06 Dec '11

06 Dec '11

In July i posted a message on this list proposing to use a router as a Tor bridge. Recently i liberated one of my routers with OpenWrt which made it possible to test this idea. Seems to work. Wrote a small article about it on my blog: http://freedomboxblog.nl/routers-as-tor-bridges/ Cheers, Rob. http://freedomboxblog.nl

1 0

Automatically retrieve and store information about bridges
by Sebastian Hahn 01 Dec '11

01 Dec '11

Filename: xxx-store-bridge-information.txt Title: Automatically retrieve and store information about bridges Author: Sebastian Hahn Created: 16-Nov-2011 Status: Open Target: 0.2.[45].x Overview: Currently, tor already stores some information about the bridges it is configured to use locally, but doesn't make great use of the stored data. This data is the Tor configuration information about the bridge (IP address, port, and optionally fingerprint) and the bridge descriptor which gets stored along with the other descriptors a Tor client fetches, as well as an "EntryGuard" line in the state file. That line includes the Tor version we used to add the bridge, and a slightly randomized timestamp (up to a month in the past of the real date). The descriptor data also includes some more accurate timestamps about when the descriptor was fetched. The information we give out about bridges via bridgedb currently only includes the IP address and port, because giving out the fingerprint as well might mean that Tor clients make direct connections to the bridge authority, since we didn't design Tor's UpdateBridgesFromAuthority behaviour correctly. Motivation: The only way to let Tor know about a change affecting the bridge (IP address or port change) is to either ask the bridge authority directly, or reconfigure Tor. The former requires making a non-anonymized direct connection to the bridge authority Tonga and asking it for the current descriptor of the bridge with a given fingerprint - this is unsafe and also requires prior knowledge of the fingerprint. The latter requires user intervention, first to learn that there was an update and second to actually teach Tor about the change. This is way too complicated for most users, and should be unnecessary while the user has at least one bridge that remains working: Tonga can give out bridge descriptors when asked for the descriptor for a certain fingerprint, and Tor clients learn the fingerprint either from their torrc file or from the first connection they make to a bridge. For some users, however, this option is not what they want: They might use private bridges or have special security concerns, which would make them want to connect to the IP addresses specified in their configuration only, and not tell Tonga about the set of bridges they know about, even through a Tor circuit. Also see https://blog.torproject.org/blog/different-ways-use-bridge for more information about the different types of bridge users. Design: Tor should provide a new configuration option that allows bridge users to indicate that they wish to contact Tonga anonymously and learn about updates for the bridges that they know about, but can't currently reach. Once those updates have been received, the clients would then hold on to the new information in their state file, and use it across restarts for connection attempts. The option UpdateBridgesFromAuthority should be removed or recycled for this purpose, as it is currently dangerous to set (it makes direct connections to the bridge authority, thus leaking that a user is about to use bridges). Recycling the option is probably the better choice, because current users of the option get a surprising and never useful behaviour. On the other hand, users who downgrade their Tors might get the old behaviour by accident. If configured with this option, tor would make an anonymized connection to Tonga to ask for the descriptors of bridges that it cannot currently connect to, once every few hours. Making more frequent requests would likely not help, as bridge information doesn't typically change that frequently, and may overload Tonga. This information needs to be stored in the state file: - An exact copy of the Bridge stanza in the torrc file, so that tor can detect when the bridge is unconfigured/the configuration is changed - The IP address, port, and fingerprint we last used when making a successful connection to the bridge, if this differs from/supplements the configured data. - The IP address, port, and fingerprint we learned from the bridge authority, if this differs from both the configured data and the data we used for the last successful connection. We don't store more data in the state file to avoid leaking too much if the state file falls into the hands of an adversary. Security implications: Storing sensitive data on disk is risky when the computer one uses gets into the wrong hands, and state file entries can be used to identify times the user was online. This is already a problem for the Bridge lines in a user's configuration file, but by storing more information about bridges some timings can be deduced. Another risk is that this allows long-term tracking of users when the set of bridges a user knows about is known to the attacker, and the set is unique. This is not very hard to achieve for bridgedb, as users typically make requests to it non-anomymized and bridgedb can selectively pick bridges to report. By combining the data about descriptor fetches on Tonga and this fingerprint, a usage pattern can be established. Also, bridgedb could give out a made-up fingerprint to a user that requested bridges, thus easily creating a unique set. Users of private bridges should not set this option, as it will leak the fingerprints of their bridges to Tonga. This is not a huge concern, as Tonga doesn't know about those descriptors, but private bridge users will likely want to avoid leaking the existence of their bridge. We might want to figure out a way to indicate that a bridge is private on the Bridge line in the configuration, so fetching the descriptor from Tonga is disabled for those automatically. This warrants more discussion to find a solution that doesn't require bridge users to understand the trade-offs of setting a configuration option. One idea is to indicate that a bridge is private by a special flag in its bridge descriptor, so clients can avoid leaking those to the bridge authority automatically. Also, Bridge lines for private bridges shouldn't include the fingerprint so that users don't accidentally leak the fingerprint to the bridge authority before they have talked to the bridge. Specification: No change/addition to the current specification is necessary, as the data that gets stored at clients is not covered by the specification. This document is supposed to serve as a basis for discussion and to provide hints for implementors. Compatibility: Tonga is already set up to send out descriptors requested by clients, so the bridge authority side doesn't need any changes. The new configuration options governing the behaviour of Tor would be incompatible with previous versions, so the torrc needs to be adapted. The state file changes should not affect older versions.

2 1

Proposal: Bridge Detection Resistance against MITM-capable Adversaries
by George Kadianakis 01 Dec '11

01 Dec '11

Filename: XXX-mitm-bridge-detection-resistance.txt Title: Bridge Detection Resistance against MITM-capable Adversaries Author: George Kadianakis Created: 07 Nov 2011 Status: Open 1. Overview Proposals 187, 189 and 190 make the first steps toward scanning resistant bridges. They attempt to block attacks from censoring adversaries who provoke bridges into speaking the Tor protocol. An attack vector that hasn't been explored in those previous proposals is that of an adversary capable of performing Man In The Middle attacks to Tor clients. At the moment, Tor clients using the v3 link protocol have no way to detect such an MITM attack, and will gladly send an VERSIONS or an AUTHORIZE cell to the MITMed connection, thereby revealing the Tor protocol and thus the bridge. This proposal introduces a way for clients to detect an MITMed SSL connection, allowing them to protect against the above attack. 2. Motivation When the v3 link handshake protocol is performed, Tor's SSL handshake is performed with the server sending a self-signed certificate and the client blindly accepting it. This allows the adversary to perform an MITM attack. A Tor client must detect the MITM attack before he initializes the Tor protocol by sending a VERSIONS or an AUTHORIZE cell. A good moment to detect such an MITM attack is during the SSL handshake. To achieve that, bridge operators provide their bridge users with a hash digest of the public-key certificate their bridge is using for SSL. Bridge clients store that hash digest locally and associate it with that specific bridge. Bridge clients who have "pinned" a bridge to a certificate "fingerprint" can thereafter validate that their SSL connection peer is the intended bridge. Of course, the hash digest must be provided to users out-of-band and before the actual SSL handshake. Usually, the bridge operator gives the hash digest to her bridge users along with the rest of the bridge credentials, like the bridge's address and port. 3. Security implications Bridge clients who have pinned a bridge to a certificate fingerprint will be able to detect an MITMing adversary in timely fashion. If after detection they act as an innocuous Internet client, they can successfully remove suspicion from the SSL connection and subvert bridge detection. Pinning a certificate fingerprint and detecting an MITMing attacker does not automatically aleviate suspicions from the bridge or the client. Clients must have a behavior to follow after detecting the MITM attack so that they look like innocent Netizens. This proposal does not try to specify such a behavior. Implementation and use of this scheme does not render bridges and clients immune to scanning or DPI attacks. This scheme should be used along with bridge client authorization schemes like the ones detailed in proposal 190. 4. Tor Implementation 4.1. Certificate fingerprint creation The certificate fingerprints used on this scheme MUST be computed by applying the SHA256 cryptographic hash function upon the ASN.1 DER encoding of a public-key certificate. 4.2. Bridge side implementation Tor bridge implementations SHOULD provide a command line option that exports a fully equipped Bridge line containing the bridge address and port, the link certificate fingerprint and any other enabled Bridge options, so that bridge operators can easily send it to their users. In the case of expiring SSL certificates, Tor bridge implementations SHOULD warn the bridge operator a sensible amount of time before the expiration, so that she can warn her clients and potentially rotate the certificate herself. 4.3. Client side implementation Tor client implementations MUST extend their Bridge line format to support bridge SSL certificate fingerprints. The new format is: Bridge <method> <address:port> [["keyid="]<id-fingerprint>] \ ["shared_secret="<shared_secret>] ["link_cert_fpr="<fingerprint>] where <fingerprint> is the bridge's SSL certificate fingerprint in hexademical encoding. Tor clients who use bridges and want to pin their SSL certificates must specify the bridge's SSL certificate fingerprint as in: Bridge 12.34.56.78 shared_secret=934caff420aa7852b855 \ link_cert_fpr=38b0712e90bed729df81f2a22811d3dd89e91406d2522f4482ae4079e5245187 4.4. Implementation prerequisites Tor bridges currently rotate their SSL certificates every 2 hours. This not only acts as a fingerprint for the bridges, but it also acts as a blocker for this proposal. Tor trac ticket #4390 and proposal YYY were created to resolve this issue. 5. Acknowledgements Thanks to Robert Ransom for his great help and suggestions on devising this scheme and writing this proposal!

5 6

Sanitizing and publishing our web server logs
by Karsten Loesing 01 Dec '11

01 Dec '11

Hi everyone, we have been discussing sanitizing and publishing our web server logs for quite a while now. The idea is to remove all potentially sensitive parts from the logs, publish them in monthly tarballs on the metrics website, and analyze them for top visited pages, top downloaded packages, etc. See the tickets #1641 and #2489 for details. Here's a suggested sanitizing procedure for our web logs, which are in Apache's combined log format: - Ignore everything except GET requests. - Ignore all requests that resulted in a 404 status code. - Rewrite log lines so that they only contain the following fields: - IP address 0.0.0.0 for HTTP request or 0.0.0.1 for HTTPS requests (as logged by our Apache configuration), - the request date (with the time part set to 00:00:00), - the requested URL (cut off at the first encountered "?"), - the HTTP version, - the server's HTTP status code, and - the size of the returned object. - Write all lines from a given virtual host and day to a single output file. - Sort the output file alphanumerically to conceal the original order of requests. Here's a sample sanitized log file for www.torproject.org from May 1, 2009 (462K): http://freehaven.net/~karsten/volatile/www.torproject.org-access.log-200905… Is there still anything sensitive in that log file that we should remove? For example: - Do the logs reveal how many pages were cached already on the requestor's site (e.g. as repeat accesses)? Note that log files are sorted before being published. - Are there other concerns about making these sanitized log files publicly available? Are the decisions to remove parts from the logs reasonable? In particular: - Do we have to take out all requests with 404 status codes? Some of these requests for non-existing URLs contain typos which may not be safe to make public. Should we instead put in some placeholder for the URL part and keep the 404 lines to know how many 404's we have per day? - Is there any good reason to keep the portion of a URL after a "?"? - Is it possible to leave some part of Referers in the logs that helps us figure out where our traffic originates and what search terms people use to find us? - Can we resolve client IP addresses to country codes and include those in the logs instead of our 0.0.0.0/0.0.0.1 code for HTTP/HTTPS? How would we handle countries with only a few users per day, e.g., should there be a threshold below which we consider requests to come from "a country with less than XY users?" Thanks, Karsten

6 10

Failed test in UNICODE
by Gisle Vanem 30 Nov '11

30 Nov '11

I just built Tor and the test suite with UNICODE enabled (MS Visual-C v16 on Win-XP SP3). With some patching, the test-programs compiled and ran mostly fine. Except test_util_spawn_background_ok() failed for a reason I did't understand initially: > test --warn util/spawn_background_ok: Nov 23 14:35:55.531 [warn] Failed to create child process test-child.exe: Systemet finner ikke angitt fil. FAIL test_util.c:1405: assert(process_handle.status == expected_status): -1 vs 1 [spawn_background_ok FAILED] util/spawn_background_partial_read: Nov 23 14:35:55.546 [warn] Failed to create child process test-child.exe: Systemet finner ikke angitt fil. FAIL test_util.c:1521: assert(process_handle.status == expected_status): -1 vs 1 [spawn_background_partial_read FAILED] ("Systemet finner ikke angitt fil" -> "System doesn't find specified file"). I think the reason is that CreateProcessW() is used in common/util.c. The function is passed a 'const char *const filename'. Either we should always use CreateProcessA() or convert 'filename' using mbstowcs(). What do you think? --gv

2 1

Periodic alert to outdated Tor operators?
by Fabio Pietrosanti (naif) 30 Nov '11

30 Nov '11

Hi all, should we send a periodic email reminder to all operators running outdated Tor routers? >From a brief look at cached-descriptors: grep 'Tor 0\.2\.0' /var/lib/tor/cached-descriptors | wc -l 111 grep 'Tor 0\.2\.1' /var/lib/tor/cached-descriptors | wc -l 5631 grep 'Tor 0\.2\.2' /var/lib/tor/cached-descriptors | wc -l 11572 grep 'Tor 0\.2\.3' /var/lib/tor/cached-descriptors | wc -l 1182 It would be nice to have an automatic system that spam periodically all Tor operators that run outdated Tor routers. -naif

3 2

Re: [tor-dev] Proposal 178: Require majority of authorities to vote for consensus parameters
by Nick Mathewson 27 Nov '11

27 Nov '11

On Tue, Feb 22, 2011 at 1:34 AM, Sebastian Hahn <hahn.seb(a)web.de> wrote: > Design: > > When the consensus is generated, the directory authorities ensure that > a param is only included in the list of params if at least half of the > total number of authorities votes for that param. The value chosen is > the low-median of all the votes. We don't mandate that the authorities > have to vote on exactly the same value for it to be included because > some consensus parameters could be the result of active measurements > that individual authorities make. This is possibly bikeshed, but I would suggest that instead of requiring half of existing authorities to vote on a particular parameter, we require 3 or more to vote on it. (As a degenerate case, fall back to "at least half" if there are fewer than 6 authorities in the clique.) I think we don't want the number to be _less_ than 3, since 3 is the smallest number of parties who can come up with a low-median that isn't just the diktat of a single member (1 party), or as low as either member wants it to be (2 parties). yrs, -- Nick

2 7

Bug triage status
by Nick Mathewson 24 Nov '11

24 Nov '11

Hi, Roger! As discussed, I did some Tor bug triage tonight. Here's what I did: * I made a new "Tor: very long term" (formerly "Tor: distant future") milestone for stuff too long-term to be in "Tor: unspecified." Now we will no longer have "unspecified" mean "maybe never" to some of us and "I honestly don't know" to others. * I made a new "tor: 0.2.4.x" milestone * I went through every ticket in "post 0.2.3.x" (there were like 3 or 4) and reassigned them someplace better. * I went through every ticket without a component. * I went through every ticket in Tor: unspecified to see if it belonged there. Surprisingly, very few of them belonged in "Tor: very long term". * I went through every ticket without a milestone that was assigned to one of the core Tor components (that is, Tor Bridge, Tor Hidden Service, Tor Directory Authority, Tor Client, Tor Relay). Now they all have milestones; some few of them also have comments, or are closed. Still to do, possibly by me, possibly not: * Triage all 233 open 0.2.3.x tickets. The ones that are feature-like, big, and not planned to get done by nov 30 should get punted to "unspecified" or 0.2.4.x or "very long term." The ones that are feature-like and small should get ordinary triage. The ones that are bugs should get priorities assigned, or marked as deferrable, or such. * Triage all 23 open 0.2.2.x-final tickets. Some of these are bugs that we believe *should* have their fixes applied on 0.2.2; some are merely bugs that *exist* in 0.2.2, but which might not be important enough to alter a stable release. * Triage all core-Tor bugs in a milestone other than 0.2.2.x-final, 0.2.3.x-final, 0.2.4.x-final, unspecified, or very long term. Next steps for Roger here: * Go over the "Unspecified" stuff I've triaged to see if you agree. It should be cleaner than it was before, happy Thanksgiving, -- Nick

1 0

Re: [tor-dev] Tor glossary
by Shondoit 23 Nov '11

23 Nov '11

During translating last week it occurred to me that we do not have a consistent translation for some common phrases. I've set up a first draft of all common words that are used throughout the various Tor projects. Why I'm sending this to tor-dev is the following: - You as developers know which phrases are important for a clear communication of Tor's (and others) workings. I would very much like if you can add to the lists the words that are essential to be consistently translated. (as of writing this, I know I forgot to add 'Introduction Point') - Sometimes different phrases are used throughout the applications. Sometimes it's called an 'exit node' other times it's an 'exit relay'. It would benefit consistency when devs use the glossary for common terms. - Translators sometimes don't know the definition of words, or the context changes. A directory in the Tor context is different from a directory in an OS context. I'm not sure what the best way is to go about doing this, but we need definitions. The last version of the list can be found in my github: https://github.com/Shondoit/torglossary If you have additions to the list, definitions, suggestions, you can either email or clone/fork the repo and add it yourself. Thanks in advance

1 0

Re: [tor-dev] Regarding Metrics project
by Karsten Loesing 17 Nov '11

17 Nov '11

Hi Qiang, I'm cc'ing tor-dev, because I think your original request to work on Java codebases went there. On 11/17/11 2:13 AM, Qiang Wang wrote: > This is Qiang, and I am very interested in Tor project, and want to > contribute something. I was wondering if I can provide any help about > metrics project? > > Could you please let me know your recommendations? Sure thing. Three ideas come to mind: - Improve the consensus-health script: We have a Java program that downloads the network statuses from all eight directory authorities and compares them to each other to detect problems. One of the outputs is a web page [0], another output is a status email [1], and a third is a message sent to an IRC bot [2]. The code [3] needs some love. - Answer the question what fraction of exit relays exit from a different IP than is in their descriptor. This is a typical question that can be answered using the metrics data [4] we have. We'd want to publish the analysis code in the metrics-tasks repository [5], so that others can reproduce the results or refine the analysis. There's already a lot of Java code in that repository, because that's what I use when analyzing metrics data. We have plenty of other analysis questions similar to this one, so if you don't like this one, take a look at the Analysis component in our bug tracker [6]. - Implement an efficient relay-search database. We have a web site for searching relays by IP, nickname, or fingerprint [7], but it's really slow. The main problem is that the database originally was designed for aggregating statistics about relays, not for searching relays. I have two ideas here: The first is to design a separate PostgreSQL database [8] and go crazy with indexes, the second is to try out CouchDB for this [9]. This task isn't really that Java-specific, except for the fact that I'm using Java to import data and send queries. If anything sounds interesting to you, please let me know. I have more information about these tasks and can help you get started. Also look at the research section of the metrics website [10] to learn more. Best, Karsten [0] https://metrics.torproject.org/consensus-health.html [1] https://lists.torproject.org/pipermail/tor-consensus-health/2011-November/0… [2] See the IRC bot nsa in #tor-bots on OFTC, e.g., "< nsa> or: [consensus-health] The following directory authorities set conflicting or invalid consensus parameters: ides bwauthbestratio=1 bwauthcircs=0 bwauthdescbw=1 bwauthkp=10000 bwauthpid=1 bwauthtd=0 bwauthti=0 bwauthtidecay=5000 cbtnummodes=3 refuseunknownexits=1" [3] https://gitweb.torproject.org/metrics-web.git/tree/HEAD:/src/org/torproject… [4] https://metrics.torproject.org/data.html [5] https://gitweb.torproject.org/metrics-tasks.git [6] https://trac.torproject.org/projects/tor/query?status=!closed&component=Ana… [7] https://metrics.torproject.org/relay-search.html [8] https://trac.torproject.org/projects/tor/ticket/2922 [9] https://trac.torproject.org/projects/tor/ticket/4440 [10] https://metrics.torproject.org/research.html

1 0

About JTor project
by Qiang Wang 17 Nov '11

17 Nov '11

Hello there, I am very interested in Tor project, and I want to contribute something to it. In particular, I'd like to work on JTor. Could anyone tell me whom I can contact with for further information regarding getting involved in? -- Thanks & best regards Qiang Wang

2 2

What Should Tor Bridges and Clients Do When They Get Hosed?
by George Kadianakis 12 Nov '11

12 Nov '11

This is not a proposal. So, since some people in this list, who are not in IRC, seemed interested in censorship resistance, I pose this new question: What should Tor bridges and clients do when they hosed in previous schemes? All those previous proposals dealed with ways to detect fingerprinting adversaries, but not with ways to persuade them that what they are seeing is not Tor. There should be a proposal specifying exactly that, and this is a discussion thread (even monologue can be considered a discussion). Let's start with a quick threat model: --- We consider a nation-state adversary who: a) has a list of hosts suspected to be Tor bridges and wants to block them without suffering huge false positives. OR b) sails the Internet to find Tor bridges. The adversary is controlling the state's Internet infrastructure and can inject, modify or block incoming or outgoing traffic. He can build software that speaks and understands network protocols but he cannot deploy humans to do the necessary testing. To complete his goals, the adversary can directly probe hosts to see what protocol they speak, OR he can MITM all connections towards those hosts to see what protocol their clients speak. --- tl;dr we are dealing with MITMs and direct probes here. Naturally, it would be cool if we could just say "Oh right, all bridges and clients speak HTTPS in case of detection; all is cool", but remember that HTTPS is quite hard to spoof right, both in the server and in the client case [1], especially when it has to be done in C and in the tor.git codebase. Ideally, we would want to be as application-layer-neutral [2] as possible, and with the minimum implementation cost possible. So let's handle client and bridge cases separately and have a go. Clients: Proposal 191 allows clients to detect MITM attempts during the SSL handshake, this is good because we don't have to pretend speaking a specific application layer protocol. I think a good solution would be to send an SSL Alert of "Bad Certificate" type and close the connection when clients detect an SSL MITM attempt. That's what Firefox does when a user selects "Get Me Out Of Here!" on the self-signed certificate dialog, and that's what all applications should do (?) when an MITM attack is detected either by certificate or public-key pinning. In the future we might also want to send innocuous HTTP queries like GETting index.html, but we have to be aware of [1]. Bridges: Bridges have it harder. Proposal 187, allows bridges to detect probing attempts after the SSL handshake, when the probing client sends any sort of packet or a badly formed AUTHORIZE cell. This forces bridges to respond with an application-layer-specific message (or close the connection, but that would be rude). This is where I'm not sure what should be done. I think all implementations MUST provide a way for the bridge operator to configure a network service of his own (FTPS, HTTPS, SMTPS, etc.) and have the bridge send all the adversary traffic to that service. That should do it for technical bridge operators, but there probably should also be something on by default, for bridge operators who don't know how to setup net services on their own. The easy choice is an "HTTPS" server with the default Apache "It Works!", or a closed basic access authentication, but really implementing a spoofed HTTPS server in tor will be a PITA, because censors can easily test us by provoking one of [0] (there is a reason that HTTP servers usually require lots of LoCs to work). Maybe we should ship a configured Apache server with the long-term future "Anti-censorship Tor Bundle"? Also, what happens to Tor on Linux when it can't listen on port 443? Or when port 443 is already taken? HTTPS servers on 9001 sure look sketchy. Any ideas are welcome. Any services widely used, frequently seen with SSL support, that handle traffic that kinda looks like Tor's and are easily implementable, are also welcome. [0]: https://en.wikipedia.org/wiki/List_of_HTTP_status_codes [1]: https://en.wikipedia.org/wiki/List_of_HTTP_header_fields https://trac.torproject.org/projects/tor/ticket/2907 [2]: Let's place SSL on the transport layer for now.

2 1

[Patch] test_util.c
by Gisle Vanem 12 Nov '11

12 Nov '11

Those '{}' constructs are not well liked by MSVC (cl v.16.xx). An easy fix: diff --git a/src/test/test_util.c b/src/test/test_util.c index 2146299..64bf52e 100644 --- a/src/test/test_util.c +++ b/src/test/test_util.c @@ -1597,7 +1597,7 @@ test_util_join_win_cmdline(void *ptr) {"a\\\\\\b", "de fg", "H", NULL}, // Backslashes {"a\\\"b", "\\c", "D\\", NULL}, // Backslashes before quote {"a\\\\b c", "d", "E", NULL}, // Backslashes not before quote - {} // Terminator + { NULL } // Terminator }; const char *cmdlines[] = { @@ -1649,7 +1649,7 @@ test_util_split_lines(void *ptr) {"\n\rfoo\n\rbar\r\n", 12, {"foo", "bar", NULL}}, {"fo o\r\nb\tar", 10, {"fo o", "b.ar", NULL}}, {"\x0f""f\0o\0\n\x01""b\0r\0\r", 12, {".f.o.", ".b.r.", NULL}}, - {NULL, 0, {}} + {NULL, 0, { NULL }} }; int i, j; --gv

2 1

[Patch] or/eventdns.c
by Gisle Vanem 09 Nov '11

09 Nov '11

I've made eventdns.c + '-DEVDNS_MAIN' compile and work under Windows / MSVC. Some simple patches: * Use set_socket_nonblocking() instead of the F_SETFL hacks. * Preserve the ret-val from evdns_config_windows_nameservers(). * In main(), call network_init() to call WSAStartup() etc. * Removed 'evdns_resolv_conf_parse(DNS_OPTION_NAMESERVERS, ...' and call evdns_init() instead. This uses 'DNS_OPTIONS_ALL'. Does that really matter? Attached diff-1.txt. (sorry, I'm a Git neophyte). --gv

2 2

SHA-3 isn't looking so hot to me
by Markku-Juhani O. Saarinen 04 Nov '11

04 Nov '11

Watson Ladd: > (HMAC is a bad idea anyway: quadratic security bounds are not the best > possible, we have to use nonces anyway to prevent replay attacks, so > Wegman-Carter is a better idea for better in{faster, more secure}. GCM > would be an example of this.) GCM has quadratic security bounds, not only in the proof but in practice too. Furthermore a 128-bit GCM MAC offers much less than 128-bit security; in this sense it is certainly weaker than, say, MD5-HMAC ! And there are the implementation caveats mentioned already mentioned in the list, including Joux's "forbidden attack" which may indeed be very real in many implementations. GCM also tends to be slow on software. I've been told that GCM was pushed through the NIST standardization process mainly by CISCO who were concerned about the performance of their hardware crypto accelerators (many hash functions are tricky to implement on hardware). There's also the issue of weak keys etc. See http://eprint.iacr.org/2011/202.pdf This came out in ECRYPT II Hash Workshop 2011, 19-20 May 2011, Tallinn, Estonia. The current ECRYPT recommendations take this into account, see section 8.5.5 of "ECRYPT II Yearly Report on Algorithms and Keysizes (2010-2011)" for a brief discussion: http://www.ecrypt.eu.org/documents/D.SPA.17.pdf I should be expanding this work as Niels Ferguson noted in the Redmond Crypto Retreat workshop last August that there's a trivial extension of this attack that allows arbitrary message modification. Also a significantly faster method for identifying weak AES-GCM keys has been discovered. As a hash function researcher I would personally select SHA-512 with digest truncated to required number of bits as an interim solution. SHA-512/256 tends to be faster than SHA-256 in software. Also it makes sense to implement a single hash core rather than two (SHA-256 and SHA-512 are fundamentally different). This is also in the standards, see: http://csrc.nist.gov/publications/drafts/fips180-4/Draft-FIPS180-4_Feb2011.… Cheers, - markku Dr. Markku-Juhani O. Saarinen <mjos(a)reveresecurity.com>

8 8

Subject: Re: The consequences of key compromise (or the reasons for changing)
by Markku-Juhani O. Saarinen 04 Nov '11

04 Nov '11

From: Jon Callas <joncallas(a)me.com> > People should get off of 80-bit crypto as soon as is reasonably possible. This means RSA 1024, SHA-1, etc. NIST recommended doing this by the end of 2010, but are now holding their nose and saying that 2013 is the real new date. Absolutely agree. The 80-bit figure was apparently adopted by U.S. Government some 25+ years ago (skipjack etc). > This seems basically reasonable to me. No one has yet factored a 768-bit number, let alone a 1K one. 768-bit RSA was factored in 2009 and the authors of that paper conjecture that 1024 bits would be factored "within a decade" and recommend that 1024-bit RSA should be phased out within a couple of years. http://eprint.iacr.org/2010/006.pdf I am certainly doing that with the stuff that I am maintaining. > SHA-1 actually looks safer today than it did in 2005. But still. Moving away is a Good Thing, so long as it doesn't make you do something stupid. Well, after the 2005 Wang-Yin-Yu paper which had a 2^69 attack, there was a claimed 2^52 attack in 2009 which turned out to have a flawed cost evaluation. There has also been talk of a 2^63 attack, but that difference can be put down to attack implementation skill and detail. I was always doubtful whether or not those techniques could be expanded to work against the SHA-2 algorithms. It is also funny that many people talk about SHA-2 as if was a single algorithm; there are actually two quite distinct algorithms, one for (now fading) 32-bit architectures (SHA-224,SHA-256) and one for 64-bit algorithms (SHA-384,SHA-512,SHA-512/224,SHA-512/256). The variants of these two algorithms only differ in the number of output bits and the IV values and hence have a constant speed regardless of their digest size. You can run "openssl speed sha" to see a real-world performance comparison on a particular box. Cheers, - markku Dr. Markku-Juhani O. Saarinen <mjos(a)reveresecurity.com>

2 1