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.

Yes, a given relay operator can see whatever his relay can see. That's why Tor circuits are multiple hops, and no single relay gets to know both the client and also her destination.

But if you can break into many relays, your odds go up of running across both the first hop in the user's path and also the last hop.

It would be pretty cool to have a design where the relay can't know anybody about the connections it's handling. But that solution would need to include somebody watching the traffic flows into / out of the relay, which has nothing to do with Tor process memory.

Makes complete sense, I don't see how that could deanonymize a user though ? If I am a relay operator and like you said can dump memory / use wireshark whatever and see the data that is going through. The exploit does the same thing ( dumps memory ). The two are the same, how can that be used as a attack vector ?

Thanks for answering my questions

Can tor use use 3 processes through pipe or like?
client <-->
[p3 <--> (p2 <-->(p1 <--> entry_guard)<-->inner) <--> exit ]
<--> inetsvr
any leakage restricted to corresponding process.
btw you are free to use distinct codecs/tls versions/etc at stages.


April 10, 2014


How many relays have upgraded to acceptable SSL so far. When does the process reach 90% complete? What is the schedule for Directory Authorities?

You'll do better following the answers to these questions on #tor-dev irc channel and on tor-dev mailing list. (Also, don't think of these things as number of relays, but rather percentage of capacity or consensus weights.)


April 10, 2014


So if I understand this correctly, for the past two years any malicious entry guard has been able to match up a user's real IP address (which it has) with a list of sites they have visited in TBB (which it obtains via heartbleed)?

If so, yikes! I wonder how many western agencies have been exploiting this little baby.

For someone to connect my traffic with my IP they have to be connected directly to me (so they are the relay I'm connected to), they have to know about this fact, and they have to know about the vulnerability.
Am I correct? If so, there is not a big chance that someone did this, even if they did, only a small amount of people are affected. (At least not every tor user) Am I wrong?

The counters for this is obvious:
1: Always run Torbrowser from a newly-extracted, never-used directory or from a copy of that in a directory on a tmpfs in RAM.
2: When it really counts, do not log into anything or engage in any activity that would identify you. Boot, do your secure work, then shut down.
3: Any time security forces could be a danger, use Tor from public wifi hotspots, using that hotspot for nothing else. Use it at home only to avoid things like building up an unwanted Google search history.

This way, heartbleed and any similar attacks all fail. They get an empty history and the IP address of a public wifi hotspot, after working like hell to get it. Just like running a brute-force encryption cracking program for three months, only to find another encrypted tarball as the only contents...

Could be made to replace the in the search space in the upper right corner of Firefox's browser?

Following on from this if the user was using a VPN although the malicious entry guard would know the sites visited and whatever it could get out of memory, would the associated IP be the one of the VPN? Or is there a way of gaining the real IP through this bug?

If I'm using OpenSSL 1.0.0j (which is what is in Liberte) then I'm not affected by this bug correct?

I use Super VPN and I'm not having any issues on this matter. What is going on!!

Sorry for the dumb question, but reading news, this blog, the comments there is one thing I'm not sure of.

I know that there is no way to know whether someone actually exploited this vulnerability or not.

But could they listen to everyone, or is it just based on luck? So was it technically possible to monitor everyone, or just random members? Let's assume that in the past two years someone did actively exploited this vulnerability. (let's assume the worst). Would that mean that everyone's traffic is affected or just a few or a lot of people?

Is there a patch I can run to fix this problem? Will running the "OpenSSL 1.0.1g" fix my computer? Will it ask me Q's that I can't answer (as a intermediate computer user)?

I have Tor v0.2.3.25 (installed from expert bundle) running on Windows. I use it as client-only: no hidden service or relay. Is it affected by this vulnerability?


This is not really about TOR, but please could someone knowledgeable help me as I can't find the answer via searches?

While logged in to Yahoo (when it was vulnerable) and logged in to eBay at the same time (which was not vulnerable), could the bug have revealed my eBay password and so I need to reset that as well as the Yahoo one?

"It depends."

Not through the obvious version of the attack (since it's the server that's vulnerable, not your browser), but maybe through some non-obvious version of it.

Please keep up the good work. The TOR team is awesome. Thanks a lot.

Was the old version of Torchat - or isthe version of OpenSSL too old?

You'd have to ask the Torchat people. Torchat has nothing to do with Tor and we haven't looked at it or evaluated it in any way. (In large part this is because they picked a confusing name for their program, so we spend energy teaching people that it's a confusing name rather than actually looking at it).

Torchat hasn't updated in ages, you need to do this manually.

Upgrade Tor in TorChat

1. Close TorChat
2. Download the offical Tor Browser Bundle from Tor Project
3. Extract Tor Browser Bundle to: c:\
4. Copy: C:\Tor Browser\Tor\tor.exe to c:\TorChat\bin\Tor\
5. Copy: C:\Tor Browser\Tor\libeay32.dll to c:\TorChat\bin\Tor\
6. Copy: C:\Tor Browser\Tor\libevent-2-0-5.dll to c:\TorChat\bin\Tor\
7. Copy: C:\Tor Browser\Tor\libssp-0.dll to c:\TorChat\bin\Tor\
8. Copy: C:\Tor Browser\Tor\ssleay32.dll to c:\TorChat\bin\Tor\
9. Copy: C:\Tor Browser\Tor\zlib1.dll to c:\TorChat\bin\Tor\
10. Start TorChat: c:\TorChat\bin\torchat.exe

Remember TC is a hidden service and like mentioned in the post above you should update Tor and then switch IDs.


Since any active security agency had plenty of time to map all Tor users IP addresses and more, What is the best practice to become anonymous from now on?. They know all their targets and their signatures as far as how they use internet. Does one needs to restart with new IP address, new persona, new hardware (computer, etc.), new software, new firmware, new VPN, new guards (relays), and essentially get ride of all things that could connect one to old persona?

TOR is awesome...
I had to know it little earlier


I'm also using What should I have to do/to change/to check, please!


Stop using the outdated version of Tor and switch to the latest version.

(I bet there are a lot of other things wrong with your setup too, if that version is a part of it.)

After one changes the keys on a relay tor weather jumps in with an announcement. Something should be done about that, a rekeying API or something.

I'm just happy Tor weather is still running at all. We've had nobody to maintain it or fix bugs or anything in it for years. Perhaps somebody wants to volunteer to help? See the tor-dev threads about it.

Private keys have been obtained, but it took over 100k requests and this was outside of Tor. How long on the fastest Tor connection would 100k requests take to complete?

Has anyone timed this yet? On average, how long does it take to get the key of a HS? How many times out of how many requests were you able to get it?

As far as I know, there are zero cases where anybody has successfully extracted a hidden service private key from a Tor client. Or for that matter a relay identity key from a relay.

That doesn't mean you can't do it. But it means we're not near to answering your "how long, how often" questions.

Could there be a future torrc option to restrict OpenSSL heartbeat to once every few minutes or shut it off altogether?

Somebody should indeed go through openssl and figure out all of its 'features' like this one. So far as I can tell, Tor doesn't need this heartbeat thing -- the Tor protocol has its own heartbeats built in.

The other question for each one will be whether an external observer can use any of the features we take out to distinguish us from 'real' SSL handshakes -- that's a major way that governments like Iran have been blocking Tor via DPI over the years.

I'm guessing at this point that focusing on just the heartbeat feature is like closing the barn door after the horses are extinct. But there are bound to be more issues remaining in other parts of openssl.

Tor Browser's anonymity stands on OpenSSL and NSS.
I think a proactive code review of NSS would be well advised.

You should give out a bounty if someone reports a deanonymizing bug in one of those libraries. I think about $1000-2000. This would be a nice reward without the need for shady dealings to sell such bug on the black market.

I think this is the only realistic approach to get enough people to actually look through the code.

We talked a while ago about doing bug bounties. Note that Mozilla itself does bounties for "security" problems, though you're right that our definition of security problem differs from theirs.

In the end we decided that we already know about plenty of important bugs that need fixing (see, and our Tor Browser money is better spent fixing as many of the known issues as we can than finding yet more issues but not fixing them.

That said, if anybody knows somebody who wants to fund Tor Browser bug bounties, we'd love to reconsider this plan.

In retrospect did the Tor client with an unpatched OpenSSL send the heartbeat over TCP only once per server session or could it have been more often? Multiple hearbeats could pave the way for reading larger memory areas at the client side.

I understand from that multiple heartbeats are only necessary over UDP.

This heartbeat implementation is so silly one has not change to change anything to make it into a joke:

Is anyone on the project doing practical tests to see how effective the attacks would be? If malicious entry guards are able to see sites a user had visited, possibly for 2 years, that is quite worrying.

If it turned out to be quite hard in practice (like private keys on web servers) it might be a bit more reassuring for tor users.

I encourage people to work on this one.

I bet it will be quite tricky but not impossible.

hi i'm still confused (after reading all these posts) exactly how i go about sorting this problem out? i use the tor bundle 3.5.4 that i updated a couple of days ago, i have no idea how to "update my ssl package" and don't understand if that applies to me as i use the bundle. also whats this about a tool to check to see if my ssl is compromised
Tool at:
is this a good idea?
basically is there anything i personally can do to protect myself, and should i still use tor?

ps i recon the dude that posted that he looks at "very bad" websites is into kiddy porn and i hope he's sweating waiting for the feds to to make a "hard entry" on his front door and take him to live in the big house with "bad bubba and the shower sisters"

If you're just using Tor as a client, and only using TBB, then moving to TBB 3.5.4 should be all you need to do for Tor.

(I say "for Tor" because if you logged into some website using https over the past few years, it's possible that the website was vulnerable, completely separate from what browser you used to reach it -- people could attack the website to extract whatever personal information you might have given it.)

>ps i recon the dude that posted that he looks at "very bad" websites is into kiddy porn
OK, that's disgusting. Not him, you. Let me guess, you're from America, Canada, or the UK, right? Either way, most of the world does not jump to the conclusion that "I look at bad websites" = "I look at kiddie porn". It's people with your views who try to get Tor banned or censored, because they assume the only reason people use Tor is for "bad things". Please, don't make completely and utterly unfounded assumptions, to the point where you actually wish great suffering upon a person. Honestly, I find that more disturbing what you're doing than the slim chance that his version of "bad sites" is exactly the same as your view.

I'm not trying to be rude, but I'm really quite tired of this. Quite often I'm on various chats, or forums, and I mention I like anonymity and privacy, and the first thing people assume is drugs, kiddie porn, or terrorism, and refuse to help me, or just as you do, wish for pain and suffering.

How's this. I go on "bad sites". Do you hope I suffer now? Do you hope I'm terrified of being locked up for decades and raped? Well too bad for you, because the sites I go on that are o-so bad are websites about atheism.

Once we're all done with our moral panics, can we please show some compassion for others who are lumped into one category just because we live in a place where we might like things big brother doesn't approve of?

btw how about return to rotating entry guards? longer you connected to the guard more leakage it can collect. new tor development lock you at single entry guard, is it coincidence?

No, this doesn't make much sense to me. I think a single guard can do a lot of damage to you, and if you have three of them, then any of the three can.

never ever use shared libraries! if you application was from openssl 1.0.0 era and you have updated system to "newest" 1.0.1

I think the answer is "take it up with Debian".

i think its great the way the Tor project actively responds to a lot of user inquires.The EFF linked to this thread and i just wanted to say, you guys sincerely care about your work and its very admirable.

anyways, it is possible to incorporate PFS to tor nodes?