Tor 0.2.7.2-alpha is released
This, the second alpha in the Tor 0.2.7 series, has a number of new features, including a way to manually pick the number of introduction points for hidden services, and the much stronger Ed25519 signing key algorithm for regular Tor relays (including support for encrypted offline identity keys in the new algorithm).
Support for Ed25519 on relays is currently limited to signing router descriptors; later alphas in this series will extend Ed25519 key support to more parts of the Tor protocol.
If you typically build Tor from source, you can download the source code from the usual place on the website.
Packages should be up in a few days.
Changes in version 0.2.7.2-alpha - 2015-07-27
- Major features (Ed25519 identity keys, Proposal 220):
- All relays now maintain a stronger identity key, using the Ed25519 elliptic curve signature format. This master key is designed so that it can be kept offline. Relays also generate an online signing key, and a set of other Ed25519 keys and certificates. These are all automatically regenerated and rotated as needed. Implements part of ticket 12498.
- Directory authorities now vote on Ed25519 identity keys along with RSA1024 keys. Implements part of ticket 12498.
- Directory authorities track which Ed25519 identity keys have been used with which RSA1024 identity keys, and do not allow them to vary freely. Implements part of ticket 12498.
- Microdescriptors now include Ed25519 identity keys. Implements part of ticket 12498.
- Add support for offline encrypted Ed25519 master keys. To use this feature on your tor relay, run "tor --keygen" to make a new master key (or to make a new signing key if you already have a master key). Closes ticket 13642.
- Major features (Hidden services):
- Add the torrc option HiddenServiceNumIntroductionPoints, to specify a fixed number of introduction points. Its maximum value is 10 and default is 3. Using this option can increase a hidden service's reliability under load, at the cost of making it more visible that the hidden service is facing extra load. Closes ticket 4862.
- Remove the adaptive algorithm for choosing the number of introduction points, which used to change the number of introduction points (poorly) depending on the number of connections the HS sees. Closes ticket 4862.
Â
- Major features (onion key cross-certification):
- Relay descriptors now include signatures of their own identity keys, made using the TAP and ntor onion keys. These signatures allow relays to prove ownership of their own onion keys. Because of this change, microdescriptors will no longer need to include RSA identity keys. Implements proposal 228; closes ticket 12499.
- Major features (performance):
- Improve the runtime speed of Ed25519 operations by using the public-domain Ed25519-donna by Andrew M. ("floodyberry"). Implements ticket 16467.
- Improve the runtime speed of the ntor handshake by using an optimized curve25519 basepoint scalarmult implementation from the public-domain Ed25519-donna by Andrew M. ("floodyberry"), based on ideas by Adam Langley. Implements ticket 9663.
- Major bugfixes (client-side privacy, also in 0.2.6.9):
- Properly separate out each SOCKSPort when applying stream isolation. The error occurred because each port's session group was being overwritten by a default value when the listener connection was initialized. Fixes bug 16247; bugfix on 0.2.6.3-alpha. Patch by "jojelino".
- Major bugfixes (hidden service clients, stability, also in 0.2.6.10):
- Stop refusing to store updated hidden service descriptors on a client. This reverts commit 9407040c59218 (which indeed fixed bug 14219, but introduced a major hidden service reachability regression detailed in bug 16381). This is a temporary fix since we can live with the minor issue in bug 14219 (it just results in some load on the network) but the regression of 16381 is too much of a setback. First-round fix for bug 16381; bugfix on 0.2.6.3-alpha.
- Major bugfixes (hidden services):
- When cannibalizing a circuit for an introduction point, always extend to the chosen exit node (creating a 4 hop circuit). Previously Tor would use the current circuit exit node, which changed the original choice of introduction point, and could cause the hidden service to skip excluded introduction points or reconnect to a skipped introduction point. Fixes bug 16260; bugfix on 0.1.0.1-rc.
- Major bugfixes (open file limit):
- The open file limit wasn't checked before calling tor_accept_socket_nonblocking(), which would make Tor exceed the limit. Now, before opening a new socket, Tor validates the open file limit just before, and if the max has been reached, return an error. Fixes bug 16288; bugfix on 0.1.1.1-alpha.
- Major bugfixes (stability, also in 0.2.6.10):
- Stop crashing with an assertion failure when parsing certain kinds of malformed or truncated microdescriptors. Fixes bug 16400; bugfix on 0.2.6.1-alpha. Found by "torkeln"; fix based on a patch by "cypherpunks_backup".
- Stop random client-side assertion failures that could occur when connecting to a busy hidden service, or connecting to a hidden service while a NEWNYM is in progress. Fixes bug 16013; bugfix on 0.1.0.1-rc.
- Minor features (directory authorities, security, also in 0.2.6.9):
- The HSDir flag given by authorities now requires the Stable flag. For the current network, this results in going from 2887 to 2806 HSDirs. Also, it makes it harder for an attacker to launch a sybil attack by raising the effort for a relay to become Stable to require at the very least 7 days, while maintaining the 96 hours uptime requirement for HSDir. Implements ticket 8243.
- Minor features (client):
- Relax the validation of hostnames in SOCKS5 requests, allowing the character '_' to appear, in order to cope with domains observed in the wild that are serving non-RFC compliant records. Resolves ticket 16430.
- Relax the validation done to hostnames in SOCKS5 requests, and allow a single trailing '.' to cope with clients that pass FQDNs using that syntax to explicitly indicate that the domain name is fully-qualified. Fixes bug 16674; bugfix on 0.2.6.2-alpha.
- Add GroupWritable and WorldWritable options to unix-socket based SocksPort and ControlPort options. These options apply to a single socket, and override {Control,Socks}SocketsGroupWritable. Closes ticket 15220.
- Minor features (control protocol):
- Support network-liveness GETINFO key and NETWORK_LIVENESS event in the control protocol. Resolves ticket 15358.
- Minor features (directory authorities):
- Directory authorities no longer vote against the "Fast", "Stable", and "HSDir" flags just because they were going to vote against "Running": if the consensus turns out to be that the router was running, then the authority's vote should count. Patch from Peter Retzlaff; closes issue 8712.
- Minor features (geoip, also in 0.2.6.10):
- Update geoip to the June 3 2015 Maxmind GeoLite2 Country database.
- Update geoip6 to the June 3 2015 Maxmind GeoLite2 Country database.
- Minor features (hidden services):
- Add the new options "HiddenServiceMaxStreams" and "HiddenServiceMaxStreamsCloseCircuit" to allow hidden services to limit the maximum number of simultaneous streams per circuit, and optionally tear down the circuit when the limit is exceeded. Part of ticket 16052.
- Minor features (portability):
- Use C99 variadic macros when the compiler is not GCC. This avoids failing compilations on MSVC, and fixes a log-file-based race condition in our old workarounds. Original patch from Gisle Vanem.
- Minor bugfixes (compilation, also in 0.2.6.9):
- Build with --enable-systemd correctly when libsystemd is installed, but systemd is not. Fixes bug 16164; bugfix on 0.2.6.3-alpha. Patch from Peter Palfrader.
- Minor bugfixes (controller):
- Add the descriptor ID in each HS_DESC control event. It was missing, but specified in control-spec.txt. Fixes bug 15881; bugfix on 0.2.5.2-alpha.
- Minor bugfixes (crypto error-handling, also in 0.2.6.10):
- Check for failures from crypto_early_init, and refuse to continue. A previous typo meant that we could keep going with an uninitialized crypto library, and would have OpenSSL initialize its own PRNG. Fixes bug 16360; bugfix on 0.2.5.2-alpha, introduced when implementing ticket 4900. Patch by "teor".
- Minor bugfixes (hidden services):
- Fix a crash when reloading configuration while at least one configured and one ephemeral hidden service exists. Fixes bug 16060; bugfix on 0.2.7.1-alpha.
- Avoid crashing with a double-free bug when we create an ephemeral hidden service but adding it fails for some reason. Fixes bug 16228; bugfix on 0.2.7.1-alpha.
- Minor bugfixes (Linux seccomp2 sandbox):
- Use the sandbox in tor_open_cloexec whether or not O_CLOEXEC is defined. Patch by "teor". Fixes bug 16515; bugfix on 0.2.3.1-alpha.
- Minor bugfixes (Linux seccomp2 sandbox, also in 0.2.6.10):
- Allow pipe() and pipe2() syscalls in the seccomp2 sandbox: we need these when eventfd2() support is missing. Fixes bug 16363; bugfix on 0.2.6.3-alpha. Patch from "teor".
- Minor bugfixes (Linux seccomp2 sandbox, also in 0.2.6.9):
- Fix sandboxing to work when running as a relay, by allowing the renaming of secret_id_key, and allowing the eventfd2 and futex syscalls. Fixes bug 16244; bugfix on 0.2.6.1-alpha. Patch by Peter Palfrader.
- Allow systemd connections to work with the Linux seccomp2 sandbox code. Fixes bug 16212; bugfix on 0.2.6.2-alpha. Patch by Peter Palfrader.
- Minor bugfixes (relay):
- Fix a rarely-encountered memory leak when failing to initialize the thread pool. Fixes bug 16631; bugfix on 0.2.6.3-alpha. Patch from "cypherpunks".
- Minor bugfixes (systemd):
- Fix an accidental formatting error that broke the systemd configuration file. Fixes bug 16152; bugfix on 0.2.7.1-alpha.
- Tor's systemd unit file no longer contains extraneous spaces. These spaces would sometimes confuse tools like deb-systemd- helper. Fixes bug 16162; bugfix on 0.2.5.5-alpha.
- Minor bugfixes (tests):
- Use the configured Python executable when running test-stem-full. Fixes bug 16470; bugfix on 0.2.7.1-alpha.
- Minor bugfixes (tests, also in 0.2.6.9):
- Fix a crash in the unit tests when built with MSVC2013. Fixes bug 16030; bugfix on 0.2.6.2-alpha. Patch from "NewEraCracker".
- Minor bugfixes (threads, comments):
- Always initialize return value in compute_desc_id in rendcommon.c Patch by "teor". Fixes part of bug 16115; bugfix on 0.2.7.1-alpha.
- Check for NULL values in getinfo_helper_onions(). Patch by "teor". Fixes part of bug 16115; bugfix on 0.2.7.1-alpha.
- Remove undefined directive-in-macro in test_util_writepid clang 3.7 complains that using a preprocessor directive inside a macro invocation in test_util_writepid in test_util.c is undefined. Patch by "teor". Fixes part of bug 16115; bugfix on 0.2.7.1-alpha.
- Code simplification and refactoring:
- Define WINVER and _WIN32_WINNT centrally, in orconfig.h, in order to ensure they remain consistent and visible everywhere.
- Remove some vestigial workarounds for the MSVC6 compiler. We haven't supported that in ages.
- The link authentication code has been refactored for better testability and reliability. It now uses code generated with the "trunnel" binary encoding generator, to reduce the risk of bugs due to programmer error. Done as part of ticket 12498.
- Documentation:
- Include a specific and (hopefully) accurate documentation of the torrc file's meta-format in doc/torrc_format.txt. This is mainly of interest to people writing programs to parse or generate torrc files. This document is not a commitment to long-term compatibility; some aspects of the current format are a bit ridiculous. Closes ticket 2325.
- Removed features:
- Tor no longer supports copies of OpenSSL that are missing support for Elliptic Curve Cryptography. (We began using ECC when available in 0.2.4.8-alpha, for more safe and efficient key negotiation.) In particular, support for at least one of P256 or P224 is now required, with manual configuration needed if only P224 is available. Resolves ticket 16140.
- Tor no longer supports versions of OpenSSL before 1.0. (If you are on an operating system that has not upgraded to OpenSSL 1.0 or later, and you compile Tor from source, you will need to install a more recent OpenSSL to link Tor against.) These versions of OpenSSL are still supported by the OpenSSL, but the numerous cryptographic improvements in later OpenSSL releases makes them a clear choice. Resolves ticket 16034.
- Remove the HidServDirectoryV2 option. Now all relays offer to store hidden service descriptors. Related to 16543.
- Remove the VoteOnHidServDirectoriesV2 option, since all authorities have long set it to 1. Closes ticket 16543.
- Testing:
- Document use of coverity, clang static analyzer, and clang dynamic undefined behavior and address sanitizers in doc/HACKING. Include detailed usage instructions in the blacklist. Patch by "teor". Closes ticket 15817.
- The link authentication protocol code now has extensive tests.
- The relay descriptor signature testing code now has extensive tests.
- The test_workqueue program now runs faster, and is enabled by default as a part of "make check".
- Now that OpenSSL has its own scrypt implementation, add an unit test that checks for interoperability between libscrypt_scrypt() and OpenSSL's EVP_PBE_scrypt() so that we could not use libscrypt and rely on EVP_PBE_scrypt() whenever possible. Resolves ticket 16189.
Comments
Please note that the comment area below has been archived.
Are they still called
Are they still called "hidden services"? Weren't they renamed to onion services?
Other than that, wonderful job as always. The amount of work you did for ticket 12498 and proposal 220 is particularly amazing :).
The exact terminology is
The exact terminology is still being determined. Hidden services are designed to be anonymous, but Tor developers are also working more direct services, which are less anonymous but still internal to the Tor network. These have a number of applications and might be more applicable to companies like Facebook and DuckDuckGo who currently run their own non-anonymous hidden service. It's my interpretation that "onion services" is a more general term that includes this new infrastructure, while "hidden services" is a subset of onion services that have anonymity in mind. Again, we're still debating about the proper terms, so this may change.
Awesome Patchnotes! Will all
Awesome Patchnotes! Will all pre 0.2.4.8 relays (without manual ssl config) be cut after consensus running this release?
I upgraded to Win 10 and now
I upgraded to Win 10 and now I get a "Tor browser does not have permission to access the profile. Please adjust your file permissions and try again." I have tried everything I can think of and nothing works. Any suggestions? Thanx in advance.
I get this too. I figured
I get this too. I figured out that running the program as an admin is a work around, but I don't think I should have to elevate to admin privilege to run a browser... that seems wrong.
any and every time i connect
any and every time i connect to tor, one of the nodes (generally the entry) is a french server, and most of time 62.210.132.56
THIS HAS HAPPENED 100 times out of 100 trials to change the tor circuit.
this happens only on one of my laptops. the other has a "normal" behaviour = nodes from all over the world.
https://www.torproject.org/do
https://www.torproject.org/docs/faq#EntryGuards
and I use TOR 5.03a
and I use TOR 5.03a
*Tor not TOR, thank you!
*Tor not TOR, thank you!
Also, you're probably
Also, you're probably referring to the Tor Browser, instead of Tor.
Heard of a MIT exploit that
Heard of a MIT exploit that has been released to Tor developers. What is the progress for a fix on that?
Yes. We're talking to them
Yes. We're talking to them about it. It's not an easy attack, and it's also not an easy fix.
Keep up the amazing work
Keep up the amazing work over there! Where can I find the newest browser download?
https://www.torproject.org/do
https://www.torproject.org/download
The blog backend is
The blog backend is terrible, and there's no one formally tasked with moderating it.
IMO, Roger should not wait to fix that.
any update for tor browser
any update for tor browser bundle ?
How Spies Could Unmask Tor
How Spies Could Unmask Tor Users without Cracking Encryption
http://thehackernews.com/2015/08/unmask-tor-network.html
wtf ?
I posted what I hope is a
I posted what I hope is a useful explanation (targeted towards researchers and developers) at
https://blog.torproject.org/blog/technical-summary-usenix-fingerprintin…
Regarding "All relays now
Regarding "All relays now maintain a stronger identity key, using the Ed25519 elliptic curve signature format.":
Why elliptic curve now? I think it was one of the last year's big crypto news when it was revealed how the elliptic curve algorithms were pulled through to popularity (back-doored) by NSA?
If I remember, one of the commenters in this blog then asked about Tor using those algorithms, and the answer was "no". So what's going on now?
I recommend this 31c3 talk
I recommend this 31c3 talk by Dan, Tanja, and Nadia:
https://events.ccc.de/congress/2014/Fahrplan/events/6369.html
There's a video here, but probably you can find a more free video somewhere too:
https://www.youtube.com/watch?v=l6jTFxQaUJA
There is nothing (known to be) wrong with elliptic curve crypto in general, and in fact it's considered by many to be stronger than RSA, especially in the face of recent bad news about RSA. (RSA 1024-bit is particularly bad, but even 2048-bit is looking not so good, and it has crazy performance penalties too.) The problem from the NSA was particular curves that they tricked NIST into standardizing.
ed25519 is not one of those curves:
http://safecurves.cr.yp.to/
All of that said, we do use the NIST curves for our link encryption currently, because that's all openssl has right now, and it's still looking much better than RSA 1024-bit, and also because much of the goal of the link encryption is to blend in with normal browser traffic. (Don't confuse the link encryption with the circuit encryption.)
Hope that helps.
This statement is
This statement is interesting as well: "Tor no longer supports copies of OpenSSL that are missing support for Elliptic Curve Cryptography. (We began using ECC when available in 0.2.4.8-alpha, for more safe and efficient key negotiation.)"
If I can ask, what or who compelled you to start using ECC? Was it at the request of one of the powerful sponsors?
Thanks.
After talking to Dan
After talking to Dan Bernstein, Tanja Lange, Nadia Heninger, and many other experts in the area, it became clear that RSA really wasn't going to hold up in the way we want over the coming years (that's the nice way of saying it -- the less nice way is that it's already become a terrible move to be using RSA today).
And no, none of our funders asked us to switch to ECC. They trust us to make good security and design decisions.
This affects TLS more than
This affects TLS more than anything else and is orthogonal to the relay identity key move, though the rationale is similar. Between DHE and ECDHE, DHE is easier to break with logjam style precomputation attacks, is considerably slower, and sends more data on the wire.
Recent versions of Tor are already preferring/negotiating ECDHE over DHE when both sides support it, and with the deprecation of support for OpenSSL < 1.0 (when ECC support was introduced into OpenSSL), making support for it a requirement is the sensible thing to do (since it is already used most of the time anyway).
This only affects people that are trying to build Tor against OpenSSL that explicitly had support for certain curves ripped out, and even Redhat has stopped doing that for the curves used by Tor, so realistically should have no impact.
I could have written a better changelog entry.
Wasn't ECC promoted by the
Wasn't ECC promoted by the US government? Is it possible ECC is already reverse engineered?
There's nothing to reverse
There's nothing to reverse engineer since the specs are open, though I assume this is just a terminology thing.
There's 2 choices for TLS's key exchange algorithm that provide perfect forward secrecy, Diffie-Hellman (broken via logjam style pre-computation attacks), and Elliptic Curve Diffie-Hellman, which people get nervous about when NIST curves enter the picture.
The current consensus is that while the NIST curves are not ideal, they probably aren't totally broken, and given the choice between DH and ECDH with the NIST curves, the latter is the more secure choice.
The TLS link encryption doesn't matter a massive amount (since traffic is further encrypted) as well, so defense in depth exists in the event that the NIST curves are totally broken.
For NIST curves, yes. As
For NIST curves, yes. As others have said the spec is open so it was designed on paper and then implemented, not the other way around.
I'd also like to point out that although Tor's circuit construction protocols use ECC, they do not use NIST curves. Instead, they achieve ECDHE through Curve25519, which was designed by Dan Bernstein very independently of NIST. I don't know whether NIST curves are mathematically untrustworthy or not, but I certainly trust the construction and design of Curve25519 far more than NIST curves. If you aren't comfortable with NIST ECC curves, then the fact that Tor circuits don't use them is somewhat comforting.
Tor switched to an OpenSSL-based ECC for ECDHE TLS connections between the exit node and the remote web server, which achieves better security than older RSA DHE. The NIST curves are in the TLS spec and that has nothing to do with Tor.