Re: Tor Project infrastructure updates in response to security breach

[Roger Dingledine <arma@xxxxxxx>]

On Wed, Jan 20, 2010 at 04:43:44PM -0500, Roger Dingledine wrote:
> In early January we discovered that two of the seven directory
> authorities were compromised (moria1 and gabelmoo), along with
> metrics.torproject.org

Here are some more technical details about the potential impacts, for
those who want to know more about Tor's innards:

----- #1: Directory authority keys

Owning two out of seven directory authorities isn't enough to make a new
networkstatus consensus (you need four for that), but it means you've
only got two more to go. We've generated new v3 long-term identity keys
for these two authorities.

The old v3 long-term identity keys probably aren't compromised, since
they weren't stored on the affected machines, but they signed v3 signing
keys that are valid until 2010-04-12 in the case of moria1 and until
2010-05-04 in the case of gabelmoo. That's still a pretty big window,
so it's best to upgrade clients away from trusting those keys.

You should upgrade to 0.2.1.22 or 0.2.2.7-alpha, which uses the new v3
long-term identity keys (with a new set of signing keys).

----- #2: Relay identity keys

We already have a way to cleanly migrate to a new v3 long-term identity
key, because we needed one for the Debian weak RNG bug:
http://archives.seul.org/or/announce/May-2008/msg00000.html

But we don't have a way to cleanly migrate relay identity keys. An
attacker who knows moria1's relay identity key can craft a new descriptor
for it with a new onion key (or even a new IP address), and then
man-in-the-middle traffic coming to the relay. They wouldn't be able to
spoof directory statements, or break the encryption for further relays
in the path, but it still removes one layer of the defense-in-depth.

Normally there's nothing special about the relay identity key (if you
lose yours, just generate another one), but relay identity keys for
directory authorities are hard-coded in the Tor bundle so the client
can detect man-in-the-middle attacks on bootstrapping.

So we abandoned the old relay identity keys too. That means abandoning
the old IP:port the authorities were listening on, or older clients will
produce warn messages whenever they connect to the new authority. Older
Tor clients can now take longer to bootstrap if they try the abandoned
addresses first. (You should upgrade.)

----- #3: Infrastructure services

Moria also hosted our git repository and svn repository. I took the
services offline as soon as we learned of the breach -- in theory a clever
attacker could give out altered files to people who check out the source,
or even tailor his answers based on who's doing the git update. We're
in pretty good shape for git though: the git tree is a set of hashes
all the way back to the root, so when you update your git tree, it will
automatically notice any tampering.

As explained in the last mail, it appears the attackers didn't realize
what they broke into. We had already been slowly migrating Tor services
off of moria (it runs too many services for too many different projects),
so we took this opportunity to speed up that plan. A friendly anonymous
sponsor has provided a pile of new servers, and git and svn are now up
in their new locations. The only remaining Tor infrastructure services on
moria are the directory authority, the mailing lists, and a DNS secondary.

----- #4: Bridge descriptors

The metrics server had an archive of bridge descriptors from 2009.
We used the descriptors to create summary graphs of bridge count and
bridge usage by country, like the ones you can see at
http://metrics.torproject.org/graphs.html

So it's conceivable that some bad guy now has a set of historical bridge
data -- meaning he knows addresses and public keys of the bridges, and
presumably some of the bridges are still running at those addresses and/or
with those public keys. He could use this information to help governments
or other censors prevent Tor clients from reaching the Tor network.

I'm not actually so worried about this one though, because a) we didn't
have that many bridges to begin with in 2009 (you should run a bridge!),
b) there seems to be considerable churn in our bridges, so last year's
list doesn't map so well to this year's list), and c) we haven't been
doing a great job lately at keeping China from learning bridges as it is.

Hope that helps to explain,
--Roger

***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxxx with
unsubscribe or-talk    in the body. http://archives.seul.org/or/talk/