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 rotation needed (and got) upgrades. Maybe we'll need to throw away our torproject SSL web cert and get a new one too.

The vulnerability has been there for 2 years. No one guarantees you that it hasn't been exploited before to extract private keys and that you did your Diffie-Hellmann key exchange with a man-in-middle who possessed the right key.

In case you're ruling a MITM out, then yeah, that's perfect forward secrecy and you should be good to go with that old traffic.

It should still be safe against a passive attacker -- that's one of the nice features of PFS in handshakes. They have to actually mitm every connection, or they don't get to learn the session key that's computed for that connection.

If the server is using forward secrecy (DHE or ECDHE cipher suites) old traffic is secure, but if the certificate is leaked new traffic can be MITMed. The actual key exchange algorithm doesn't matter.

No the old isn't always secure. You're still old screwed if TLS session tickets are in use and the server hasn't restarted and cleared state. It's rare, but google for more.


April 08, 2014


Hi. What do you mean with
«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»

1. aptitude update -> aptitude safe-upgrade
2. rm -rf /var/lib/tor/keys/*
3. /etc/init.d/tor restart

Is this correct? Or the second step is superfluos (or erroneous) ?
Thans in advance for your attention.

Well, the capacity of the tor network would be harmed a lot now if everybody were doing this, right? As I understand it, the new relay would need to go through "unmeasured" and "measured" phases, during which the full capacity is not used.

Do we have some data on how many relays actually changed the keys during update?

Correct. Once they get measured by the bwauths, which should take just a couple of days, they should ramp up. Hopefully it won't be too bumpy.

As for data, sort of, but certainly nothing comprehensive yet.

Try adv-tor from the best 'asm man' in the worldd
Christian Albu

We got the advor person to rename it from advtor, since "advanced Tor" is a poor name when what you're doing is adding a bunch of un-audited patches to Tor. Maybe it is better, maybe it is worse, most likely it's a combination (which in sum is probably not a great result for its users).

So, feel free to use a program called advor if you find one on the internet, if you really want to, but know that it's not endorsed or checked or anything by the Tor people.

I wonder if this is related to an observation concerning Google's recaptcha service.
Various web services embed Google's captchas before they let you use their service.
I observed many times that after solving the captcha the SSL connection to Google on port 443 remains open for a long time.
This could be 30 minutes or longer.
Would it make sense regarding the heartbeat bug that Google keeps those connections open to read parts of the memory of connected Tor clients on a large scale?

Sounds unlikely. Remember that your browser isn't exploitable here -- so the website will have a tough time attacking you.

What about version 0.9.8y is it safe?

It should be safe (from this vulnerability), yes.

My debian oldstable machine has 0.9.8o-4squeeze14 which should also be safe (from this vulnerability).

i've been to some really bad websites lately.i'm quite pc illiterate.please explain clearly where i must go and what i must do to ensure my safety.went thru tor to these sites.was that enough?

Are you one of the tiny fraction of Tor users who gives Tor a bad name by trying to reach child porn sites? If so, please go away and stop using Tor. That's not what Tor is for, and you're hurting us.

(If not, I'm sorry I yelled at you.)

LOL talk about jumping to conclusions. There are plenty of websites that are considered "bad" in certain countries that in the west we wouldn't even bat an eye at.

I don't like it when people make assumptions that just because someone said they went on bad websites that it has to be child porn, even from a Tor dev. Not including the fact that much of what people think is child porn is not actually bad (eg jailbait, not rape or real children, those can still be bad), but there are so many other websites that various governments or societies consider bad, whether it be drugs, or various religious or atheist views, or political views, or even freedom of speech. If anything we need to provide help to anyone who asks and not shun them or even throw out so much suspicion just because they say bad websites and the first thing that comes to mind is the most emotional worst case scenario.

Ok, I am going to cut this part of the thread off before it becomes a big flame war.

It's time to switch to 4096 RSA cryptosystems, I'm on a VPN using AES 256 for encryption, SHA256 for data authentication, and 4096RSA for handshake on a 1.7GHz processor with 2GB memory, and I have never EVER had any issues concerning speed, never experienced lag or hiccups, on the contrary I couldn't tell the difference between switching the VPN on and off.

Bumping up key sizes is a fine idea. And it's for that reason that we switched to much stronger ECC for our circuit handshakes, and for link encryption when it's available:…

But switching to stronger cryptosystems is not what this vulnerability is about. Even if you switched to 4096 rsa, this vulnerability will be just as bad for you.

Which is better ECC or RSA?
And I do second op, higher cryptosystems will put the minds of laymen to rest, after fixing the current vulnerability of course!

"It depends" is the only answer that can fit in a blog comment.

At this point they're both likely to be stronger than other components in the system (as we learned this week).

Don't use the NIST curves if you can help it. (We use them for our link encryption, to blend in, but not for our circuit-level encryption.)

You might like

On first glance it looks like the Safecurves folks understand the issues better than the ones from the site you link.

this bug exposes just how bad the NSA circumventing encryption really is, watch everyone panic over this yet the NSA and probably foreign intelligence have even better exploits. This is a reminder for myself that nothing is safe or secure online.


And I'm not sure if I should feel happier or sadder to imagine a world where these are the *accidental* bugs that we, the security community, introduce.

Security sure is hard, even without government-level adversaries.

I travel a lot, like every week, and sometimes every 2-3days, I'm in a different country, should I download TBB in every country I'm in, to be safe, or is there no problem with using the same TBB I downloaded many countries ago in different countries?

As long as you have the latest TBB, there should be no difference between fetching it from one country vs fetching it from another country.

But be sure to check the signatures on it, to make sure it really is the TBB we made for you.

Any idea when we can expect new Tor builds ?

Real soon now I hear.

You can watch progress on

(And now the new builds are up.)

is there any way to check the first relay my client is connected to for the vulnerability?

You could read your guards out of your state file and then manually check them with one of the python scripts that's floating around.

The Tor client doesn't do it automatically at this point. I'm not sure it ever should. The CFAA sure is overbroad here:

I can't believe how few people on this and other sites have not even mentioned using a vpn. Running a vpn-server on the inside-IP of your -second- router with Gargoyle or openwrt on it, would protect you against any vulnerabilities in SSL/TLS. Don't use Tor or surf the web without it. Configuration of the vpn server/client is quite simple on Gargoyle.

Wait, what? No, using a vpn would not protect you from "any vulnerabilities in SSL/TLS". For example, if you go to an https website with your browser, and it goes through your vpn, and there's a vulnerability in your browser's SSL library, the vpn does not help you.

For another example, if you use Pidgin to talk to an xmpp server over ssl, and it goes through your vpn, a vulnerability in openssl (like the one in this post) will be bad news for you.

It's about what applications you use, not about how you transport your traffic. Notice that that statement is true in the same way for Tor itself.

I see, you mean in terms of anonimity, of course.
I would think a vpn would still encrypt the content, though.
Or am I wrong?

I don't mean in terms of anonymity.

The vpn does encrypt the content, but the unencrypted content is still exposed on both ends. And that's where the vulnerability is.

Vexing (bug) and enlightening.
The key lies in memory.
I'm glad I updated my systems, but we'll have to wait for servers to do the same.
Looking forward to the latest TBB as per usual.
Keep up the good work.

And tor encrypt encrypted content right? What info can be collected from that? Endpoints? What else?
To prevent similar problems never collect and keep unnecessary historical information.

Am I right that entry guard potentially can see data for exit relay? tor-tls(tor-tls(tor-tls(tls(plain))))

For the general encryption question, you might like…

And no, you are mistaken that the entry guard gets to see data for the exit relay. The Tor client does, but that's the one that you run under your own control so it's ok that it does. (Otherwise there would be a point in the network that gets to both see you and learn where you're going, which is exactly what Tor's decentralized design aims to avoid.)

I scanned all the nodes in consensus for Heartbleed,
with the following results:

at least 530 nodes are VULNERABLE,
at least 2995 are NOT VULNERABLE,
the rest I don't know beacause of network timeout or something.

I did not check for rekeying.

To test for yourself, do this:
- get IP:ORPORT list of relays (grep the microdesc-consensus)
- get the script
- run it against each IP:PORT
- count the results

Yep. I think it's more like 1000 relays vulnerable at this point.

But counting relays is the wrong way to assess the vulnerability of the Tor network as a whole. You should ask what fraction of total consensus weight, or what fraction of advertised descriptor bandwidth, is vulnerable.

Otherwise you fall into the trap of various past researchers who see 500 relays on Windows, claim Windows is vulnerable, and conclude they can compromise 10% of the Tor network. This is true except that 10% of the Tor network doesn't see 10% of the users or traffic.

Now, in this case a big fraction of the network by weight *is* vulnerable. I mailed the top 400 relay operators last night to tell them about the bug. You can also follow along the tor-relays list:…

Eventually we'll start taking away the Valid flag from fingerprints of relays who were known to be running with a vulnerable openssl.

It's going to be a bumpy couple of days / weeks.

Hi! Sorry if I ask something stupid, I'm not an advanced user. I don't quite understand what these numbers mean to the average user. Can I assume that it means that there is a good chance that a few of my my connections weren't vulnerable at all?
If I understand correctly probably someone could have connected my ip with my traffic. Was this an easy thing, or hard to achieve? What I'm trying to figure out is how probable is that someone kept their anonmity?

keep up the good work tor and hopefully in a few days everyone above can carry on with all their "bad" stuff ;-) lel

What the hell is OpenSSL? I never installed anything called OpenSSL. Can't anyone write who is affected and what needs to be done in easy to understand words?

Every freaking time something happens everyone seems to start speaking binary...

You might find
to be useful. Many many journalists have been trying to write about it, and explain it, over the past day.

OpenSSL is a library which many programs and websites (including but not limited to tor) use to do cryptography.

A critical security vulnerability was found in this library yesterday. Just about everyone who uses tor (and the whole Internet, in fact, not just tor) is affected in some way.

What needs to be done is for an updated Tor Browser Bundle (coming soon) to be released, and for all users to upgrade. The relay operators also need to update their relays, and generate new keys for them.

Unfortunately, there isn't a lot more a user can do than that. Nobody knows if anyone has actually been attacked using this vulnerability, and even if they were, it would be basically impossible to find out. That's why everyone is scrambling today.

How many directory authorities were vulnerable? Assuming more than half, how soon can we expect a new tor build with their new keys?

Two or three of the nine directory authorities were unaffected, and the rest were vulnerable.

The long-term authority identity keys are unaffected, since they're kept offline.

The medium-term authority signing keys were affected, and they've been rotated (except for two authorities, which are offline until they can be brought back safely). Rotating them makes things a lot better, but still not perfect.

And the relay identity keys might have been taken, but really that's more of a hassle than a security thing -- if we rotate them, existing clients will scream in their logs that they're being mitm'ed, and more importantly existing clients will refuse to proceed, even though the directory documents they fetch are signed with other keys.

It's not clear to me yet that this change is worth a flag day. Hopefully we can do it more smoothly.