A new OpenSSL vulnerability on 1.0.1 through 1.0.1f is out today, which can be used to reveal memory to a connected client or server.
If you're using an older OpenSSL version, you're safe.
Note that this bug affects way more programs than just Tor — expect everybody who runs an https webserver to be scrambling today. If you need strong anonymity or privacy on the Internet, you might want to stay away from the Internet entirely for the next few days while things settle.
Here are our first thoughts on what Tor components are affected:
- Clients: The browser part of Tor Browser shouldn't be affected, since it uses libnss rather than openssl. But the Tor client part is: Tor clients could possibly be induced to send sensitive information like "what sites you visited in this session" to your entry guards. If you're using TBB we'll have new bundles out shortly; if you're using your operating system's Tor package you should get a new OpenSSL package and then be sure to manually restart your Tor. [update: the bundles are out, and you should upgrade]
- Relays and bridges: Tor relays and bridges could maybe be made to leak their medium-term onion keys (rotated once a week), or their long-term relay identity keys. An attacker who has your relay identity key can publish a new relay descriptor indicating that you're at a new location (not a particularly useful attack). An attacker who has your relay identity key, has your onion key, and can intercept traffic flows to your IP address can impersonate your relay (but remember that Tor's multi-hop design means that attacking just one relay in the client's path is not very useful). In any case, best practice would be to update your OpenSSL package, discard all the files in keys/ in your DataDirectory, and restart your Tor to generate new keys. (You will need to update your MyFamily torrc lines if you run multiple relays.) [update: we've cut the vulnerable relays out of the network]
- Hidden services: Tor hidden services might leak their long-term hidden service identity keys to their guard relays. Like the last big OpenSSL bug,
this shouldn't allow an attacker to identify the location of the hidden service[edit: if it's your entry guard that extracted your key, they know where they got it from]. Also, an attacker who knows the hidden service identity key can impersonate the hidden service. Best practice would be to move to a new hidden-service address at your convenience.
- Directory authorities: In addition to the keys listed in the "relays and bridges" section above, Tor directory authorities might leak their medium-term authority signing keys. Once you've updated your OpenSSL package, you should generate a new signing key. Long-term directory authority identity keys are offline so should not be affected (whew). More tricky is that clients have your relay identity key hard-coded, so please don't rotate that yet. We'll see how this unfolds and try to think of a good solution there.
- Tails is still tracking Debian oldstable, so it should not be affected by this bug.
- Orbot looks vulnerable; they have some new packages available for testing.
- The webservers in the https://www.torproject.org/ rotation needed (and got) upgrades. Maybe we'll need to throw away our torproject SSL web cert and get a new one too.
UPDATE: Don't upgrade to these bundles. The version of OpenSSL in these bundles -- even though it fixes some bugs -- introduces new bugs that will prevent Tor from working on many computers. See the following links for more information:
- Watch out for openssl 1.0.1d if you're using AESNI
- stitched aes-ni ciphers in openssl 1.0.1d seems to break SSL Handshakes/Renegotiations
Please continue using the old bundles. All of the download links have been downgraded to the previous version. We will release updated bundles in a few days. Thanks.
All of the bundles have been updated. The alpha bundles contain the latest Tor 0.2.4.10-alpha and all of the bundles have received an OpenSSL update (1.0.1d for everything except the PPC Vidalia bundles which have 0.9.8y). The regular obfsproxy bundles have been discontinued but pyobfsproxy/flashproxy bundles are available from the obfsproxy page. We plan to begin shipping these as part of the regular release cycle within the next month or two.
Tor Browser Bundle (2.3.25-3)
- Update OpenSSL to 1.0.1d
- Update HTTPS Everywhere to 3.1.3
- Update NoScript to 18.104.22.168
Tor Browser Bundle (2.4.10-alpha-1)
- Update Tor to 0.2.4.10-alpha
- Update OpenSSL to 1.0.1d
- Update NoScript to 22.214.171.124
- Add PDF Viewer (PDF.js) to README
The Tor Browser Bundles have all been updated to the latest Firefox 12.0 as well as a number of other software updates, bugfixes, and new features. We've rebranded Firefox so it should now be more easy to distinguish between it and your normal Firefox. We've also added Korean and Vietnamese to the available languages.
UPDATE: The Mac OS X 64-bit bundles had a minor Vidalia problem that prevented TorBrowser from being launched. They have been updated to 2.2.35-9.1 and are now available on the website.
Tor Browser Bundle (2.2.35-9)
- Update Firefox to 12.0
- Update OpenSSL to 1.0.1b
- Update Libevent to 2.0.18-stable
- Update Qt to 4.8.1
- Update Libpng to 1.5.10
- Update HTTPS Everywhere to 2.0.2
- Update NoScript to 2.3.9
- Rebrand Firefox to TorBrowser (closes: #2176)
- New Firefox patches
- Make Download Manager memory-only (closes: #4017)
- Add DuckDuckGo and Startpage to Omnibox (closes: #4902)
- Add Steven Michaud's OS X crash fix patch. It doesn't fix #5021 but will hopefully help us debug further. See also:
- Make the 32-bit Tor Browser Bundle compatible with OS X 10.5
The Tor Browser Bundles have all been updated to the latest Firefox (10.0) as well as a number of other software version updates.
Tor Browser Bundle (2.2.35-5)
- Update Firefox to 10.0
- Update Qt to 4.7.4
- Update OpenSSL to 1.0.0g
- Update zlib to 1.2.6
- Update HTTPS Everywhere to 1.2.2
- Update NoScript to 2.2.8
- New Firefox patches
- Limit the number of fonts per document
- Put documentation in remove-shared-lib-symlinks debug dumps (closes: #4984)
- Make sure mozconfig always gets copied into the Firefox build directory
Yet another OpenSSL security patch broke its compatibility with Tor:
Tor 0.2.2.19-alpha makes relays work with OpenSSL 0.9.8p and 1.0.0.b.
The original announcement is at http://archives.seul.org/or/talk/Nov-2010/msg00172.html
Changes in version 0.2.2.19-alpha - 2010-11-21
- Resolve an incompatibility with openssl 0.9.8p and openssl 1.0.0b:
No longer set the tlsext_host_name extension on server SSL objects;
but continue to set it on client SSL objects. Our goal in setting
it was to imitate a browser, not a vhosting server. Fixes bug 2204;
bugfix on 0.2.1.1-alpha.
- Try harder not to exceed the maximum length of 50 KB when writing
Minor bugfixes: read more »
There's a new buffer overflow vulnerability in versions of OpenSSL from 0.9.8f through 0.9.8o, and 1.0.0 through 1.0.0a. You can read the security advisory for the whole story.
So far as we can tell from our current analysis, Tor is not affected. Here's why:
The advisory says:
Any OpenSSL based TLS server is vulnerable if it is multi-threaded and uses OpenSSL's internal caching mechanism. Servers that are multi-process and/or disable internal session caching are NOT affected.
Tor qualifies for both of the safe cases: Tor does disable OpenSSL's internal session caching. This happens in the file src/common/tortls.c, when we call SSL_CTX_set_session_cache_mode(result->ctx,SSL_SESS_CACHE_OFF). Tor has done this since since version 0.0.2pre6 back in 2003. read more »
Apple responded to my bug report about a broken openssl. I've since built test packages for OS X 10.5 and 10.6 users. Their response is:
Thank you for your report of this issue with Tor.
The issue you're seeing is because the current versions of the development tools were created before the OpenSSL security fix, and so do not include the "SSL3_FLAGS_ALLOW_UNSAFE_LEGACY_RENEGOTIATION" definition in the OpenSSL headers.
You can work around this issue by supplying the definition to Tor directly, for example by compiling Tor using
CPPFLAGS='-DSSL3_FLAGS_ALLOW_UNSAFE_LEGACY_RENEGOTIATION=0x0010' ./configure && make
This will work on both Leopard and Snow Leopard.
If you have an Intel (i386) Mac, use the normal i386 packages for Tor 0.2.2.8-alpha release at https://www.torproject.org/download.
If you have a PowerPC (ppc) Mac AND are running OS X 10.5 or 10.6, use these packages: read more »
Apple OS X Security Update 2010-001 removes OpenSSL renegotation, http://support.apple.com/kb/HT1222. We've filed a bug report with Apple on this issue. Their standard response so far is http://support.apple.com/kb/HT4004.
In the meanwhile, we have bug #1225 open, https://bugs.torproject.org/flyspray/index.php?do=details&id=1225. Add yourself to the Notifications if you want updates as they happen. A fine explanation of why Tor is not affected by the TLS renegotiation bug can be found at https://bugs.torproject.org/flyspray/index.php?do=details&id=1225&area=c...
Packages for testing are available at:
READ THIS FINE PRINT: read more »
- These will only work on OSX 10.5 and 10.6 (both i386 and powerpc). Tor fails to compile when using the 10.4 libraries and static openssl.
- Tor-0.2.2.8-alpha-i386-Bundle.dmg is compiled to replace the tor
On November 19, we released the latest in the Tor alpha series, version 0.2.2.6-alpha. This release lays the groundwork for many upcoming features:
support for the new lower-footprint "microdescriptor" directory design,
future-proofing our consensus format against new hash functions or
other changes, and an Android port. It also makes Tor compatible with
the upcoming OpenSSL 0.9.8l release, and fixes a variety of bugs.
It can be downloaded at https://www.torproject.org/download.html.en
- Directory authorities can now create, vote on, and serve multiple
parallel formats of directory data as part of their voting process.
Partially implements Proposal 162: "Publish the consensus in
- Directory authorities can now agree on and publish small summaries
of router information that clients can use in place of regular
server descriptors. This transition will eventually allow clients read more »