Tor 0.3.0.1-alpha: A new alpha series begins

by nickm | December 19, 2016

Now that Tor 0.2.9.8 is stable, it's time to release a new alpha series for testing and bug-hunting!
Tor 0.3.0.1-alpha is the first alpha release in the 0.3.0 development series. It strengthens Tor's link and circuit handshakes by identifying relays by their Ed25519 keys, improves the algorithm that clients use to choose and maintain their list of guards, and includes additional backend support for the next-generation hidden service design. It also contains numerous other small features and improvements to security, correctness, and performance.
You can download the source from the usual place on the website. Packages should be available over the next weeks, including an alpha TorBrowser release some time in January.
Please note: This is an alpha release. Please expect more bugs than usual. If you want a stable experience, please stick to the stable releases.

Below are the changes since 0.2.9.8.

Changes in version 0.3.0.1-alpha - 2016-12-19

  • Major features (guard selection algorithm):
    • Tor's guard selection algorithm has been redesigned from the ground up, to better support unreliable networks and restrictive sets of entry nodes, and to better resist guard-capture attacks by hostile local networks. Implements proposal 271; closes ticket 19877.
  • Major features (next-generation hidden services):
    • Relays can now handle v3 ESTABLISH_INTRO cells as specified by prop224 aka "Next Generation Hidden Services". Service and clients don't use this functionality yet. Closes ticket 19043. Based on initial code by Alec Heifetz.
    • Relays now support the HSDir version 3 protocol, so that they can can store and serve v3 descriptors. This is part of the next- generation onion service work detailled in proposal 224. Closes ticket 17238.
  • Major features (protocol, ed25519 identity keys):
    • Relays now use Ed25519 to prove their Ed25519 identities and to one another, and to clients. This algorithm is faster and more secure than the RSA-based handshake we've been doing until now. Implements the second big part of proposal 220; Closes ticket 15055.
    • Clients now support including Ed25519 identity keys in the EXTEND2 cells they generate. By default, this is controlled by a consensus parameter, currently disabled. You can turn this feature on for testing by setting ExtendByEd25519ID in your configuration. This might make your traffic appear different than the traffic generated by other users, however. Implements part of ticket 15056; part of proposal 220.
    • Relays now understand requests to extend to other relays by their Ed25519 identity keys. When an Ed25519 identity key is included in an EXTEND2 cell, the relay will only extend the circuit if the other relay can prove ownership of that identity. Implements part of ticket 15056; part of proposal 220.

 

  • Major bugfixes (scheduler):
    • Actually compare circuit policies in ewma_cmp_cmux(). This bug caused the channel scheduler to behave more or less randomly, rather than preferring channels with higher-priority circuits. Fixes bug 20459; bugfix on 0.2.6.2-alpha.
  • Minor features (controller):
    • When HSFETCH arguments cannot be parsed, say "Invalid argument" rather than "unrecognized." Closes ticket 20389; patch from Ivan Markin.
  • Minor features (diagnostic, directory client):
    • Warn when we find an unexpected inconsistency in directory download status objects. Prevents some negative consequences of bug 20593.
  • Minor features (directory authority):
    • Add a new authority-only AuthDirTestEd25519LinkKeys option (on by default) to control whether authorities should try to probe relays by their Ed25519 link keys. This option will go away in a few releases--unless we encounter major trouble in our ed25519 link protocol rollout, in which case it will serve as a safety option.
  • Minor features (directory cache):
    • Relays and bridges will now refuse to serve the consensus they have if they know it is too old for a client to use. Closes ticket 20511.
  • Minor features (ed25519 link handshake):
    • Advertise support for the ed25519 link handshake using the subprotocol-versions mechanism, so that clients can tell which relays can identity themselves by Ed25519 ID. Closes ticket 20552.
  • Minor features (fingerprinting resistence, authentication):
    • Extend the length of RSA keys used for TLS link authentication to 2048 bits. (These weren't used for forward secrecy; for forward secrecy, we used P256.) Closes ticket 13752.
  • Minor features (infrastructure):
    • Implement smartlist_add_strdup() function. Replaces the use of smartlist_add(sl, tor_strdup(str)). Closes ticket 20048.
  • Minor bugfixes (client):
    • When clients that use bridges start up with a cached consensus on disk, they were ignoring it and downloading a new one. Now they use the cached one. Fixes bug 20269; bugfix on 0.2.3.12-alpha.
  • Minor bugfixes (configuration):
    • Accept non-space whitespace characters after the severity level in the `Log` option. Fixes bug 19965; bugfix on 0.2.1.1-alpha.
    • Support "TByte" and "TBytes" units in options given in bytes. "TB", "terabyte(s)", "TBit(s)" and "terabit(s)" were already supported. Fixes bug 20622; bugfix on 0.2.0.14-alpha.
  • Minor bugfixes (consensus weight):
    • Add new consensus method that initializes bw weights to 1 instead of 0. This prevents a zero weight from making it all the way to the end (happens in small testing networks) and causing an error. Fixes bug 14881; bugfix on 0.2.2.17-alpha.
  • Minor bugfixes (descriptors):
    • Correctly recognise downloaded full descriptors as valid, even when using microdescriptors as circuits. This affects clients with FetchUselessDescriptors set, and may affect directory authorities. Fixes bug 20839; bugfix on 0.2.3.2-alpha.
  • Minor bugfixes (directory system):
    • Download all consensus flavors, descriptors, and authority certificates when FetchUselessDescriptors is set, regardless of whether tor is a directory cache or not. Fixes bug 20667; bugfix on all recent tor versions.
    • Bridges and relays now use microdescriptors (like clients do) rather than old-style router descriptors. Now bridges will blend in with clients in terms of the circuits they build. Fixes bug 6769; bugfix on 0.2.3.2-alpha.
  • Minor bugfixes (ed25519 certificates):
    • Correctly interpret ed25519 certificates that would expire some time after 19 Jan 2038. Fixes bug 20027; bugfix on 0.2.7.2-alpha.
  • Minor bugfixes (hidden services):
    • Stop ignoring misconfigured hidden services. Instead, refuse to start tor until the misconfigurations have been corrected. Fixes bug 20559; bugfix on multiple commits in 0.2.7.1-alpha and earlier.
  • Minor bugfixes (memory leak at exit):
    • Fix a small harmless memory leak at exit of the previously unused RSA->Ed identity cross-certificate. Fixes bug 17779; bugfix on 0.2.7.2-alpha.
  • Minor bugfixes (util):
    • When finishing writing a file to disk, if we were about to replace the file with the temporary file created before and we fail to replace it, remove the temporary file so it doesn't stay on disk. Fixes bug 20646; bugfix on tor-0.2.0.7-alpha. Patch by fk.
  • Minor bugfixes (Windows):
    • Check for getpagesize before using it to mmap files. This fixes compilation in some MinGW environments. Fixes bug 20530; bugfix on 0.1.2.1-alpha. Reported by "ice".
  • Code simplification and refactoring:
    • Abolish all global guard context in entrynodes.c; replace with new guard_selection_t structure as preparation for proposal 271. Closes ticket 19858.
    • Introduce rend_service_is_ephemeral() that tells if given onion service is ephemeral. Replace unclear NULL-checkings for service directory with this function. Closes ticket 20526.
    • Extract magic numbers in circuituse.c into defined variables.
    • Refactor circuit_is_available_for_use to remove unnecessary check.
    • Refactor circuit_predict_and_launch_new for readability and testability. Closes ticket 18873.
    • Refactor large if statement in purpose_needs_anonymity to use switch statement instead. Closes part of ticket 20077.
    • Refactor the hashing API to return negative values for errors, as is done as throughout the codebase. Closes ticket 20717.
    • Remove data structures that were used to index or_connection objects by their RSA identity digests. These structures are fully redundant with the similar structures used in the channel abstraction.
    • Remove duplicate code in the channel_write_*cell() functions. Closes ticket 13827; patch from Pingl.
    • Remove redundant behavior of is_sensitive_dir_purpose, refactor to use only purpose_needs_anonymity. Closes part of ticket 20077.
    • The code to generate and parse EXTEND and EXTEND2 cells has been replaced with code automatically generated by the "trunnel" utility.
  • Documentation:
    • Include the "TBits" unit in Tor's man page. Fixes part of bug 20622; bugfix on tor-0.2.5.1-alpha.
    • Change '1' to 'weight_scale' in consensus bw weights calculation comments, as that is reality. Closes ticket 20273. Patch from pastly.
    • Correct the value for AuthDirGuardBWGuarantee in the manpage, from 250 KBytes to 2 MBytes. Fixes bug 20435; bugfix on tor-0.2.5.6-alpha.
    • Stop the man page from incorrectly stating that HiddenServiceDir must already exist. Fixes 20486.
    • Clarify that when ClientRejectInternalAddresses is enabled (which is the default), multicast DNS hostnames for machines on the local network (of the form *.local) are also rejected. Closes ticket 17070.
  • Removed features:
    • The AuthDirMaxServersPerAuthAddr option no longer exists: The same limit for relays running on a single IP applies to authority IP addresses as well as to non-authority IP addresses. Closes ticket 20960.
    • The UseDirectoryGuards torrc option no longer exists: all users that use entry guards will also use directory guards. Related to proposal 271; implements part of ticket 20831.
  • Testing:
    • New unit tests for tor_htonll(). Closes ticket 19563. Patch from "overcaffeinated".
    • Perform the coding style checks when running the tests and fail when coding style violations are found. Closes ticket 5500.
    • Add tests for networkstatus_compute_bw_weights_v10.
    • Add unit tests circuit_predict_and_launch_new.
    • Extract dummy_origin_circuit_new so it can be used by other test functions.

Comments

Please note that the comment area below has been archived.

Anonymous (not verified) said:

December 20, 2016

Permalink

Tor will not load for me at all since the update. Nothing will load. Is anyone else having this issue?

Anonymous (not verified) said:

December 21, 2016

Permalink

Just built Tor 0.3.0.1-alpha or 'thought I did', as the download from the torproject.org tor source site provided the file with that name. I built it and then noticed when I asked what version it is as I suspected something was not right, it told me $ tor --version
Tor version 0.2.8.6

Imagine my surprise and disappointment. Why would these builds get mixed up like that and the filename on the archives indicate Tor 0.3.0.1-alpha on them? Wow, bad hair day I guess. Please fix this foobar ASAP.

Archive Package Name: tor-0.3.0.1-alpha.tar.gz
Size 5.7 MB (5704559 bytes)
$ sha1sum tor-0.3.0.1-alpha.tar.gz
67bf36d91caf60c9227910474d6e8402b8b6ad04 tor-0.3.0.1-alpha.tar.gz

Displays Tor version 0.2.8.6

I assume you have a problem with your $PATH. Specifically, I bet a Tor 0.2.8.6 is in your $PATH, and this new Tor that you built is not.

From your build directory, try running "src/or/tor --version"

Anonymous (not verified) said:

December 21, 2016

Permalink

Thanks arma, it was way early in the AM and I had been accidently inquiring the tor binary version I had installed in my system files and not that of the local tor binary I just built in my user folder area. $ tor --version and I should have been using $ ./tor --version

Anonymous (not verified) said:

December 21, 2016

Permalink

It looks like those Curves are infecting the whole tor infrastructure, at a time when AES, still the best available when fitted with a proper key size - as math works! - is HW accelerated in all available processors ever since 3-4 years ago.
https://en.wikipedia.org/wiki/AES_instruction_set

I've suggested once that the Curves encryption is simplistic/lame and that the encrypted streams, superficially analyzed, are easily identifiable as tor, as the Curves don't seem to have gained that much territory in the https implementation.
Nevertheless, according to the tor metrics half of the tot relays are still running tor 0.2.5.x - where ntor and the Curves were not yet democratically enforced.

I must admit, as interested as I am in the Curves development, there's nothing I have seen/red in the last period that made me change my mind about their weak security. All the explanations are really subjective and without any underlying mathematical proof / study, including Mr. Bernstein's speeches, that are rather superficial and boring, sometimes at a kindergarten level.

I think you might be confused about how ECC compares to AES -- elliptic curve crypto is asymmetric, like RSA, whereas AES is symmetric, like DES. So wondering about the use of curves "when AES is available in hardware" is a non sequitur.

To be even clearer, we still use AES in key pieces of the protocol (oops, no pun intended), and we sure do take advantage of the hardware acceleration.

You're right to wonder about whether ECC is indeed as robust as RSA -- a lot of people have been researching exactly that question lately. But 1024-bit RSA is very clearly bad news by now (the key is just too small), and 4096-bit RSA is way way way slower than we can handle in some places (I'm thinking circuit handshakes in particular). At the same time some very smart people (including Dan and Tanja, yes, but not just them) tell us that factoring is likely to have some surprising breakthroughs in the coming years. Those same people tell us that ECC has multiple decades of research in the math world. To me that all adds up to "yay ECC".

(You mention that it makes Tor traffic identifiable as Tor, but that's only the link encryption, which is much less important security-wise than the circuit handshake.)

As for your last concern, if you want to be in a position to assess the security of various mathematical assumptions, you need to go read the papers, not watch speeches.

Hope that helps!

Anonymous (not verified) said:

December 22, 2016

Permalink

I'm not confused, I've only focused on the elliptic curves cryptography in general, enforced now in tor for substituting both RSA & AES. I'm sorry if I wasn't clear enough.
Your answer doesn't really convince me about the right choice you made, as the technical head of tor, and please don't use logical fallacies for your arguments.
(For a deep packet inspection algorithm it will be an overkill to differentiate between legit AES based https (especially now that https is pretty much enabled by default and by large based on AES - even the tor website uses it) and AES powered tor, that was and still is my point).

I guess it's more of an actor scale concern, specifically who are you putting yourself against and what factoring capacity that actor really has. The best available factoring algorithm ATM looks to be Shor's and I'm only concerned that by implementing an efficient factoring algo in a video card pool / amazon cloud or in an ASIC based board, soon some smaller actors would be able to mess around with your otherwise beautiful toy. As for the big ones, your toy doesn't really help too much, regardless of what encryption you pick.

https://en.wikipedia.org/wiki/RSA_(cryptosystem)
"in 2011.[30] A theoretical hardware device named TWIRL and described by Shamir and Tromer in 2003 called into question the security of 1024 bit keys. It is currently recommended that n be at least 2048 bits long.[31]
In 1994, Peter Shor showed that a quantum computer (if one could ever be practically created for the purpose) would be able to factor in polynomial time, breaking RSA; see Shor's algorithm."

https://en.wikipedia.org/wiki/Elliptic_curve_cryptography
"In contrast with its current standing over RSA, elliptic curve cryptography is expected to be more vulnerable to an attack based on Shor's algorithm.["

Unfortunately, as I'm not that much of a math genius I'm trying to look after straight, condensate and objective explanations to my questions and I couldn't' find any with respect to the ECC security. I've mentioned Mr. Bernstein because he is the author of the specific ECC flavor that you have adopted and there is nothing in his speeches and papers that explains why he belies his curves are secure. As for me, I'm more happy with a carefully generated random value out of an infinite pool (very high entropy) and "obfuscated" in a robust algorithm instead of a value out of a finite field, obfuscated through a lame equation.

Hope you take my comment in a positive way, that's apart from your arrogance, as I do really care about your little toy and I'm using it mainly to protect my privacy in the world wild web. Careful with the logical fallacies and never mind me, just publish the studies and papers you've mentioned, the ones I couldn't find, in a section on the tor website as an argument for your cryptography choices.

I hope too that it helped! See you later alligator!

Anonymous (not verified) said:

December 25, 2016

Permalink

1) How long will the Archives link (https://blog.torproject.org/archive) on this blog remain in the menu while not being useful in any way?

2) Why can't these ANN-type blog posts (or the web site's Downloads section) provide a link to download locations and how-to-build docs? It's been 2 years now that I read these "new version" posts, spend 5-10 minutes trying to figure out where to get the code and then give up. There are probably 000's of others with similar experience.

Please fix these annoyances - it makes the site and content look sloppy.

Thanks for another great update, by the way. v0.3 features look awesome!

1) Until we move to the new blog. Any month now I hear! Try not to disturb too much of the duct tape still left on this one, because we need it to hobble along for a little while more.

2) Hm. Well, most people should not need to build it themselves. Most people should be using Tor Browser, and getting this new version of Tor when Tor Browser gets it. The power users can get it from their operating system packages. Also, in the past when we gave people URLs for how to find the tarball, they got super confused because they were totally unprepared to use a tarball.

That said, I agree with you that it used to be not obvious *when* you're going to have this Tor in your Tor Browser. That's why I asked Nick to add a sentence about that, which he did.
https://trac.torproject.org/projects/tor/ticket/20725