OpenSSL bug CVE-2014-0160

A new OpenSSL vulnerability on 1.0.1 through 1.0.1f is out today, which can be used to reveal memory to a connected client or server.

If you're using an older OpenSSL version, you're safe.

Note that this bug affects way more programs than just Tor — expect everybody who runs an https webserver to be scrambling today. If you need strong anonymity or privacy on the Internet, you might want to stay away from the Internet entirely for the next few days while things settle.

Here are our first thoughts on what Tor components are affected:

  1. Clients: The browser part of Tor Browser shouldn't be affected, since it uses libnss rather than openssl. But the Tor client part is: Tor clients could possibly be induced to send sensitive information like "what sites you visited in this session" to your entry guards. If you're using TBB we'll have new bundles out shortly; if you're using your operating system's Tor package you should get a new OpenSSL package and then be sure to manually restart your Tor. [update: the bundles are out, and you should upgrade]
  2. Relays and bridges: Tor relays and bridges could maybe be made to leak their medium-term onion keys (rotated once a week), or their long-term relay identity keys. An attacker who has your relay identity key can publish a new relay descriptor indicating that you're at a new location (not a particularly useful attack). An attacker who has your relay identity key, has your onion key, and can intercept traffic flows to your IP address can impersonate your relay (but remember that Tor's multi-hop design means that attacking just one relay in the client's path is not very useful). In any case, best practice would be to update your OpenSSL package, discard all the files in keys/ in your DataDirectory, and restart your Tor to generate new keys. (You will need to update your MyFamily torrc lines if you run multiple relays.) [update: we've cut the vulnerable relays out of the network]
  3. Hidden services: Tor hidden services might leak their long-term hidden service identity keys to their guard relays. Like the last big OpenSSL bug, this shouldn't allow an attacker to identify the location of the hidden service [edit: if it's your entry guard that extracted your key, they know where they got it from]. Also, an attacker who knows the hidden service identity key can impersonate the hidden service. Best practice would be to move to a new hidden-service address at your convenience.
  4. Directory authorities: In addition to the keys listed in the "relays and bridges" section above, Tor directory authorities might leak their medium-term authority signing keys. Once you've updated your OpenSSL package, you should generate a new signing key. Long-term directory authority identity keys are offline so should not be affected (whew). More tricky is that clients have your relay identity key hard-coded, so please don't rotate that yet. We'll see how this unfolds and try to think of a good solution there.
  5. Tails is still tracking Debian oldstable, so it should not be affected by this bug.
  6. Orbot looks vulnerable; they have some new packages available for testing.
  7. The webservers in the https://www.torproject.org/ rotation needed (and got) upgrades. Maybe we'll need to throw away our torproject SSL web cert and get a new one too.
olderOS

April 13, 2014

Permalink

Is using remote (shared) tor through SOCKS protocol seems preferable? No personal data leakage possible, bcose process dont have access to them.

No, because that remote Tor client still knows everything that a local Tor client would, and it would still be vulnerable to this same sort of attack (if you haven't upgraded).

Plus, if you use a remote Tor client you add yet another point in the network that gets to know both you and everything you do.

And if that's not enough, you're still going to be running whatever application (e.g. browser) on your own computer, so if it has problems then you didn't deal with that.

Bad idea IMO.

olderOS

April 13, 2014

Permalink

If you are using Tor, STOP NOW.
I suggest EVERYONE GO BACK TO 2.3.5.
Client and server. Clients, enable NoScript!
2.3.5 is back from 2011 and is tried and true, as far as I know.

Any hidden sites using compromised versions of Tor/SSL are unsafe and can never be considered safe again, unless the owner can prove through use of an old PGP key/.bit address that they own the new .onion site. All .onion sites using newer versions of Tor ARE POTENTIALLY COMPROMISED.

Also, any clients who have used a version of Tor within the last 2-3 years should be considering all of their keyrings potentially compromised by the entry guard (first relay) and should be completely re-encrypting their systems and generating new PGP keys, etc, as the first relay could have been reading our RAM through HeartBleed.

* IF YOU CANNOT SAFELY THREATEN TO KILL POLITICIANS OR DOWNLOAD/POST CP, YOU ARE NOT ANONYMOUS. *

I knew that it was sketchy when Tor Project was telling everyone to update their browser bundles after the Firefox javascript exploit that was revealing IP addresses of pedos.

THIS REQUIRES FURTHER RESEARCH AND THE TOR PROJECT IS COMPLETELY INCAPABLE OF DOING IT, AS IT HAS BEEN OVERRUN BY NSA SHILLS. We need to go back and fork the project!

Be careful listening to this person's advice.

For example, the 2.x TBBs have old obsolete insecure versions of Firefox in them, so that part is clearly bad advice.

Hidden services that used insecure versions of openssl are indeed unsafe and shouldn't be used again -- I agree. But this notion of proving something via PGP? Not enough details. And why blame the newer versions of Tor? Haven't you looked at the code? Or at least the changelog that shows all the bugs we fixed since the version you prefer to run?

Ha, and then we get to the end of your comment. I guess I'll let people judge that one for themselves.

olderOS

April 13, 2014

Permalink

Is it possible to check which SSL-version is installed by my TBB? (I'm only using the browser/client-only)

Version is 0.2.3.25-?. Do I have to look vidalia or browser-options?

Wow. You are using an obsolete insecure version of Tor Browser from years ago.

That browser you have probably has security holes by now. I recommend against running it.

I recommend you implement a way to to make tor nodes refuse connections from older version -anything that isn't the latest TBB. Too many people have no idea what dangers they're putting themselves in when using a not-up-to-date TBB.

Part of the trouble is that Tor is an anonymity system, and our protocol is open and there are multiple implementations.

So there are no good ways of having the relays reach in and figure out what version the Tor client is.

I guess we could have the Tor client volunteer its version info, and then the relays can hang up if they don't like it. But if we're to do that, why not have the clients just opt to fail if they're out of date?

That sure would make some users upset, e.g. the ones who put Tor on their USB stick, go to the censored/surveilled place with really crappy Internet, and then can't use it because of the update that came out the day before -- even if all they planned to use it for was to fetch the newer version.

So in sum, "it's complicated; somebody should come up with a clear plan and then we can see if it would actually work. Most versions of such plans don't seem good."

olderOS

April 14, 2014

Permalink

PersonalWeb, the True Names patent troll, claimed they could hack SSL to insert advertising with MITM attacks for ISP customers. Does anybody know if they were using this hack?

olderOS

April 19, 2014

Permalink

No question, but I just wanted to thank you very much for answering so many questions on here, it must be hard with all the other work you are doing. I wish I knew as much as you do.

Yes, the bug is fixed. But some of the fallout from the bug is still ongoing. For example, we'll be putting out a Tor update in the next while that blacklists the old (no longer in use) directory signing keys from the directory authorities -- not because we know they were compromised, but because we don't know they weren't. For another example, we cut 1000 relays out of the network because they were still vulnerable to the bug. And there are another 500-1000 that have upgraded (so the bug is fixed for them) but maybe their long-term identity key was extracted from them before they upgraded, and we'll be cutting those out of the network at some point.

It'll be a while yet until we can call it all resolved. I recommend following on the tor-relays list and other places than these blog comments.