Re: Dir server's rendezvous-service-descriptor's
I was reading these two docs. They seemed to hint that such a thing existed on the authoritative directories. As that seemed where the HS nodes were uploading their descriptors/intro points to. Thus maybe a disk or control port query would exist for such records. Or with some minor source change, could be logged upon receipt. https://www.torproject.org/hidden-services.html.en Step two: the hidden service assembles a hidden service descriptor, containing its public key and a summary of each introduction point, and signs this descriptor with its private key. It uploads that descriptor to a set of directory servers. http://gitweb.torproject.org/tor/tor.git/blob/HEAD:/doc/spec/rend-spec.txt 1.2/1.6 > v2 hidden service descriptors are stored DHT-style on any relays > with the HSDir flag. Right now I count 581 of those relays in the > consensus. Hmm, ok, I think I need to read these specs some more. Well, certainly some of the 581 are untrusted regarding your A) above. Does each one hold a full list of the HS's out there? If DHT, no, it would probably be an even subset distribution. I'd have to read more. I can't imagine that logging each HS onion name received would present any risk to the net. But could provide a handy HS index. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Tor Project infrastructure updates in response to security breach
Mike Perry wrote: Just as in the Tor repo, I gpg sign the Torbutton git tags. I also gpg sign .xpis, but have been sloppy about posting them publicly. For now, I think the right answer is "Fetch it over SSL" or "Check the git/gpg sig". Could you make a point of publicly posting the .xpi gpg signatures along with the .xpis? I have never liked the method of downloading the extensions via the browser and installing all in one step. I prefer to download the extension, convince myself it is authentic (such as gpg), possibly install it locally in a test accound, and finally install it locally in the account(s) where I intend to use it. At present, the missing ingredient in being able to do that is not having a signature to verify against. So I'd much appreciate being able to get the signature w/o having to figure out git. Particularly if that signature has already been created. Thanks, Jim *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Tor Project infrastructure updates in response to security breach
Mike Perry wrote: > > I suppose I could also create a rogue code signing certificate and > provide that over SSL for people to install, but then I wonder if > vanilla Firefox will reject my XPIs then because they are signed, but > with an "invalid" cert. > I have a few of those laying around. I guess we could run some tests and find out? Best, Jake signature.asc Description: OpenPGP digital signature
Vidalia Bundle
Will it be possible to use Tor from the Tor browser bundle as a drop in replacement for Tor that came with the Vidalia bundle? If not, when will the Vidalia bundle be updated? -- PIT signature.asc Description: OpenPGP digital signature
Re: Tor Project infrastructure updates in response to security breach
on Thu, Jan 21, 2010 at 02:09:42PM -0800, Mike Perry wrote: > For now, I think the right answer is "Fetch it over SSL" "Fetch it over SSL from addons.mozilla.org" (the Mozilla Foundation obviously did bend over) /marcel signature.asc Description: Digital signature
Re: Tor Project infrastructure updates in response to security breach
Thus spake Paolo Palmieri (palma...@gmx.it): > > would it make sense to sign the torbutton xpi's? > > Actually, I've always been quite amazed by the fact that TorButton's > .xpi (binary?) files are not signed. > > I'd really like to see this implemented in the future. Just as in the Tor repo, I gpg sign the Torbutton git tags. I also gpg sign .xpis, but have been sloppy about posting them publicly. As for actual Firefox-compatible builtin xpi signatures, the last time I looked into those they were exceedingly complicated and needed a special Code Signing Certificate, which required me bending over and paying Verisign or some other SSL Mafia Member a lot of money ($200-500/yr) to examine my rectum for a while. Maybe the Tor Project can get one of these for me, but I am not certain its really worth it. I suppose I could also create a rogue code signing certificate and provide that over SSL for people to install, but then I wonder if vanilla Firefox will reject my XPIs then because they are signed, but with an "invalid" cert. For now, I think the right answer is "Fetch it over SSL" or "Check the git/gpg sig". -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpG7EGSQVvmT.pgp Description: PGP signature
Re: Dir server's rendezvous-service-descriptor's
On Tue, Jan 19, 2010 at 04:40:37AM -0500, grarpamp wrote: > Is there an archive or a current snapshot > of these from any or all of the six servers > available? Thanks. A) No, the hidden service descriptors aren't archived anywhere, or published anywhere, or even written to disk anywhere. B) Which six servers are you talking about? v2 hidden service descriptors are stored DHT-style on any relays with the HSDir flag: http://gitweb.torproject.org/tor/tor.git/blob_plain/HEAD:/doc/spec/proposals/114-distributed-storage.txt Right now I count 581 of those relays in the consensus. (v0 hidden service descriptors are stored just on the original three v1 directory authorities, two of which are gone so it's mostly moot.) --Roger *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: exit and guard flag
On Mon, Jul 27, 2009 at 08:23:15PM +0200, Olaf Selke wrote: > Hi there, > > I can confirm Roger's theory that exit traffic drops when gaining the > guard flag. > > Olaf Hi Olaf, Mike Perry recently found two further reasons why this is the case. The first (known) reason is that once you get the Guard flag, clients assume you're not useful for the middle hop anymore, since now you presumably have a lot of clients using you for the first hop. Once you've had the Guard flag for a while, that's a reasonable assumption -- but on day one, pretty much nobody has chosen you as their guard yet. New reason #1 is that clients were picking guards without weighting by bandwidth: https://bugs.torproject.org/flyspray/index.php?do=details&id=1217 So fast guards would get just the same amount of attention as slow guards. Tor 0.2.2.7-alpha resolves this, and 0.2.1.23 (whenever we put it out) will too. So the load balancing here should slowly correct itself over time. New reason #2 is that in the special case where you have both the Guard flag *and* the Exit flag, we aren't giving you as much attention as we should have. See Mike Perry's recent or-dev post with details: http://archives.seul.org/or/dev/Jan-2010/msg00012.html There's a third reason lurking, which is that the directory authorities seem to be making really bad decisions about which relays ought to get the Guard flag. That one is still unsolved though. It looks like the uptime and stability tracking is broken somehow. This time for sure! :) --Roger *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Tor Project infrastructure updates in response to security breach
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/msg0.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 *
