Tor 0.3.0.3-alpha is released:
Posted February 3rd, 2017 by nickm
Tor 0.3.0.3-alpha fixes a few significant bugs introduced over the 0.3.0.x development series, including some that could cause authorities to behave badly. There is also a fix for a longstanding bug that could prevent IPv6 exits from working. Tor 0.3.0.3-alpha also includes some smaller features and bugfixes.
The Tor 0.3.0.x release series is now in patch-freeze: no additional features will be considered for inclusion in 0.3.0.x. We suspect that some bugs will probably remain, however, and we encourage people to test this release.
You can download the source code from the usual place on the website, but most users should wait for packages to become available over the upcoming weeks.
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.3.0.2-alpha:
Changes in version 0.3.0.3-alpha - 2017-02-03
- 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.
- When deciding whether we have just found a router to be reachable, do not penalize it for not having performed an Ed25519 link handshake if it does not claim to support an Ed25519 handshake. Previously, we would treat such relays as non-running. Fixes bug 21107; bugfix on 0.3.0.1-alpha.
- Major bugfixes (entry guards):
- Stop trying to build circuits through entry guards for which we have no descriptor. Also, stop crashing in the case that we *do* accidentally try to build a circuit in such a state. Fixes bug 21242; bugfix on 0.3.0.1-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.
- 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 features (ciphersuite selection):
- Clients now advertise a list of ciphersuites closer to the ones preferred by Firefox. Closes part of ticket 15426.
- Allow relays to accept a wider range of ciphersuites, including chacha20-poly1305 and AES-CCM. Closes the other part of 15426.
- 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 (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 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 (client):
- Minor bugfixes (client, entry guards):
- Fix a bug warning (with backtrace) when we fail a channel that circuits to fallback directories on it. Fixes bug 21128; bugfix on 0.3.0.1-alpha.
- Fix a spurious bug warning (with backtrace) when removing an expired entry guard. Fixes bug 21129; bugfix on 0.3.0.1-alpha.
- Fix a bug of the new guard algorithm where tor could stall for up to 10 minutes before retrying a guard after a long period of no network. Fixes bug 21052; bugfix on 0.3.0.1-alpha.
- Do not try to build circuits until we have descriptors for our primary entry guards. Related to fix for bug 21242.
- 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 (controller):
- Restore the (deprecated) DROPGUARDS controller command. Fixes bug 20824; bugfix on 0.3.0.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.
- 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.
- 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.
- 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.
- When mapping a file of length greater than SIZE_MAX, do not silently truncate its contents. This issue could occur on 32 bit systems with large file support and files which are larger than 4 GB. Fixes bug 21134; bugfix on 0.3.0.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 (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.
where can i find research into vulnerabilities of tor hidden services? i want to help
anywhere you think is necessary, I dont know enough about it, im learning as i go along,not easy, i'm on y wn cant get help anywhere. Simona
Best place to look for research regarding anonymity in general:
https://www.freehaven.net/anonbib/
Some papers which presented interesting attacks on hidden services:
https://www.freehaven.net/anonbib/#hs-attack06
https://www.freehaven.net/anonbib/#oakland2013-trawling
Blog posts:
https://blog.torproject.org/blog/
improving-tors-anonymity-changing-guard-parameters
Open Ticket regarding attacks on hidden services:
https://trac.torproject.org/projects/tor/ticket/9001
Proposals on the topic:
https://gitweb.torproject.org/torspec.git/tree/
proposals/224-rend-spec-ng.txt
https://gitweb.torproject.
org/torspec.git/tree/proposals/247-hs-guard-discovery.txt
https://gitweb.torproject.org/
torspec.git/tree/proposals/250-commit-reveal-consensus.txt
How can I verify authenticity of my current tor installation?
I have a bad feeling since the last (automatic) update. Thank you.
It's really hard to figure out what's installed once it's been installed and used.
Your best bet if you're nervous is to get rid of it and install a fresh one (and check the signature on the fresh one).
how can I tell or check?
https://www.torproject.org/docs/verifying-signatures
is the right starting point.
To get what's probably a better explanation about checking signatures in general, read the Tails documentation:
https://tails.boum.org/install/download/openpgp/index.en.html
I appreciate all your replies.
I read about signature verification of the zip file regarding manual installation.
I'd like to verify the whole Tor bundle AFTER an automatic update which I didn't trigger myself.
If there is an (automatic) signature verification process involved, it's transparent for the user and not acceptable in terms of security. We need feedback on this.
Think about a possible man-in-the-middle attack by a malicious exit-node redirecting your current tor browser to a 'modified' update / installation file (by spoofing the ips of torproject.org or the key server). In a talk Roger mentioned certain obsolete certificates being still implemented in the firefox browser engine. What if some 3-letter-agency was able to get or buy one? Your tor bundle could come with malware unnoticed. This attack scenario is bothering me since the beginning of tor.
The updates are signed with a signing key. Thus, a man-in-the-middle doing some redirections to a modified update file won't have any success unless this update got signed with the update signing key, too.
Don't get me wrong. Tor is the best We've got and I'm very thankful for it.
But there's still room for improvement.
It shows the same IP address every time you open the drop menu.... same places as well.
I assume you're talking about Tor Browser, not about the core Tor program (which has no drop menu).
It sounds like you're asking why the first relay in your circuit is the same all the time? If so, check out:
https://www.torproject.org/docs/faq#EntryGuards
and for way way more information if you want it, check out
https://blog.torproject.org/blog/improving-tors-anonymity-changing-guard-parameters
why doesn't tails allow persistent uers to keep their entry guards? especially for users who use tails daily?
It's a known issue currently, they're working on it: https://labs.riseup.net/code/issues/5462
that ticket has existed for 3 years and they still haven't found a solution! im very worried about this vulnerability!
May you ask Dutch intelligence to help you to harden your using the net.
They are VERY interested in that the normal tor user can using
Tails(TBB) like TBB on MSWindows with persistent Entry Guards and without a trojanized system (-:
https://www.burojansen.nl/bvd-aivd/dutch-secret-service-tries-to-recruit-tor-admin/
"[...] they were mostly interested in building a community of techies around the developers of Tor and Tails and that it would be an international effort."
hi,
Some rotten cop do the same (hiding their personal & illegal habits by this way) - even if this story could seem interesting for yourself ( i thing it is a bullshit) i would like insist on 2 important things :
* ask a contract
* ask to be payed
= Now you know why and how much you are valued : money is the right weight.
** ask their name & take their photo, ask someone else to be present , afaik working or accepting a job is not illegal or secret - the recruitment is hard & complex and never done in a street or at a bar except in the spy-movies.
(secret service rarely recruit unstable or vulnerable person- it is in almost all the case the opposite)
i would like add that "informant" is the downiest job given by a police force to a citizen so it is certainly more an insult than a compliment (like spoiling a code or implementing a backdoor). .
thx.
I remember some time ago I saw service (maybe on torproject.org) which shows the whole history of particular tor relay (IP): when it was online, when it was offline during the whole its history as tor relay. So, I could retrospectively check it all. Now I see only uptime value on atlas and date of relay creation at blutmagie.de. Could you remind me where that stat page of particular relay was?
Can you give us some more hints? I was going to point you to https://atlas.torproject.org/ but then you mentioned it.
Oh! Maybe you are talking about https://globe.torproject.org/ ? It used to be another website like atlas but displaying things differently. Atlas has all the content that Globe had.
Ultimately, that data comes from onionoo.torproject.org.
Thanks, Roger! Finally, I found it! It was exonerator. Initially it was hosted (e.g. in 2012) at https://metrics.torproject.org/exonerator.html. Now it is (I don't know why) removed from metrics and moved to https://exonerator.torproject.org. However, it gives stat (all uptimes and downtimes) only for particular day, not for the whole history. Why it is not part of onionoo?
P.S. I would be very happy if you could reply also on this my old comment: https://blog.torproject.org/comment/reply/1297/232924
which is from old topic: https://blog.torproject.org/blog/tor-0299-released
Is there 64-bit version of Tor and Tor-Browser coming to Windows soon?
We hope to have 64-bit Windows support in our alpha series sometime this week. It is on our agenda but won't definitely show up before June as we are doing the transition to Firefox ESR 52 until then.
Any hope for an apple app?
Tor Browser already works on OSX.
I think he talks about iOS
My tor browser is running very slow and it's not showing the whole websites anymore that it does before. What can this be?
Can you add more details? And which website if possible? What are you security settings?
When do you expect to have the new generation of hidden service in production and ready to use?
Sometime in 2017 is the plan.
I'm usually not on the bleeding edge but I've managed to get this version running. First, why is relaying disabled by default? And secondly, the ARM notices are of the nature of Average packaged cell fullness percentage, TLS write overhead percentage, uptime, 0 circuits on, kB sent & MB received. Is this useful information? And is this a useful node as it is now operating? Thanks.
It totally depends how you configured your Tor.
If it's a relay (meaning you set your ORPort), you can look yourself up in https://atlas.torproject.org/
As for what 'arm' tells you, some relay operators find the arm tool to be useful, and others not so much. It really depends on you. Also note that arm hasn't been updated for some years, so it's starting to show some sharp edges.
And as for why the Tor program is not a relay by default... you might enjoy
https://www.torproject.org/docs/faq#EverybodyARelay
Thanks!
Post new comment