openssl

Apple workaround for openssl issues on OS X 10.5 and 10.6

phobos — Sun, 31 Jan 2010 19:10:14 -0800

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:

Tor Expert: https://www.torproject.org/dist/osx-old/Tor-0.2.2.8-alpha-i386-10.5-10.6... and .asc.

Vidalia Bundle: https://www.torproject.org/dist/vidalia-bundles/vidalia-bundle-0.2.2.8-a... and .asc.

If you have a PowerPC (ppc) Mac AND ARE running OS X 10.3 or 10.4, use the normal ppc packages at https://www.torproject.org/download.

This can be confusing. I now maintain two different PowerPC packages. One set for pre-10.5 and one set for 10.5 and later OS X versions. This is because Apple didn't update 10.3 nor 10.4 for the openssl bug.

Apple broke OpenSSL which breaks Tor on OS X

phobos — Wed, 27 Jan 2010 10:14:35 -0800

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:
https://www.torproject.org/dist/testing/

READ THIS FINE PRINT:

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
binaries in /Applications/Vidalia.app/Contents/MacOS only. If your tor
is located elsewhere, compile your own for now.
let us know if they work for you. My testing systems show it works
for me. Update
https://bugs.torproject.org/flyspray/index.php?do=details&id=1225 if it
doesn't work or you have other issues with these testing packages.

I'm still working on os x 10.4 packages.

Tor 0.2.2.6-alpha released

phobos — Wed, 02 Dec 2009 21:29:12 -0800

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

Major features:

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
multiple flavors".
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
to use far less bandwidth for downloading information about the
network. Begins the implementation of Proposal 158: "Clients
download consensus + microdescriptors".
The directory voting system is now extensible to use multiple hash
algorithms for signatures and resource selection. Newer formats
are signed with SHA256, with a possibility for moving to a better
hash algorithm in the future.
New DisableAllSwap option. If set to 1, Tor will attempt to lock all
current and future memory pages via mlockall(). On supported
platforms (modern Linux and probably BSD but not Windows or OS X),
this should effectively disable any and all attempts to page out
memory. This option requires that you start your Tor as root --
if you use DisableAllSwap, please consider using the User option
to properly reduce the privileges of your Tor.
Numerous changes, bugfixes, and workarounds from Nathan Freitas
to help Tor build correctly for Android phones.

Major bugfixes:

Work around a security feature in OpenSSL 0.9.8l that prevents our
handshake from working unless we explicitly tell OpenSSL that we
are using SSL renegotiation safely. We are, but OpenSSL 0.9.8l
won't work unless we say we are.

Minor bugfixes:

Fix a crash bug when trying to initialize the evdns module in
Libevent 2. Bugfix on 0.2.1.16-rc.
Stop logging at severity 'warn' when some other Tor client tries
to establish a circuit with us using weak DH keys. It's a protocol
violation, but that doesn't mean ordinary users need to hear about
it. Fixes the bug part of bug 1114. Bugfix on 0.1.0.13.
Do not refuse to learn about authority certs and v2 networkstatus
documents that are older than the latest consensus. This bug might
have degraded client bootstrapping. Bugfix on 0.2.0.10-alpha.
Spotted and fixed by xmux.
Fix numerous small code-flaws found by Coverity Scan Rung 3.
If all authorities restart at once right before a consensus vote,
nobody will vote about "Running", and clients will get a consensus
with no usable relays. Instead, authorities refuse to build a
consensus if this happens. Bugfix on 0.2.0.10-alpha; fixes bug 1066.
If your relay can't keep up with the number of incoming create
cells, it would log one warning per failure into your logs. Limit
warnings to 1 per minute. Bugfix on 0.0.2pre10; fixes bug 1042.
Bridges now use "reject *:*" as their default exit policy. Bugfix
on 0.2.0.3-alpha; fixes bug 1113.
Fix a memory leak on directory authorities during voting that was
introduced in 0.2.2.1-alpha. Found via valgrind.

The original announcement can be found at http://archives.seul.org/or/talk/Nov-2009/msg00106.html

June 2008 Progress Report

phobos — Tue, 22 Jul 2008 20:25:34 -0700

Torbutton 1.2.0rc1 (released June 1), the first release candidate for the next stable series of the security-enhanced Torbutton Firefox extension, features functional support for Firefox 3. However, this support has not been extensively tested. In particular, timezone masking does not work at all. The workaround is to manually set the environment variable 'TZ' to 'UTC' before starting Firefox. This works on both Linux and Windows:
http://archives.seul.org/or/talk/Jun-2008/msg00044.html

Tor 0.2.0.27-rc (released June 3) adds a few features we left out of the earlier release candidates. In particular, we now include an IP-to-country GeoIP database, so controllers can easily look up what country a given relay is in, and so bridge relays can give us some sanitized summaries about which countries are making use of bridges. (See proposal 126-geoip-fetching.txt for details.)
http://archives.seul.org/or/talk/Jun-2008/msg00055.html

Torbutton 1.2.0rc2 (released June 8) features a fix for an annoying bug on MacOS, and adds much clamored for options to start Firefox in a specific Tor state:
http://archives.seul.org/or/talk/Jun-2008/msg00103.html

Tor 0.2.0.28-rc (released June 13) fixes an anonymity-related bug, fixes a hidden-service performance bug, and fixes a bunch of smaller bugs.
http://archives.seul.org/or/talk/Jun-2008/msg00165.html

Tor 0.2.1.1-alpha (released June 13) fixes a lot of memory fragmentation problems that were making the Tor process bloat especially on Linux; makes our TLS handshake blend in better; sends "bootstrap phase" status events to the controller, so it can keep the user informed of progress (and problems) fetching directory information and establishing circuits; and adds a variety of smaller features. http://archives.seul.org/or/talk/Jun-2008/msg00185.html

Vidalia 0.1.4 (released June 13) adds a bootstrap progress bar, UPnP support, a new set of freely licensed GUI icons, and fixes a few bugs.
http://trac.vidalia-project.net/browser/vidalia/tags/vidalia-0.1.4/CHANG...

The Tor Browser Bundle 1.1.0 (released June 13) replaces startup batch script with application (RelativeLink) so there is a helpful icon, optionally installs Pidgin (for Tor IM Browser Bundle), optionally uses WinRAR to produce a self-extracting split bundle, and includes upgraded versions of Tor, Vidalia, and Torbutton.
https://svn.torproject.org/svn/torbrowser/trunk/README

Tor 0.2.1.2-alpha (released June 20) includes a new "TestingTorNetwork" config option to make it easier to set up your own private Tor network; fixes several big bugs with using more than one bridge relay; fixes a big bug with offering hidden services quickly after Tor starts; and uses a better API for reporting potential bootstrapping problems to the controller.
http://archives.seul.org/or/talk/Jun-2008/msg00247.html

Vidalia 0.1.5 (released June 21) switches Vidalia's internal string representation so it can use the new Pootle-based translation system.
http://trac.vidalia-project.net/browser/vidalia/tags/vidalia-0.1.5/CHANG...

Torbutton 1.2.0rc3 and 1.2.0rc4 (both released June 27) provide improved addon compatibility, better preservation of Firefox preferences that we touch, fixing issues with Tor toggle breaking for some option combos, and an improved 'Restore Defaults' button.
https://torbutton.torproject.org/dev/CHANGELOG

We finally got around to writing down the details of many of our architecture and technical design changes:

Proposal 137 ("Keep controllers informed as Tor bootstraps") modifies Tor so it keeps Vidalia informed of each "bootstrap phase" -- that is, progress Tor makes at learning directory information, making connections to the network, etc. Now Vidalia has a progress bar on Tor startup that explains what's going on. Further, Tor reports "bootstrap problems" when it believes it's having troubles starting up correctly, and Vidalia can now tell the user. All of this is in as of the Tor 0.2.1.2-alpha release (June 20).
https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/137-bootstra...

Proposal 138 ("Remove routers that are not Running from consensus documents") modifies the directory "networkstatus consensus" documents so they no longer list relays that are believed to be unusable. They used to list these relays so clients could decide for themselves, but in practice clients just ignored them. This change saves 30% to 40% in download bandwidth for consensus documents. It is included in the 0.2.1.2-alpha release (June 20).
https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/138-remove-d...

Proposal 139 ("Download consensus documents only when it will be trusted") tries to make Tor clients better handle the case when new directory authorities have been added to the system, or when directory authorities have changed (for example, this could happen if we have another bug like the one in May that caused us to change keys for half the directory authorities). Now clients specify which directory authorities they trust, so the directory mirrors can give them a consensus document they'll be willing to use. This change is included in Tor 0.2.1.1-alpha, and a bugfix on it was included in Tor 0.2.1.2-alpha.
https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/139-conditio...

Proposal 140 ("Provide diffs between consensuses") is still under development, but is scheduled to be included in the Tor 0.2.1.x tree. The idea is that most parts of the consensus document don't change from one hour to the next, so we can give clients a diff on the previous one rather than a whole new document, changing the size of the document every client must download every few hours from 92KB on average to 13KB on average.
https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/140-consensu...

Proposal 141 ("Download server descriptors on demand") is still under discussion, and may not be ready until for inclusion until Tor 0.2.2.x. This is the more detailed version of our "grand scaling plan" first mentioned in April. The idea is to have clients download networkstatus consensus documents as they do now, but rather than preemptively fetching every relay descriptor just in case, they fetch descriptors "just in time" only when they need them. The trick is to keep the bandwidth overhead low while not introducing too many new anonymity attacks e.g. due to leaking which relays you're picking.
https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/141-jit-sd-d...

We've instrumented a Tor client to collect stats on how much bandwidth we use now for directory overhead and how much we'd save with this new approach:
http://archives.seul.org/or/dev/Jun-2008/msg00024.html

Proposals 142 ("Combine Introduction and Rendezvous Points") and 143 ("Improvements of Distributed Storage for Tor Hidden Service Descriptors") are still in the discussion phase. Their goal is to improve the experience for clients accessing Tor hidden services, both by making the handshake faster and by making hidden service reachability more reliable and more robust.
https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/142-combine-...
https://svn.torproject.org/svn/tor/trunk/doc/spec/proposals/143-distribu...

The "spoofing Firefox cipher suites and extensions" features are now in the Tor 0.2.1.1-alpha release, meaning they're in the Tor Browser Bundle 1.1.0 release also. From the 0.2.1.1-alpha ChangeLog:
"More work on making our TLS handshake blend in: modify the list of ciphers advertised by OpenSSL in client mode to even more closely resemble a common web browser. We cheat a little so that we can advertise ciphers that the locally installed OpenSSL doesn't know about."

We've done some initial security auditing (though there's always room for more, and we plan to do some more concrete auditing in July).

Nick also wrote some early thoughts on doing pass-through to an Apache server to improve scanning resistance:
http://archives.seul.org/or/dev/Jun-2008/msg00014.html

We also looked into running two Firefoxes in parallel:
https://svn.torproject.org/svn/torbrowser/trunk/docs/two-firefox.txt
and we even hacked in some Torbutton fixes that will come out in version 1.2.0rc3 that should get us closer:
http://archives.seul.org/or/cvs/Jun-2008/msg00213.html

Speaking of which, we also hacked in another feature in Torbutton 0.1.2rc2, to add a "locked" mode so Tor Browser Bundle can start Torbutton and not fear that the user will click and disable Tor. I believe TBB 1.1.0 doesn't use this feature yet though.
http://archives.seul.org/or/cvs/Jun-2008/msg00186.html

From the Tor 0.2.1.2-alpha ChangeLog:
"If you have more than one bridge but don't know their digests, you would only learn a request for the descriptor of the first one on your list. (Tor considered launching requests for the others, but found that it already had a connection on the way for $0000...0000 so it didn't open another.) Bugfix on 0.2.0.x."
"If you have more than one bridge but don't know their digests, and the connection to one of the bridges failed, you would cancel all pending bridge connections. (After all, they all have the same digest.) Bugfix on 0.2.0.x."
"If you're using bridges, generate "bootstrap problem" warnings as soon as you run out of working bridges, rather than waiting for ten failures -- which will never happen if you have less than ten bridges."

We put up a new webpage to describe bridges, how to fetch bridge relay addresses, etc:
https://www.torproject.org/bridges

We also modified the BridgeDB database (that is, the server that runs https://bridges.torproject.org/ and answers mail to bridges@torproject.org) to autodetect if the address hitting https://bridges.torproject.org/ is currently a Tor exit relay, and if so to treat it specially -- that is, we reserve a set of bridge addresses and give those out only to folks coming in over Tor.

The updated BridgeDB version now makes sure to give out at least one bridge that's listed as Stable in the bridge authority's networkstatus document, and at least one bridge that listens on port 443. The goal here is to increase the odds that at least one of the bridges we give the user will be usable even if he's in a tightly firewalled situation.

From the Tor 0.2.0.27-rc ChangeLog:
"Include an IP-to-country GeoIP file in the tarball, so bridge relays can report sanitized summaries of the usage they're seeing."

We finished work on a patch for OpenSSL that will make it keep less buffer space around. Currently fast Tor relays use (waste) as much as 100M of memory in OpenSSL's buffers. This patch was accepted and included in the main OpenSSL tree in June:
http://marc.info/?l=openssl-cvs&m=121246471627426&w=2

The Vidalia 0.1.4 release has folded the UPnP library and GUI changes into the main Vidalia tree, along with a "test" button to try speaking UPnP at the local router and tell the user whether it worked; these features will be available by default in the 0.2.0.x stable release.

We've put a lot of effort into reducing Tor's memory footprint again. The main issue was a "memory fragmentation" problem in Linux's memory allocator, which was causing Tor servers on Linux to slowly grow without bound. As of Tor 0.2.1.2-alpha, the issue appears to be substantially better. Many more details are here:
http://archives.seul.org/or/dev/Jun-2008/msg00001.html

From the Tor 0.2.1.2-alpha ChangeLog:
"New TestingTorNetwork config option to allow adjustment of previously constant values that, while reasonable, could slow bootstrapping. Implements proposal 135. Patch from Karsten Loesing."
"When building a consensus, do not include routers that are down. This will cut down 30% to 40% on consensus size. Implements proposal 138."

We've added clear user-oriented instructions for the Tor Browser Bundle split-download page:
https://www.torproject.org/torbrowser/split.html.en

We're starting work on a "gettor" email auto-responder script that will let people mail gettor@torproject.org and retrieve a copy of Tor from their mailbox. More info forthcoming in July.

More generally, we have a new https://www.torproject.org/finding-tor page that describes various mechanisms such as mirrors.

In July we plan to deploy a more automated mechanism for tracking which Tor mirrors are up-to-date.

We have our translation server up and online:
https://translation.torproject.org/

We have imported the strings from Vidalia, Torbutton, and Torcheck, and we currently have active translations for Spanish, French, German, Italian, Polish, Romanian, Swedish, Turkish, Finnish, Russian, Chinese, and Arabic.

We have a more useful overall translation tutorial here:
https://www.torproject.org/translation-portal

And we have internal documentation here for how to deal with the translation stuff behind the scenes:
https://svn.torproject.org/svn/tor/trunk/doc/translations.txt

In July we plan to add the strings for Vidalia's installer; the challenge is that we need to write a script to convert from the "nsh" (nullscript installer language) format to the "po" (preferred by Pootle) format and back.

In July we also expect to see the first version of our "wml to po and back" conversion tool, that will allow us to start putting our website pages into the translation server.

The Debian OpenSSL flaw: what does it mean for Tor clients?

arma — Tue, 13 May 2008 18:22:24 -0700

There have been a lot of questions today about just what the
recent Debian OpenSSL flaw means for Tor clients. Here's an attempt to
explain it in a bit more detail. (Go read the Tor security advisory before
reading this post.)

First, let's look at the security/anonymity implications for users who
aren't running on Debian, Ubuntu, or similar. These implications all
stem from the fact that some of the Tor relays and v3 directory authorities
have weak keys, so the Tor network isn't able to provide as much anonymity
as we would like.

The biggest issue is that perhaps 300 Tor relays were running with
weak keys and weak crypto, out of the roughly 1500-2000 total running
relays. What can an attacker do from this? If you happen to pick three
weak relays in a row for your circuit, then somebody watching your local
network connection (or watching the first relay you pick) could break all
the layers of Tor encryption and read the traffic as if they were watching
it at the exit relay. (I don't want to say they could read the plaintext,
because if you used end-to-end encryption like SSL they wouldn't be able
to see inside of that -- unless of course the webserver you contact is
running Debian and affected by this bug!) Because this attacker can read
the traffic inside Tor, they would also break your anonymity: they know
both you and the destination(s) you asked for.

Worse, this attack works against past traffic too: what if an attacker
logged traffic over the past two years? As long as there's a single
non-weak non-colluding Tor relay in your circuit, you're fine -- that
relay will provide encryption that the attacker can't break, then or
now. But if you ever picked a path that consisted entirely of relays
with broken RNGs, and an attacker logged this traffic, then he can unwrap
the traffic from his logs using the same approach as above.

(Somebody who knows a Tor relay's private key could also impersonate that
relay. So he can do a man-in-the-middle attack, intercepting your traffic
to the "real" Tor relay and handling it himself. But this wouldn't give
him anything that he can't already do just by watching. Another attack would
be to create a fake descriptor and upload that. But this wouldn't give him
anything he can't do by starting his own relay and uploading a descriptor for it.)

This evening we've begun the process of making the directory authorities
reject all uploaded descriptors that are signed using these keys, so
we will effectively cut them out of the network. Peter Palfrader, our
Tor debian package maintainer, has also put out a new deb package that
will automatically discard the old relay keys when the relays upgrade,
so they'll automatically generate new safe keys.

The next big issue is that three of the six v3 directory authorities
were using weak keys for their directory votes and signatures. This
issue doesn't affect Tor clients running the 0.1.2.x (stable) series,
since those clients use the v2 directory system, none of whose keys
(I think) are weak.

What can three v3 authorities do? If they could forge a new v3
networkstatus consensus, they could trick users into using their own
fabricated Tor network, which would totally ruin their anonymity. Worse,
they could do this in a way that would be very hard to detect, by just
giving out their forged consensus to a few target users and giving out
the "real" consensus the rest of the time. But fortunately, Tor clients
require a majority of signatures before they'll believe the consensus --
and that's four of six. (Whew, that was close!)

Now, three v3 authorities can still influence the consensus a lot. As
one example, they could pick their favorite relays (say, because they
operate those relays, or because those are the ones that are easiest to
monitor), and put in three votes claiming that all the other relays are
unusable. The resulting consensus will then list only those relays as
"Running", since no other relays got enough votes. Then we're back to
the above scenario. But in this case at least one other v3 authority
would need to participate in building the consensus, so this couldn't be
a selective one-off attack. The whole consensus would appear different
to everybody, and hopefully somebody would notice.

The 0.2.0.26-rc release resolves these concerns by replacing those
three weak identity keys with new strong ones. Once you upgrade, your
new Tor won't trust any of those old keys -- so if anybody tries the
above attacks on you, your Tor won't buy it.

And the last issue that affects non-Debian users? If you use a hidden
service that generated its ".onion" key on a weak system, then you can
no longer be sure that you're actually talking to the original person
who generated the key. That's because somebody else might have figured
out the private key for that service, and started advertising it himself.
(Ordinarily, hidden services guarantee that nobody can intercept and read
or modify your communications with the service, because only the person
on the other end knows the private key that generated the ".onion" name.)

Now, what about the effects on Tor clients that run Debian, Ubuntu,
or the like? Well, first they're affected by all the above attacks. And
on top of that, any encryption they do can be considered to have no real
effect. So for example if an attacker can observe your traffic either
locally or at the first relay, he can see right through it all.

Similarly, if anybody has logs of traffic coming out of a Debian or Ubuntu
Tor client, they can strip it of its encryption, and thus retroactively
break the anonymity.

And lastly, don't forget there are plenty of other issues that this
OpenSSL bug causes that are unrelated to Tor. As a simple example, if your
bank generated its SSL cert on Debian or Ubuntu, then your SSL connection
to your bank (likely including your password) is readable. Or if you ever
tried to ssh into (or out of) an affected system, you have a problem. I
imagine some broader lists of examples will start appearing soon.

Security critical Tor-0.2.0.26-rc released

phobos — Tue, 13 May 2008 09:38:48 -0700

Tor-0.2.0.26-rc replaces several V3 directory authority keys affected by a recent Debian OpenSSL bug.

This is a security-critical release.

Everybody running any version in the 0.2.0.x series should upgrade, whether
they are running Debian or not. Also, all servers running any version of Tor
whose keys were generated by Debian, Ubuntu, or any derived distribution may
have to replace their identity keys. See our security advisory for full details. As always, you can find Tor 0.2.0.26-rc on the downloads page.

Changes in version 0.2.0.26-rc - 2008-05-13
Major security fixes:

Use new V3 directory authority keys on the tor26, gabelmoo, and moria1 V3 directory authorities. The old keys were generated with a vulnerable version of Debian's OpenSSL package, and must be considered compromised. Other authorities' keys were not generatedwith an affected version of OpenSSL.

Major bugfixes:

List authority signatures as "unrecognized" based on DirServer lines, not on cert cache. Bugfix on 0.2.0.x.

Minor features:

Add a new V3AuthUseLegacyKey option to make it easier for authorities to change their identity keys if they have to.