Tor Project infrastructure updates in response to security breach

Harry Hoffman hhoffman at ip-solutions.net
Thu Jan 21 14:02:47 UTC 2010


Hi Roger,

Thanks for the detailed explanation. It's always interesting to hear 
about how other go into the "verification route" when a compromise happens.

Do you know the nature of the compromise? Was it against Tor itself or 
one of the other services running on the Directory Authorities?

Just curious, as it sounds like each of the DA was running a different 
set of apps, but perhaps I read more into that then was said.

Also, is there a need for hardware to be apart to physically partition 
services (i.e. svn,git,dns)? Or do you guys already have that covered?

Cheers,
Harry

Roger Dingledine wrote:
> 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 at torproject.org with
> unsubscribe or-talk    in the body. http://archives.seul.org/or/talk/
> 
***********************************************************************
To unsubscribe, send an e-mail to majordomo at torproject.org with
unsubscribe or-talk    in the body. http://archives.seul.org/or/talk/



More information about the tor-talk mailing list