Tor 0.3.0.6 is released: a new series is stable!
Tor 0.3.0.6 is the first stable release of the Tor 0.3.0 series.
With the 0.3.0 series, clients and relays now use Ed25519 keys to authenticate their link connections to relays, rather than the old RSA1024 keys that they used before. (Circuit crypto has been Curve25519-authenticated since 0.2.4.8-alpha.) We have also replaced the guard selection and replacement algorithm to behave more robustly in the presence of unreliable networks, and to resist guard- capture attacks.
This series also includes numerous other small features and bugfixes, along with more groundwork for the upcoming hidden-services revamp.
Per our stable release policy, we plan to support the Tor 0.3.0 release series for at least the next nine months, or for three months after the first stable release of the 0.3.1 series: whichever is longer. If you need a release with long-term support, we recommend that you stay with the 0.2.9 series.
If you build Tor from source, you can find it at the usual place on the website. Packages should be ready over the next weeks, with a Tor Browser release in late May or early June.
Below are the changes since 0.2.9.10. For a list of only the changes since 0.3.0.5-rc, see the ChangeLog file.
Changes in version 0.3.0.6 - 2017-04-26
- Major features (directory authority, security):
- The default for AuthDirPinKeys is now 1: directory authorities will reject relays where the RSA identity key matches a previously seen value, but the Ed25519 key has changed. Closes ticket 18319.
- 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):
- 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.
- 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.
- Major features (security):
- Change the algorithm used to decide DNS TTLs on client and server side, to better resist DNS-based correlation attacks like the DefecTor attack of Greschbach, Pulls, Roberts, Winter, and Feamster. Now relays only return one of two possible DNS TTL values, and clients are willing to believe DNS TTL values up to 3 hours long. Closes ticket 19769.
- Major bugfixes (client, onion service, also in 0.2.9.9):
- Fix a client-side onion service reachability bug, where multiple socks requests to an onion service (or a single slow request) could cause us to mistakenly mark some of the service's introduction points as failed, and we cache that failure so eventually we run out and can't reach the service. Also resolves a mysterious "Remote server sent bogus reason code 65021" log warning. The bug was introduced in ticket 17218, where we tried to remember the circuit end reason as a uint16_t, which mangled negative values. Partially fixes bug 21056 and fixes bug 20307; bugfix on 0.2.8.1-alpha.
- Major bugfixes (crash, directory connections):
- Fix a rare crash when sending a begin cell on a circuit whose linked directory connection had already been closed. Fixes bug 21576; bugfix on 0.2.9.3-alpha. Reported by Alec Muffett.
- Major bugfixes (directory authority):
- During voting, when marking a relay as a probable sybil, do not clear its BadExit flag: sybils can still be bad in other ways too. (We still clear the other flags.) Fixes bug 21108; bugfix on 0.2.0.13-alpha.
- Major bugfixes (DNS):
- Fix a bug that prevented exit nodes from caching DNS records for more than 60 seconds. Fixes bug 19025; bugfix on 0.2.4.7-alpha.
- Major bugfixes (IPv6 Exits):
- Stop rejecting all IPv6 traffic on Exits whose exit policy rejects any IPv6 addresses. Instead, only reject a port over IPv6 if the exit policy rejects that port on more than an IPv6 /16 of addresses. This bug was made worse by 17027 in 0.2.8.1-alpha, which rejected a relay's own IPv6 address by default. Fixes bug 21357; bugfix on commit 004f3f4e53 in 0.2.4.7-alpha.
- Major bugfixes (parsing):
- Fix an integer underflow bug when comparing malformed Tor versions. This bug could crash Tor when built with --enable-expensive-hardening, or on Tor 0.2.9.1-alpha through Tor 0.2.9.8, which were built with -ftrapv by default. In other cases it was harmless. Part of TROVE-2017-001. Fixes bug 21278; bugfix on 0.0.8pre1. Found by OSS-Fuzz.
- When parsing a malformed content-length field from an HTTP message, do not read off the end of the buffer. This bug was a potential remote denial-of-service attack against Tor clients and relays. A workaround was released in October 2016, to prevent this bug from crashing Tor. This is a fix for the underlying issue, which should no longer matter (if you applied the earlier patch). Fixes bug 20894; bugfix on 0.2.0.16-alpha. Bug found by fuzzing using AFL (http://lcamtuf.coredump.cx/afl/).
- 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.
- Major bugfixes (security, also in 0.2.9.9):
- Downgrade the "-ftrapv" option from "always on" to "only on when --enable-expensive-hardening is provided." This hardening option, like others, can turn survivable bugs into crashes--and having it on by default made a (relatively harmless) integer overflow bug into a denial-of-service bug. Fixes bug 21278 (TROVE-2017-001); bugfix on 0.2.9.1-alpha.
- Minor feature (client):
- Enable IPv6 traffic on the SocksPort by default. To disable this, a user will have to specify "NoIPv6Traffic". Closes ticket 21269.
- Minor feature (fallback scripts):
- Add a check_existing mode to updateFallbackDirs.py, which checks if fallbacks in the hard-coded list are working. Closes ticket 20174. Patch by haxxpop.
- Minor feature (protocol versioning):
- Add new protocol version for proposal 224. HSIntro now advertises version "3-4" and HSDir version "1-2". Fixes ticket 20656.
- Minor features (ciphersuite selection):
- Allow relays to accept a wider range of ciphersuites, including chacha20-poly1305 and AES-CCM. Closes the other part of 15426.
- Clients now advertise a list of ciphersuites closer to the ones preferred by Firefox. Closes part of ticket 15426.
- Minor features (controller):
- Minor features (controller, configuration):
- Each of the *Port options, such as SocksPort, ORPort, ControlPort, and so on, now comes with a __*Port variant that will not be saved to the torrc file by the controller's SAVECONF command. This change allows TorBrowser to set up a single-use domain socket for each time it launches Tor. Closes ticket 20956.
- The GETCONF command can now query options that may only be meaningful in context-sensitive lists. This allows the controller to query the mixed SocksPort/__SocksPort style options introduced in feature 20956. Implements ticket 21300.
- 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 authorities):
- 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 (entry guards):
- Add UseEntryGuards to TEST_OPTIONS_DEFAULT_VALUES in order to not break regression tests.
- Require UseEntryGuards when UseBridges is set, in order to make sure bridges aren't bypassed. Resolves ticket 20502.
- Minor features (fallback directories):
- Allow 3 fallback relays per operator, which is safe now that we are choosing 200 fallback relays. Closes ticket 20912.
- Annotate updateFallbackDirs.py with the bandwidth and consensus weight for each candidate fallback. Closes ticket 20878.
- Display the relay fingerprint when downloading consensuses from fallbacks. Closes ticket 20908.
- Exclude relays affected by bug 20499 from the fallback list. Exclude relays from the fallback list if they are running versions known to be affected by bug 20499, or if in our tests they deliver a stale consensus (i.e. one that expired more than 24 hours ago). Closes ticket 20539.
- Make it easier to change the output sort order of fallbacks. Closes ticket 20822.
- Reduce the minimum fallback bandwidth to 1 MByte/s. Part of ticket 18828.
- Require fallback directories to have the same address and port for 7 days (now that we have enough relays with this stability). Relays whose OnionOO stability timer is reset on restart by bug 18050 should upgrade to Tor 0.2.8.7 or later, which has a fix for this issue. Closes ticket 20880; maintains short-term fix in 0.2.8.2-alpha.
- Require fallbacks to have flags for 90% of the time (weighted decaying average), rather than 95%. This allows at least 73% of clients to bootstrap in the first 5 seconds without contacting an authority. Part of ticket 18828.
- Select 200 fallback directories for each release. Closes ticket 20881.
- 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 (geoip):
- Update geoip and geoip6 to the April 4 2017 Maxmind GeoLite2 Country database.
- Minor features (geoip, also in 0.2.9.9):
- Update geoip and geoip6 to the January 4 2017 Maxmind GeoLite2 Country database.
- Minor features (infrastructure):
- Implement smartlist_add_strdup() function. Replaces the use of smartlist_add(sl, tor_strdup(str)). Closes ticket 20048.
- Minor features (linting):
- Enhance the changes file linter to warn on Tor versions that are prefixed with "tor-". Closes ticket 21096.
- Minor features (logging):
- In several places, describe unset ed25519 keys as "<unset>", rather than the scary "AAAAAAAA...AAA". Closes ticket 21037.
- Minor features (portability, compilation):
- Minor features (relay):
- We now allow separation of exit and relay traffic to different source IP addresses, using the OutboundBindAddressExit and OutboundBindAddressOR options respectively. Closes ticket 17975. Written by Michael Sonntag.
- Minor features (reliability, crash):
- Try better to detect problems in buffers where they might grow (or think they have grown) over 2 GB in size. Diagnostic for bug 21369.
- Minor features (testing):
- During 'make test-network-all', if tor logs any warnings, ask chutney to output them. Requires a recent version of chutney with the 21572 patch. Implements 21570.
- Minor bugfix (control protocol):
- The reply to a "GETINFO config/names" request via the control protocol now spells the type "Dependent" correctly. This is a breaking change in the control protocol. (The field seems to be ignored by the most common known controllers.) Fixes bug 18146; bugfix on 0.1.1.4-alpha.
- The GETINFO extra-info/digest/<digest> command was broken because of a wrong base16 decode return value check, introduced when refactoring that API. Fixes bug 22034; bugfix on 0.2.9.1-alpha.
- Minor bugfix (logging):
- Don't recommend the use of Tor2web in non-anonymous mode. Recommending Tor2web is a bad idea because the client loses all anonymity. Tor2web should only be used in specific cases by users who *know* and understand the issues. Fixes bug 21294; bugfix on 0.2.9.3-alpha.
- Minor bugfixes (bug resilience):
- Fix an unreachable size_t overflow in base64_decode(). Fixes bug 19222; bugfix on 0.2.0.9-alpha. Found by Guido Vranken; fixed by Hans Jerry Illikainen.
- Minor bugfixes (build):
- Replace obsolete Autoconf macros with their modern equivalent and prevent similar issues in the future. Fixes bug 20990; bugfix on 0.1.0.1-rc.
- Minor bugfixes (certificate expiration time):
- Avoid using link certificates that don't become valid till some time in the future. Fixes bug 21420; bugfix on 0.2.4.11-alpha
- Minor bugfixes (client):
- Always recover from failures in extend_info_from_node(), in an attempt to prevent any recurrence of bug 21242. Fixes bug 21372; bugfix on 0.2.3.1-alpha.
- 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 (code correctness):
- Repair a couple of (unreachable or harmless) cases of the risky comparison-by-subtraction pattern that caused bug 21278.
- Minor bugfixes (config):
- Don't assert on startup when trying to get the options list and LearnCircuitBuildTimeout is set to 0: we are currently parsing the options so of course they aren't ready yet. Fixes bug 21062; bugfix on 0.2.9.3-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 (configure, autoconf):
- Rename the configure option --enable-expensive-hardening to --enable-fragile-hardening. Expensive hardening makes the tor daemon abort when some kinds of issues are detected. Thus, it makes tor more at risk of remote crashes but safer against RCE or heartbleed bug category. We now try to explain this issue in a message from the configure script. Fixes bug 21290; bugfix on 0.2.5.4-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 (crash prevention):
- Fix an (currently untriggerable, but potentially dangerous) crash bug when base32-encoding inputs whose sizes are not a multiple of 5. Fixes bug 21894; bugfix on 0.2.9.1-alpha.
- Minor bugfixes (dead code):
- Remove a redundant check for PidFile changes at runtime in options_transition_allowed(): this check is already performed regardless of whether the sandbox is active. Fixes bug 21123; bugfix on 0.2.5.4-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 mirrors):
- Allow relays to use directory mirrors without a DirPort: these relays need to be contacted over their ORPorts using a begindir connection. Fixes one case of bug 20711; bugfix on 0.2.8.2-alpha.
- Clarify the message logged when a remote relay is unexpectedly missing an ORPort or DirPort: users were confusing this with a local port. Fixes another case of bug 20711; bugfix on 0.2.8.2-alpha.
- Minor bugfixes (directory system):
- 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.
- 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.
- Minor bugfixes (documentation):
- Update the tor manual page to document every option that can not be changed while tor is running. Fixes bug 21122.
- 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 (fallback directories):
- Avoid checking fallback candidates' DirPorts if they are down in OnionOO. When a relay operator has multiple relays, this prioritizes relays that are up over relays that are down. Fixes bug 20926; bugfix on 0.2.8.3-alpha.
- Stop failing when OUTPUT_COMMENTS is True in updateFallbackDirs.py. Fixes bug 20877; bugfix on 0.2.8.3-alpha.
- Stop failing when a relay has no uptime data in updateFallbackDirs.py. Fixes bug 20945; bugfix on 0.2.8.1-alpha.
- Minor bugfixes (hidden service):
- Clean up the code for expiring intro points with no associated circuits. It was causing, rarely, a service with some expiring introduction points to not open enough additional introduction points. Fixes part of bug 21302; bugfix on 0.2.7.2-alpha.
- Resolve two possible underflows which could lead to creating and closing a lot of introduction point circuits in a non-stop loop. Fixes bug 21302; bugfix on 0.2.7.2-alpha.
- Stop setting the torrc option HiddenServiceStatistics to "0" just because we're not a bridge or relay. Instead, we preserve whatever value the user set (or didn't set). Fixes bug 21150; bugfix on 0.2.6.2-alpha.
- Minor bugfixes (hidden services):
- Make hidden services check for failed intro point connections, even when they have exceeded their intro point creation limit. Fixes bug 21596; bugfix on 0.2.7.2-alpha. Reported by Alec Muffett.
- Make hidden services with 8 to 10 introduction points check for failed circuits immediately after startup. Previously, they would wait for 5 minutes before performing their first checks. Fixes bug 21594; bugfix on 0.2.3.9-alpha. Reported by Alec Muffett.
- 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 (IPv6):
- Make IPv6-using clients try harder to find an IPv6 directory server. Fixes bug 20999; bugfix on 0.2.8.2-alpha.
- When IPv6 addresses have not been downloaded yet (microdesc consensus documents don't list relay IPv6 addresses), use hard- coded addresses for authorities, fallbacks, and configured bridges. Now IPv6-only clients can use microdescriptors. Fixes bug 20996; bugfix on b167e82 from 19608 in 0.2.8.5-alpha.
- 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 (onion services):
- Allow the number of introduction points to be as low as 0, rather than as low as 3. Fixes bug 21033; bugfix on 0.2.7.2-alpha.
- Minor bugfixes (portability):
- Use "OpenBSD" compiler macro instead of "OPENBSD" or "__OpenBSD__". It is supported by OpenBSD itself, and also by most OpenBSD variants (such as Bitrig). Fixes bug 20980; bugfix on 0.1.2.1-alpha.
- Minor bugfixes (portability, also in 0.2.9.9):
- Avoid crashing when Tor is built using headers that contain CLOCK_MONOTONIC_COARSE, but then tries to run on an older kernel without CLOCK_MONOTONIC_COARSE. Fixes bug 21035; bugfix on 0.2.9.1-alpha.
- Fix Libevent detection on platforms without Libevent 1 headers installed. Fixes bug 21051; bugfix on 0.2.9.1-alpha.
- Minor bugfixes (relay):
- Avoid a double-marked-circuit warning that could happen when we receive DESTROY cells under heavy load. Fixes bug 20059; bugfix on 0.1.0.1-rc.
- Honor DataDirectoryGroupReadable when tor is a relay. Previously, initializing the keys would reset the DataDirectory to 0700 instead of 0750 even if DataDirectoryGroupReadable was set to 1. Fixes bug 19953; bugfix on 0.0.2pre16. Patch by "redfish".
- Minor bugfixes (testing):
- Fix Raspbian build issues related to missing socket errno in test_util.c. Fixes bug 21116; bugfix on 0.2.8.2. Patch by "hein".
- Remove undefined behavior from the backtrace generator by removing its signal handler. Fixes bug 21026; bugfix on 0.2.5.2-alpha.
- Use bash in src/test/test-network.sh. This ensures we reliably call chutney's newer tools/test-network.sh when available. Fixes bug 21562; bugfix on 0.2.9.1-alpha.
- Minor bugfixes (tor-resolve):
- The tor-resolve command line tool now rejects hostnames over 255 characters in length. Previously, it would silently truncate them, which could lead to bugs. Fixes bug 21280; bugfix on 0.0.9pre5. Patch by "junglefowl".
- Minor bugfixes (unit tests):
- Allow the unit tests to pass even when DNS lookups of bogus addresses do not fail as expected. Fixes bug 20862 and 20863; bugfix on unit tests introduced in 0.2.8.1-alpha through 0.2.9.4-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 0.2.0.7-alpha. Patch by fk.
- Minor bugfixes (Windows services):
- Be sure to initialize the monotonic time subsystem before using it, even when running as an NT service. Fixes bug 21356; bugfix on 0.2.9.1-alpha.
- 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.
- Extract magic numbers in circuituse.c into defined variables.
- 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.
- Refactor circuit_is_available_for_use to remove unnecessary check.
- Refactor circuit_predict_and_launch_new for readability and testability. Closes ticket 18873.
- Refactor code to manipulate global_origin_circuit_list into separate functions. Closes ticket 20921.
- 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 (formatting):
- Clean up formatting of tor.1 man page and HTML doc, where <pre> blocks were incorrectly appearing. Closes ticket 20885.
- Documentation (man page):
- Clarify many options in tor.1 and add some min/max values for HiddenService options. Closes ticket 21058.
- Change '1' to 'weight_scale' in consensus bw weights calculation comments, as that is reality. Closes ticket 20273. Patch from pastly.
- 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.
- Correct the value for AuthDirGuardBWGuarantee in the manpage, from 250 KBytes to 2 MBytes. Fixes bug 20435; bugfix on 0.2.5.6-alpha.
- Include the "TBits" unit in Tor's man page. Fixes part of bug 20622; bugfix on 0.2.5.1-alpha.
- Small fixes to the fuzzing documentation. Closes ticket 21472.
- Stop the man page from incorrectly stating that HiddenServiceDir must already exist. Fixes 20486.
- Update the description of the directory server options in the manual page, to clarify that a relay no longer needs to set DirPort in order to be a directory cache. Closes ticket 21720.
- 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.
- 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.
- 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.
Please note that the comment area below has been archived.
9 years later from first
9 years later from first 2.0.x stable release! :)
@nickm This deserves some
@nickm This deserves some birthday cake!
Lots of bugfixes, this is
Lots of bugfixes, this is much appreciated but a little bit scary!
Wasn't there a plan to rewrite part of Tor, such as bug-prone parsing code, in memory-safe languages? That sounds nicer the more I think about it.
>Minor features (geoip): >
>Minor features (geoip):
> Update geoip and geoip6 to the April 4 2017 Maxmind GeoLite2 >Country database.
>Minor features (geoip, also in 0.2.9.9):
> Update geoip and geoip6 to the January 4 2017 Maxmind >GeoLite2 Country database.
Looks like a mistake in
Looks like a mistake in aggregating the ChangeLog entries into the unified ReleaseNotes entry for 0.3.0.x. No worries.
I worry that RSA 1024 is
I worry that RSA 1024 is still somehow used in Tor. Where could I read about all implications of this issue? If attacker stores all traffic and then at some moment find private RSA1024 keys, how much information she can get? Do we have more practical attacks on crypto? If I don't confuse it, essential Tor crypto was moved to ECC many years back, but RSA was still used for some things. One should also mention that many Tor relays use old versions of Tor, so attacks are even more probable.
> I worry that RSA 1024 is
> I worry that RSA 1024 is still somehow used in Tor. Where could I read about all implications of this issue?
I'm a Tor user. I answer this question according to my understanding, please point mistakes out if I'm wrong.
As far as I know, the only major RSA-1024 usage now, is the Hidden Service private key. This private key determines the ".onion" address and protects hidden services against forgery.
> If attacker stores all traffic and then at some moment find private RSA1024 keys, how much information she can get?
Basically, no information. This key is only used for signing, not data encryption. Actually encryption is done by Curve25519 I think.
If an attacker wants to attack a Hidden Service by exploiting the weakness of RSA-1024, the attacker first need to find out the RSA-1024 private key using massive computational resources, then the attacker needs to hijack the Tor connection of a user in real time, to a fake Hidden Service website. But the attacker is not able to get infomation of previously recorded data.
New version of Hidden Service is still working on progress, hopefully it can be completely within 2017.
> One should also mention that many Tor relays use old versions of Tor.
I think this is the bigger issue.
The question is why so many
The question is why so many relays are using so old and very old Tor versions?
Well, that one at least is
Well, that one at least is easy. Many people run Debian stable, and the version of Tor in Debian stable is from quite a while ago.
It isn't a security issue (for the relays), since our fine deb maintainer makes sure that it stays up to date on its security things.
But you're right that it can still be a security issue for the clients, since these relays aren't using the newest and greatest Tor designs.
All things considered though, I'm not worried. They're still useful relays, and there's something to be said for stability, and they'll update over time.
Is old version of tor node a
Is old version of tor node a bottleneck in the whole tor chain (in sense of security)? Does it downgrade encryption also between other nodes in the chain? If my guard uses old tor crypto which knows nothing about ECC for encryption, does it mean that ECC will not be used in my tor chain at all? (AFAIK, not, am I right?) Does it have sense to restrict the choice of guard nodes only by those which run last stable Tor release?
> If my guard uses old tor
> If my guard uses old tor crypto which knows nothing about ECC for encryption, does it mean that ECC will not be used in my tor chain at all?
So something that predates 0.2.4.something? It's done on a per hop basis anyway.
> Does it have sense to restrict the choice of guard nodes only by those which run last stable Tor release?
If you want to dramatically reduce your anonymity set, then sure.
It's done on a per hop basis
It's done on a per hop basis anyway.
Oh, yes, now I've recalled that during transition from RSA to ECC it was required that at least one node in the chain must use ECC.
If you want to dramatically reduce your anonymity set, then sure.
Anonymity is judged on the basis of many effects, each contributing as both partially positive and partially negative for anonymity. Final summary is not always easy to find. E.g. if you know in advance that some nodes are malicious, it is better to remove them from anonymity set.
In the case discussed above, one needs to compare the risks of the cases: 1) Both: my guard is not using ECC and NSA can break RSA in real time. 2) Reduced anonymity set because RSA guards will not be used. Taking into account that guard nodes are quasi-stable (rotated about once in 2 months) answer is not so easy for me. However, once you cannot see any issue here, I think I don't need to interfere with the Tor protocol.
> NSA can break RSA in real
> NSA can break RSA in real time.
I think you misunderstood
I think you misunderstood the above comment. The person was saying "if NSA can break RSA in real time, then".
May the old buggy code -
May the old buggy code - ChangeLog! - is a problem, too?
Beside the crypto?
May the old buggy code -
May the old buggy code - ChangeLog! - is a problem, too?
I don't think so. You can remove all files in /var/lib/tor and let tor fetch statistics again. You'll get the same RSA keys.
This is a helpful
This is a helpful discussion.
Can I chime in with a question about the Web of Trust for Tails signing keys?
When Tails transitioned to a new signing key (see tails.boum.org) a few years ago, they said that they would extend the expiration date in one year increments as needed, which has in fact happened. But since about 2016, only anonymous keys which are apparently not listed in the key servers have been used to sign the signing key. Why? Should we be worried that Tails has lost control of their signing key?
TIA for your thoughts!
I think it is offtopic to
I think it is offtopic to discuss Tails here, but anyway... I would warry about another thing in Tails. Namely, despite it is assembled from well known opensource projects, the Tails team doesn't publish any instruments to create images by other people. So, if you need to get Tails with some slight modifications, you cannot take build script and patch it. This was true in the past, and I think it still the problem.
IOW, Tails Proejct should
IOW, Tails Proejct should support reproducible builds. I agree. I thought it did.
Thanks for reply! So, as
Thanks for reply! So, as I've understood, forging of HS key doesn't allow third party to decrypt client's traffic on guard's side (or on nodes from the client's tor chain, i.e. between client and RP or between client and IP) anyway.
Basically, no information.
Basically, no information. This key is only used for signing, not data encryption.
When I grep /var/lib/tor for RSA keys I find a lot of them in cached-certs, cached-miscrodescs and cached-miscrodescs.new. Suppose, attacker can decrypt RSA1024 in real time, then how much he can do by forging these signatures in tor chain? I guess he can do much, because, otherwise, these signatures would not be used in Tor protocol. Here I speak about usual tor-based clearnet connection, not about HS.
If you read the design
If you read the design documentation or specifications, you would know the answer for this, instead of being totally wrong.
I'm sorry, however, here
I'm sorry, however, here people en mass asking much more stupid questions about Tor than me. To get answer on this question I need to read heavy docs about protocol and then think about all consequences if something is changed. I guess for you it is much simpler to give me the answer than for me to spend a lot of time to fully understand Tor protocol. I also guess that the answer is pretty simple.
I guess you might be a coder
I guess you might be a coder venting at an innocent person because of some frustration in your work. If so, please don't do that in this blog: Tor is far too critical for the safety of ordinary citizens to play games with someone asking a serious question (to which I do not know the answer, unfortunately).
> I guess you might be a
> I guess you might be a coder venting at an innocent person because of some frustration in your work.
You guess wrong.
> Suppose, attacker can decrypt RSA1024 in real time
Then they can break most public key crypto used by Tor, because they have hardware capable of doing large quantum Fourier transforms in excess of what is required to calculate the Elliptic Curve discrete logarithm for a 256 bit curve.
Then they can break most
Then they can break most public key crypto used by Tor, because they have hardware capable of doing large quantum Fourier transforms in excess of what is required to calculate the Elliptic Curve discrete logarithm for a 256 bit curve.
I meant attacker can break RSA1024 in real time using classical algorithms, not quantum! The question is not so hypothetical because long time ago there were some proposals of constructing special hardware to break 1024 keys. E.g., this is proposal from 2001:
> E.g., this is proposal
> E.g., this is proposal from 2001
That's not anywhere near a real time attack, and neither is the modern variant (BatchNFS).
If I were you, I would worry
If I were you, I would worry that 'she' might be decrypting ECC in real-time sooner than breaking 1024 keys.
But maybe without the ECC switch we wouldn't have any tor now, 'cos it might have been game over.
Breaking ED25519 sooner than
Breaking ED25519 sooner than breaking 1024-bit RSA keys?
If you think this is realistic, you should go find a cryptographer and have a chat with them about the state of the art and their predictions for the next few years.
(Here's the short summary for those who don't have a cryptographer handy: ed25519 is one of the strong known ciphers, and 1024-bit RSA is not known to be broken by anybody right now but it's just a matter of years until it is.)
Hey arma, as you are one of
Hey arma, as you are one of the few fortunate ones, you should have a chat over a coffee break with your actual colleague Bruce.
AFAIK, he also seems to not like anything related with finite fields, maybe you should ask him why.
Let me add my 2 coins here.
Let me add my 2 coins here. That rumor is pretty old. It was raised because of NSA suddenly issued statement about forcing people to longer keylengths. NSA explained this recommendation as the result of progress in quantum computing. However, many researchers, including Scott Aaronson, are quite skeptical about that. In part, skepticism comes from the fact that NSA doesn't prey on quantum scientists who work in quantum technologies (like it was during Manhattan project). So, some people made conclusion that the real reason of NSA's issue is not progress in quantum computing, but in cryptography of asymmetric systems (also, probably, in ECC).
At that time I've read many opinions about this thing, and didn't find any real point to worry about. Indeed, progress in quantum computing is going, so it could be the real reason in some near future to move to longer case. However, no serious weaknesses in ECC is known, so, taking into account how speedy it is in comparison to long RSA keys (like 4096), I cannot suggest anybody to avoid ECC and prefer RSA.
tor Full RELRO Canary
tor Full RELRO Canary found Seccomp-bpf PaX enabled PIE enabled Yes
Is that text string supposed
Is that text string supposed to make sense to anyone?
someone showing off its
someone showing off its built tor running on a grsec-enabled linux machine...
DisableNetwork is set. Tor
DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
You're pasting a log line
You're pasting a log line from a Tor Browser. This is a blog post about Tor 0.3.0.6, and there aren't any Tor Browsers that include Tor 0.3.0.6. So I would say you're off-topic.
That said, that particular log line doesn't mean much of anything. If you're having problems getting your Tor to work, look at the other log lines, not that one.
I feel it run much more fast
I feel it run much more fast on my openbsd server.
Well done to the entire Tor
Well done to the entire Tor Team.
Now... please come back Agora! ;)
why isn't available in the
why isn't available in the repository, is something changed?
When will 0.3.0.6 be
When will 0.3.0.6 be available from deb.torproject.org?
Abnormal termination in
Abnormal termination in msvcrt, press OK, and Tor exited!
What were you running? How
What were you running? How were you running it? What version of Windows? Is it repeatable?
TBB 7.0a3. As usual. XP.
TBB 7.0a3. As usual. XP. Never seen this before, not repeatable.
when will we see a stable
when will we see a stable Tor Browser Bundle with this series?
The blog post included an
The blog post included an answer to this one: "Packages should be ready over the next weeks, with a Tor Browser release in late May or early June."
even the source repository
even the source repository only show 3.05 still.
if it so much better why can't we have it?
I guess it depends what you
I guess it depends what you mean by "the source repository".
I see it very clearly on https://dist.torproject.org/
This is for a standalone
This is for a standalone build
For a system build for example on debian stable the repository has been:
http://deb.torproject.org/torproject.org/ tor-experimental-0.3.0.x-jessie main
On all distributions, last I looked, the latest version is 3.0.5
When 3.0.5 came out within 2-3 days the repository had the available update.
Now, 3 weeks later there is still 3.0.5 and for weeks nobody has responded to the same question, way above on the list. Meanwhile most attempts to use bridges obfs4 either hang or are very slow.
Is this because it is no longer experimental but stable?
I suspect it is up to debian
I suspect it is up to debian to audit each package and approve it fot it to be on the debian repository, which pretty much affects half the unix/;linux population. So the question can not be answered here. Debian is too busy with the release of Debian 9 which seems will be stuck with the old stable tor
Any news regarding Orfox,
Any news regarding Orfox, I.e. TOR browser for android? It hasn't received any updates for several months, which makes me worried about its security. I use it nearly for all my browsing.
Also, how about Orbot? Updates?
I've heard the Guardidan
I've heard the Guardidan Project is working on updates to both. That said we'll plan to build a Tor Browser for Mobile (Android) later this year which will supersede Orfox. It should get as regular updates as the Tor Browser for desktop (and should have feature parity as well). So, stay tuned. :)
That's so awesome to hear!
That's so awesome to hear! Thank you guys for not forgetting your mobile users :)
Will this be just like the Tor Browser for desktop (i.e. it comes with its own Tor) or we will always have to rely on Orbot?
The current plan is to do it
The current plan is to do it like Tor Browser on desktop. But that might change to something else in case memory/battery consumption is deemed to be too high with a separate tor.
But please don't forget that
But please don't forget that Orbot is needed to route other apps through TOR, which sets android privacy to another level.
That's why I find it important that orbot development won't halt.
+1 I'm looking forward to
+1 I'm looking forward to this!
Help me one APK for enter
Help me one APK for enter deep web??
Awesome. Very happy to see
Awesome. Very happy to see TP continues to make technical improvements.
Please continue to also work on political/financial/personnel defenses, because the Project itself remains vulnerable in those areas.
A round of applause to the
A round of applause to the Tor project - https://www.viva64.com/en/b/0507/
Post orfox on fdroid and
Post orfox on fdroid and make the script so it doesn't ask any permissions.
Thanks in advance.
Startpage (TorBrowser's default search engine) is now using capchas:
"As part of StartPage's ongoing mission to provide the best experience for our users, we occasionally need to confirm that you are a legitimate user. Completing the CAPTCHA below helps us reduce abuse and improve the quality of our services.
Thank you, The StartPage Team"
FWIW: StartPage is not Tor's…
FWIW: StartPage is not Tor's default search engine, it should be DuckDuckGo on your system (unless you changed that, of course).
how does one know which tor
how does one know which tor is running after building 3.0.6 from source?
I had to disrupt the installation to install 3-4 packages/libraries in order to have a successful build. Then on dpkg it was still showing 3.0.5b so I stopped the service for a 5th time and uninstalled tor/geolib and build ftom source again, Then the browser did run but I was unsure from which tot, I suspected it used the one I built. Tried apt it was still reading from tor+http
I reboot and there is not tor or able connection through tor+http
I reinstalled tor via the open http repository again, 3.0.5 then everything back to normall
I even tried as root it wouldn't stick.
What am I missing?
I have no idea what you're
I have no idea what you're trying to do, or why. You can figure out the version of a running tor instance over the control port (even without authenticating) via the `PROTOCOLINFO` command.
Hi, the WannaCry malware
Hi, the WannaCry malware downloads a Tor client from https://dist.torproject.org/torbrowser/6.5.1/tor-win32-0.2.9.10.zip, can you please remove this file (rename it? Make it require a valid http referer, or some other way to stop automated downloading of it by the malware). Yes the developers will probably adjust where they download the file from, but at least this would help protect systems for a bit longer, especially now that Microsoft has backported the fix to XP.
I'm basing this on the breakdown of the malware at https://www.bleepingcomputer.com/news/security/wannacry-wana-decryptor-…
See this thread on the tor…
See this thread on the tor-relays list:
Just my two cents:…
Just my two cents:
Why not set the standard higher then Ed25519 curve (y^2 = x^3+486662x^2+x)(modulo p = 2^255 - 19)? And go directly to M-511 curve (y^2 = x^3+530438x^2+x)(modulo p = 2^511 - 187).
Ed25519 curve is design to give ~128 bits of security, and M-511 curve is design to give ~250 bits of security.
Depending on the source 128 bits should provide security up to years 2022/ 2040, and 250 bits should provide much more time, if quantum computing capable of breaking this Elliptic Curve Technology doesn't became available before.
So why not skip already Ed25519 and go directly to M-511? The effort is probably not much more and the system can stay secure for much more time!
sorry to try reach u b4…
sorry to try reach u b4 reading available docs, but this seems best to tell first then read for this cause (it may be just me cause total not tech person --- but better to be sure. The point? oh, yes. all of a sudden tor downloads-and-installs with no security by default. "New slider" for security is the message. this came to my notice after reinstalling tor. the reason I reinstalled tor is because all of a sudden onion sites that I visit frequently and for a number of months, they have the padlock X'd out. Warning of site being not suecure and data can be intercepted. What's up. Sorry sorry sorry to waste you time with out reading. i'll do so now, but jeez maybe som'n. dono
That's a new Firefox feature…
That's a new Firefox feature and we are currently thinking about how to deal with it: See: https://trac.torproject.org/projects/tor/ticket/21321