Re: Tor Project infrastructure updates in response to security breach
> 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. Thanks, Paolo *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Tor or vidalia problem?
Hello, Running vidalia 0.2.6 and Tor 0.2.2.6-alpha, I upgraded to the last release of Tor 0.2.2.7-alfa I have some mailboxes in POP on port 110 and cannot get rid of the "Alert messages" saying it is not safe etc etc, when I connect to these POP boxes. Clicking on "OK" or "Ignore" makes them close until the netx time and they come again. I unchecked all in the "Settings" config of Vidalia, but those popups remain when I check a POP box. Stranger is that I went back to Tor 0.2.2.6-alpha, and now also these Warning popups are always there, despite before the upgrade to 0.2.2.7, they were NOT showing up! Any suggestion? Thank you *** 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
ok, cool. thx guys. would it make sense to sign the torbutton xpi's? and torsocks? perhaps since it all comes from the same git repo it isn't necessary. *** 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
On Jan 21, 2010, at 6:25 AM, grarpamp wrote: As I wrote someone earlier... It would be easier to just sign the git revision hashes at various intervals. Such as explicitly including the revision hash that each release is made from in the release docs itself. And then signing that release. That way everyone... git repo maintainers, devels, mirrors, users... can all verify the git repo via that signature. Of course the sig key material needs to be handled in a sanitary way, but still, it's the idea that matters. And git, not svn, would need to be the canonical repo committers commit to, etc. This already happens. Clone the Tor repository, and you'll find a signed tag named tor-0.2.2.7-alpha. Use "git tag -v tor-0.2.2.7-alpha" to check for yourself. Sebastian *** 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
On Thu, Jan 21, 2010 at 12:25:08AM -0500, grarpamp wrote: > It would be easier to just sign the git revision hashes at various intervals. > Such as explicitly including the revision hash that each release is > made from in the release docs itself. And then signing that release. > That way everyone... git repo maintainers, devels, mirrors, users... > can all verify the git repo via that signature. Of course the sig key material > needs to be handled in a sanitary way, but still, it's the idea that matters. > And git, not svn, would need to be the canonical repo committers commit > to, etc. > > Thanks for Tor. We do sign the git repository for each release (stable and development). Do a git clone of Tor, and then 'git tag -l'. Saying the git hash of the release in the release notes is not a crazy notion though. --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
As I wrote someone earlier... It would be easier to just sign the git revision hashes at various intervals. Such as explicitly including the revision hash that each release is made from in the release docs itself. And then signing that release. That way everyone... git repo maintainers, devels, mirrors, users... can all verify the git repo via that signature. Of course the sig key material needs to be handled in a sanitary way, but still, it's the idea that matters. And git, not svn, would need to be the canonical repo committers commit to, etc. Thanks for Tor. ---I could imagine that they might try to sneak in a commit to the git repository. We have a hook that mails all commits to the mailing list, and we watch that pretty well. But they could disable the hook during their commit. As I mentioned in the earlier mail, the git tree is made up of hashes, so they can't just modify it outright. I've looked over the 'git log' output, and didn't find anything odd. It might be neat to do an automated comparison of "mails that made it to the mailing list" vs "commits to the git repository", if we wanted another layer of checking. *** 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
On Wed, Jan 20, 2010 at 11:12:29PM -0500, Peter Thoenen wrote: > > In early January we discovered that two of the seven directory > > authorities were compromised (moria1 and gabelmoo), along with > > metrics.torproject.org, a new server we'd recently set up to serve > > metrics data and graphs. The three servers have since been reinstalled > > with service migrated to other servers. > > While the issue was resolved, could this of had an impact had they known >what they broke into between the time of breach and time of discovery? Yes, depending on how paranoid you want to get. I don't think they could have done anything particularly devious with the directory authority. We've got that pretty well sorted out with the distributed trust thing -- nothing moria1 does can rig the consensus by itself. So it's really a question of the services running. Moria was running a nameserver for torproject.org (still is), so they could send web requests elsewhere. If people check SSL certs, no problem (modulo the usual points about SSL not being perfect); if they don't check SSL certs, we hope they check package signatures. This risk isn't specific to our machines though -- your local ISP can lie to you about your DNS resolves, or some jerk could redirect our bgp record like how Pakistan stole Youtube for a few hours last year. It was also the mail host for @torproject.org, though most of the mails went off to other mail servers after that. So they could have read my mail. Most of my mail is public (and/or boring) anyway though. I could imagine that they might try to sneak in a commit to the git repository. We have a hook that mails all commits to the mailing list, and we watch that pretty well. But they could disable the hook during their commit. As I mentioned in the earlier mail, the git tree is made up of hashes, so they can't just modify it outright. I've looked over the 'git log' output, and didn't find anything odd. It might be neat to do an automated comparison of "mails that made it to the mailing list" vs "commits to the git repository", if we wanted another layer of checking. Svn is less secure. It's just a database, and people can muck with it how they like. We've compared several of the svn repositories to backups, and nothing looked out of the ordinary. Good thing we moved Tor, Torbutton, BridgeDB, etc to git last year. The website wml files are still in svn and not git though, to make it easier for our volunteer translators; give us a holler if you find "Tor sucks" scribbled in some corner. :) If you want to scale up on the paranoid meter, you could imagine ssh client buffer overflows for the developers when we connected to it. That rabbit-hole goes as far as you like. Speaking of rabbit-holes, my gpg key is nearly a decade old and only 1024 bits. Sometime in the next little while I'm going to switch to a bigger one. > Do we know how they broke in? As I understand it, we have a 450G disk image from one of the machines sitting somewhere in Canada, but not anywhere near any of the Tor people. The attacker(s) were sloppy, so we know some things like the name of the local-to-root exploit they used (which by its name works on a surprisingly wide spread of kernel versions... security is hard). I still don't know how they got in to moria originally, though. Too much was going on on that machine. --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
> In early January we discovered that two of the seven directory > authorities were compromised (moria1 and gabelmoo), along with > metrics.torproject.org, a new server we'd recently set up to serve > metrics data and graphs. The three servers have since been reinstalled > with service migrated to other servers. While the issue was resolved, could this of had an impact had they known what they broke into between the time of breach and time of discovery? Do we know how they broke in? *** 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
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 *** 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
When you guys have finished the assessment will you be releasing details of how the compromise happened? Cheers, Harry On Wed, 2010-01-20 at 16:43 -0500, Roger Dingledine wrote: > You should upgrade to Tor 0.2.1.22 or 0.2.2.7-alpha: > https://www.torproject.org/download.html.en > > In early January we discovered that two of the seven directory > authorities were compromised (moria1 and gabelmoo), along with > metrics.torproject.org, a new server we'd recently set up to serve > metrics data and graphs. The three servers have since been reinstalled > with service migrated to other servers. > > We made fresh identity keys for the two directory authorities, which is > why you need to upgrade. > > Moria also hosted our git repository and svn repository. We took the > services offline as soon as we learned of the breach. It appears the > attackers didn't realize what they broke into -- just that they had > found some servers with lots of bandwidth. The attackers set up some ssh > keys and proceeded to use the three servers for launching other attacks. > We've done some preliminary comparisons, and it looks like git and svn > were not touched in any way. > > We've been very lucky the past few years regarding security. It still > seems this breach is unrelated to Tor itself. To be clear, it doesn't > seem that anyone specifically attacked our servers to get at Tor. It > seems we were attacked for the cpu capacity and bandwidth of the servers, > and the servers just happened to also carry out functions for Tor. > > We've tried to address the most common questions below. > > * Does this mean someone could have matched users up to their > destinations? > > No. By design, Tor requires a majority of directory authorities (four > in this case) to generate a consensus; and like other relays in the > Tor network, directory authorities don't know enough to match a user > and traffic or destination. > > * Does this mean somebody could have changed the Tor source? > > No, we've checked the source. It does mean you should upgrade so your > client knows about all the currently valid directory authorities. > > * Does this mean someone could have learned more about Tor than an > ordinary user? > > Since our software and specifications are open, everyone already has > access to almost everything on these machines... except some old bridge > descriptors, which we give out only in small batches as entry points for > blocked clients. > > * Can I trust Tor's security? > > We've taken steps to fix the weaknesses identified and to harden our > systems further. Tor has a track record of openness and transparency, > with its source code and specifications and also with its operations. > Moreover, we're disclosing breaches such as this so you can monitor our > status. You shouldn't assume those who don't disclose security breaches > never have any! > > --Roger > *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
OSX bundle
Hi, should https://www.torproject.org/dist/vidalia-bundles/vidalia-bundle-0.2.1.21-0.2.6-ppc.dmg contain a new version of Tor and maybe Polipo/Privoxy? It appears to only contain Vidalia and a Torbutton install. GD _ Hotmail: Powerful Free email with security by Microsoft. http://clk.atdmt.com/GBL/go/196390710/direct/01/
Tor 0.2.2.7-alpha is out
Tor 0.2.2.7-alpha fixes a huge client-side performance bug, as well as laying the groundwork for further relay-side performance fixes. It also starts cleaning up client behavior with respect to the EntryNodes, ExitNodes, and StrictNodes config options. This release also rotates two directory authority keys, due to a security breach of some of the Torproject servers: http://archives.seul.org/or/talk/Jan-2010/msg00161.html Everybody should upgrade: https://www.torproject.org/download.html.en Changes in version 0.2.2.7-alpha - 2010-01-19 o Directory authority changes: - Rotate keys (both v3 identity and relay identity) for moria1 and gabelmoo. o Major features (performance): - We were selecting our guards uniformly at random, and then weighting which of our guards we'd use uniformly at random. This imbalance meant that Tor clients were severely limited on throughput (and probably latency too) by the first hop in their circuit. Now we select guards weighted by currently advertised bandwidth. We also automatically discard guards picked using the old algorithm. Fixes bug 1217; bugfix on 0.2.1.3-alpha. Found by Mike Perry. - When choosing which cells to relay first, relays can now favor circuits that have been quiet recently, to provide lower latency for low-volume circuits. By default, relays enable or disable this feature based on a setting in the consensus. You can override this default by using the new "CircuitPriorityHalflife" config option. Design and code by Ian Goldberg, Can Tang, and Chris Alexander. - Add separate per-conn write limiting to go with the per-conn read limiting. We added a global write limit in Tor 0.1.2.5-alpha, but never per-conn write limits. - New consensus params "bwconnrate" and "bwconnburst" to let us rate-limit client connections as they enter the network. It's controlled in the consensus so we can turn it on and off for experiments. It's starting out off. Based on proposal 163. o Major features (relay selection options): - Switch to a StrictNodes config option, rather than the previous "StrictEntryNodes" / "StrictExitNodes" separation that was missing a "StrictExcludeNodes" option. - If EntryNodes, ExitNodes, ExcludeNodes, or ExcludeExitNodes change during a config reload, mark and discard all our origin circuits. This fix should address edge cases where we change the config options and but then choose a circuit that we created before the change. - If EntryNodes or ExitNodes are set, be more willing to use an unsuitable (e.g. slow or unstable) circuit. The user asked for it, they get it. - Make EntryNodes config option much more aggressive even when StrictNodes is not set. Before it would prepend your requested entrynodes to your list of guard nodes, but feel free to use others after that. Now it chooses only from your EntryNodes if any of those are available, and only falls back to others if a) they're all down and b) StrictNodes is not set. - Now we refresh your entry guards from EntryNodes at each consensus fetch -- rather than just at startup and then they slowly rot as the network changes. o Major bugfixes: - Stop bridge directory authorities from answering dbg-stability.txt directory queries, which would let people fetch a list of all bridge identities they track. Bugfix on 0.2.1.6-alpha. o Minor features: - Log a notice when we get a new control connection. Now it's easier for security-conscious users to recognize when a local application is knocking on their controller door. Suggested by bug 1196. - New config option "CircuitStreamTimeout" to override our internal timeout schedule for how many seconds until we detach a stream from a circuit and try a new circuit. If your network is particularly slow, you might want to set this to a number like 60. - New controller command "getinfo config-text". It returns the contents that Tor would write if you send it a SAVECONF command, so the controller can write the file to disk itself. - New options for SafeLogging to allow scrubbing only log messages generated while acting as a relay. - Ship the bridges spec file in the tarball too. - Avoid a mad rush at the beginning of each month when each client rotates half of its guards. Instead we spread the rotation out throughout the month, but we still avoid leaving a precise timestamp in the state file about when we first picked the guard. Improves over the behavior introduced in 0.1.2.17. o Minor bugfixes (compiling): - Fix compilation on OS X 10.3, which has a stub mlockall() but hides it. Bugfix on 0.2.2.6-alpha. - Fix compilation on Solaris by removing support for the DisableAllSwap config option. Solar
Tor Project infrastructure updates in response to security breach
You should upgrade to Tor 0.2.1.22 or 0.2.2.7-alpha: https://www.torproject.org/download.html.en In early January we discovered that two of the seven directory authorities were compromised (moria1 and gabelmoo), along with metrics.torproject.org, a new server we'd recently set up to serve metrics data and graphs. The three servers have since been reinstalled with service migrated to other servers. We made fresh identity keys for the two directory authorities, which is why you need to upgrade. Moria also hosted our git repository and svn repository. We took the services offline as soon as we learned of the breach. It appears the attackers didn't realize what they broke into -- just that they had found some servers with lots of bandwidth. The attackers set up some ssh keys and proceeded to use the three servers for launching other attacks. We've done some preliminary comparisons, and it looks like git and svn were not touched in any way. We've been very lucky the past few years regarding security. It still seems this breach is unrelated to Tor itself. To be clear, it doesn't seem that anyone specifically attacked our servers to get at Tor. It seems we were attacked for the cpu capacity and bandwidth of the servers, and the servers just happened to also carry out functions for Tor. We've tried to address the most common questions below. * Does this mean someone could have matched users up to their destinations? No. By design, Tor requires a majority of directory authorities (four in this case) to generate a consensus; and like other relays in the Tor network, directory authorities don't know enough to match a user and traffic or destination. * Does this mean somebody could have changed the Tor source? No, we've checked the source. It does mean you should upgrade so your client knows about all the currently valid directory authorities. * Does this mean someone could have learned more about Tor than an ordinary user? Since our software and specifications are open, everyone already has access to almost everything on these machines... except some old bridge descriptors, which we give out only in small batches as entry points for blocked clients. * Can I trust Tor's security? We've taken steps to fix the weaknesses identified and to harden our systems further. Tor has a track record of openness and transparency, with its source code and specifications and also with its operations. Moreover, we're disclosing breaches such as this so you can monitor our status. You shouldn't assume those who don't disclose security breaches never have any! --Roger signature.asc Description: Digital signature
Re: tor experimental???
Thanks Roger, I should have been taking better care of this box but have been super busy. My bridge is back up and running :-) Cheers, Harry Roger Dingledine wrote: On Wed, Jan 20, 2010 at 03:11:01PM -0500, Harry Hoffman wrote: So, at some point in time the apt url I was using for tor ceased to exist: http://mirror.noreply.org/pub/tor/dists/experimental-0.2.1.x-intrepid/main/binary-i386/Packages.gz Did experimental become unstable? Your url is quite old. Since then, we've A) moved to deb.torproject.org, and B) renamed the experimental branch to "experimental", so you don't need to name a branch. What happened in your case is that 0.2.1.x is the new stable. You might like https://www.torproject.org/docs/debian#ubuntu or https://www.torproject.org/docs/debian#development Hope that helps, --Roger *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/ *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: tor experimental???
On Wed, Jan 20, 2010 at 03:11:01PM -0500, Harry Hoffman wrote: > So, at some point in time the apt url I was using for tor ceased to exist: > > http://mirror.noreply.org/pub/tor/dists/experimental-0.2.1.x-intrepid/main/binary-i386/Packages.gz > > Did experimental become unstable? Your url is quite old. Since then, we've A) moved to deb.torproject.org, and B) renamed the experimental branch to "experimental", so you don't need to name a branch. What happened in your case is that 0.2.1.x is the new stable. You might like https://www.torproject.org/docs/debian#ubuntu or https://www.torproject.org/docs/debian#development Hope that helps, --Roger *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
tor experimental???
Hi, So, at some point in time the apt url I was using for tor ceased to exist: http://mirror.noreply.org/pub/tor/dists/experimental-0.2.1.x-intrepid/main/binary-i386/Packages.gz Did experimental become unstable? Cheers, Harry *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Latest OS X update breaks Tor
Hi folks, It looks like the latest OS X update removes a feature from the system OpenSSL library, and Tor needs this feature to operate. So if you're on OS X, you should expect that your Tor will stop working when you do the system update. :( We're aiming to have a fixed bundle (that statically links openssl) out in the next week or so. --Roger *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Memory usage on relays
Scott Bennett wrote: > On Tue, 19 Jan 2010 10:18:46 +0100 Olaf Selke > wrote: >> LD_PRELOAD"/foo/bar/libssl.so /foo/bar/libcrypto.so" >> in /etc/init.d/tor? > > Yup. It looks to be missing an equal sign. :) What?! ;-) You are right, it's a copy&paste error. Temporarily using an icc compiled openssl lib /etc/init.d/tor reads: LD_PRELOAD="/home/icc/tmp/openssl-0.9.8k/libssl.so /home/icc/tmp/openssl-0.9.8k/libcrypto.so" start-stop-daemon --start --quiet --oknodo \ [...] Olaf *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
