phoul's blog

Announcing the Tor Browser User Manual

The community team is excited to announce the new Tor Browser User Manual!

The manual is currently only available in English. We will be adding more languages in the near future, as well as adding the manual to Transifex.

During the creation of this manual, community feedback was requested over various mailing lists / IRC channels. We understand that many people who read this blog are not part of these lists / channels, so we would like to request that if you find errors in the manual or have feedback about how it could be improved, please open a ticket on our bug tracker and set the component to "community".

This manual is part of an ongoing effort to foster wider adoption of Tor, and provide better support to all users, new and old. We'll soon have some more exciting new developments to share about our user support efforts, so stay tuned.

Thanks for using Tor!

Advisory: remote DoS when using Tor with recent OpenSSL versions built with the "no-ssl3" option

This is a copy of the message Nick Mathewson sent to the tor-talk & tor-relays mailing lists.

Hello, relay operators!

There's one important bugfix in the 0.2.5.9-rc release that relay operators should know about. If you have a version of OpenSSL that came out last week (like 1.0.1j, 1.0.0, ) and if your version of OpenSSL is built with the "no-ssl3" flag, then it's possible to crash your Tor relay remotely if you don't upgrade to 0.2.5.9-rc or to 0.2.4.25 (when that's out).

This appears to be an OpenSSL bug. The Tor releases in question contain a workaround for it.

To tell if your version of OpenSSL was built with 'no-ssl3': run:

openssl s_client -ssl3 -connect www.torproject.org:443

If it gives you output beginning with something like:

CONNECTED(00000003)
140632971298688:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3
alert handshake failure:s3_pkt.c:1257:SSL alert number 40
140632971298688:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl
handshake failure:s3_pkt.c:596:

then you're fine and you don't need to upgrade Tor on your relay. But if it says something that starts with:

unknown option -ssl3
usage: s_client args

then you need to upgrade Tor.

Some questions and answers:

Q: Does this affect clients?
A: No. Only relays.

Q: Does this affect me if I'm running a version of OpenSSL other than 1.0.1j, 1.0.0o, or 0.9.8zc?
A: No. Only those versions.

Q: Does this affect me if I'm running a version of OpenSSL configured without the "no-ssl3" option?
A: No. Only versions that were built with the "no-ssl3" option are affected.

Q: Does the OpenSSL team know?
A: Yes. Have a look at this thread. Also, before I saw that thread, I informed them the other day.

Q: Does this affect Tor packages?
A: I don't think that we shipped any packages where we used the "no-ssl3" flag to diable ssl3. So only if you're using OpenSSL from another source (say, your operating system) will you be affected.

Q: What can I do to remediate this problem?
A: You can upgrade to the most recent Tor, or you can use a version of OpenSSL built without the "no-ssl3" flag. Downgrading your OpenSSL is not recommended.

Q: What is the potential impact of this bug?
A: If a relay is affected by this bug, anybody can make the relay crash remotely. It does not enable any data leaks or remote code execution. Still, the ability to selectively disable relays might enable a sophisticated attacker to do some kinds of traffic analysis more efficiently. So, fix your relay if it's affected.

Q: Should we run in circles and freak out?
A: Not this time. We should just make sure we fix affected relays.

Q: Hey, Nick, you didn't explain this properly!
A: Please send a follow-up message that explains it better. :)

Tor Challenge 2014

We are excited to announce the EFF has just launched the second Tor Challenge!

This challenge is somewhat different from the previous edition, as there are now incentives tied to running relays for an extended period of time. The goal is to educate and encourage lots of people to setup relays, and continue to contribute throughout the year.

EFF will be giving out a "limited-edition" sticker to relay operators who keep their relay running for at least 12 months. On top of that, people running a 1MB/s+ relay for 12 months will also receive a Tor t-shirt!

The more high-bandwidth relays we have, the better off the network is as a whole and the more people we will be able to help stay safe and secure online; so please join the EFF & the Tor Project for the 2014 Tor Challenge! Also, help us spread the word about this challenge by sharing this with others!

tor 0.2.4.22 released

This is a slightly belated announcement for the release of tor 0.2.4.22. Going into the future, we're planning to publish this information on the blog shortly after it is sent to tor-announce.

Release information is always published first on tor-talk.

Tor 0.2.4.22 backports numerous high-priority fixes from the Tor 0.2.5 alpha release series. These include blocking all authority signing keys that may have been affected by the OpenSSL "heartbleed" bug, choosing a far more secure set of TLS ciphersuites by default, closing a couple of memory leaks that could be used to run a target relay out of RAM, and several others.

Here is the complete changelog:

Changes in version 0.2.4.22 - 2014-05-16:

  • Major features (security, backport from 0.2.5.4-alpha):
    • Block authority signing keys that were used on authorities
      vulnerable to the "heartbleed" bug in OpenSSL (CVE-2014-0160). (We
      don't have any evidence that these keys _were_ compromised; we're
      doing this to be prudent.) Resolves ticket 11464.
  • Major bugfixes (security, OOM):
    • Fix a memory leak that could occur if a microdescriptor parse
      fails during the tokenizing step. This bug could enable a memory
      exhaustion attack by directory servers. Fixes bug 11649; bugfix
      on 0.2.2.6-alpha.
  • Major bugfixes (TLS cipher selection, backport from 0.2.5.4-alpha):
    • The relay ciphersuite list is now generated automatically based on
      uniform criteria, and includes all OpenSSL ciphersuites with
      acceptable strength and forward secrecy. Previously, we had left
      some perfectly fine ciphersuites unsupported due to omission or
      typo. Resolves bugs 11513, 11492, 11498, 11499. Bugs reported by
      'cypherpunks'. Bugfix on 0.2.4.8-alpha.

    • Relays now trust themselves to have a better view than clients of
      which TLS ciphersuites are better than others. (Thanks to bug
      11513, the relay list is now well-considered, whereas the client
      list has been chosen mainly for anti-fingerprinting purposes.)
      Relays prefer: AES over 3DES; then ECDHE over DHE; then GCM over
      CBC; then SHA384 over SHA256 over SHA1; and last, AES256 over
      AES128. Resolves ticket 11528.

    • Clients now try to advertise the same list of ciphersuites as
      Firefox 28. This change enables selection of (fast) GCM
      ciphersuites, disables some strange old ciphers, and stops
      advertising the ECDH (not to be confused with ECDHE) ciphersuites.
      Resolves ticket 11438.
  • Minor bugfixes (configuration, security):
    • When running a hidden service, do not allow TunneledDirConns 0:
      trying to set that option together with a hidden service would
      otherwise prevent the hidden service from running, and also make
      it publish its descriptors directly over HTTP. Fixes bug 10849;
      bugfix on 0.2.1.1-alpha.
  • Minor bugfixes (controller, backport from 0.2.5.4-alpha):
    • Avoid sending a garbage value to the controller when a circuit is
      cannibalized. Fixes bug 11519; bugfix on 0.2.3.11-alpha.
  • Minor bugfixes (exit relay, backport from 0.2.5.4-alpha):
    • Stop leaking memory when we successfully resolve a PTR record.
      Fixes bug 11437; bugfix on 0.2.4.7-alpha.
  • Minor bugfixes (bridge client, backport from 0.2.5.4-alpha):
    • Avoid 60-second delays in the bootstrapping process when Tor is
      launching for a second time while using bridges. Fixes bug 9229;
      bugfix on 0.2.0.3-alpha.
  • Minor bugfixes (relays and bridges, backport from 0.2.5.4-alpha):
    • Give the correct URL in the warning message when trying to run a
      relay on an ancient version of Windows. Fixes bug 9393.
  • Minor bugfixes (compilation):
    • Fix a compilation error when compiling with --disable-curve25519.
      Fixes bug 9700; bugfix on 0.2.4.17-rc.
  • Minor bugfixes:
    • Downgrade the warning severity for the the "md was still
      referenced 1 node(s)" warning. Tor 0.2.5.4-alpha has better code
      for trying to diagnose this bug, and the current warning in
      earlier versions of tor achieves nothing useful. Addresses warning
      from bug 7164.
  • Minor features (log verbosity, backport from 0.2.5.4-alpha):
    • When we run out of usable circuit IDs on a channel, log only one
      warning for the whole channel, and describe how many circuits
      there were on the channel. Fixes part of ticket 11553.
  • Minor features (security, backport from 0.2.5.4-alpha):
    • Decrease the lower limit of MaxMemInCellQueues to 256 MBytes (but
      leave the default at 8GBytes), to better support Raspberry Pi
      users. Fixes bug 9686; bugfix on 0.2.4.14-alpha.
  • Documentation (backport from 0.2.5.4-alpha):
    • Correctly document that we search for a system torrc file before
      looking in ~/.torrc. Fixes documentation side of 9213; bugfix on
      0.2.3.18-rc.
Syndicate content Syndicate content