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:
- 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]
- 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]
- 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.
- 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.
- Tails is still tracking Debian oldstable, so it should not be affected by this bug.
- Orbot looks vulnerable; they have some new packages available for testing.
- 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.
Sounds doable in theory (no
Sounds doable in theory (no idea about practice, but we should assume so).
Arbitrary memory leaks are bad news.
Another fine reason to get relays to update (many of the big ones are in the process of updating right now).
Do heartbeat messages go
Do heartbeat messages go both ways? If so, can a relay also theoretically read a tor client process's memory?
Is Tor working on removing http://opensslfoundation.com/ as a dependency yet? It seems riddled with bugdoors. Personally, I'd like to avoid using software from Maryland.
Yes, heartbeat messages can
Yes, heartbeat messages can go both ways. See the "clients" section above.
Removing the openssl dependency, and replacing it with what? The world is missing an actually good crypto library.
What about NSS since you're
What about NSS since you're already using it for the browser?
Yes, maybe. There aren't
Yes, maybe. There aren't [m]any good crypto libraries out there to choose from. It's not clear to me that libnss is any better -- at least people *find* some of the bugs in openssl. :)
Since this attack relies on
Since this attack relies on the entire chain being owned, a mix of libraries will prevent any single compromise from owning the system.
By "chain" I assume you mean
By "chain" I assume you mean "Tor circuit".
In that case check out the comment at the top:
https://blog.torproject.org/blog/openssl-bug-cve-2014-0160#comment-55451
And then imagine fetching the memory from the relay that turns out to be Alice's entry guard, and also fetching it from the relay that turns out to be Alice's exit relay.
So the "entire chain" isn't needed. Maybe.
Entry guards or exits could
Entry guards or exits could use different crypto than other relays. Would you consider having exits use lighter weight encryption to ease the load on their CPUs?
Yes, if you can find us some
Yes, if you can find us some lighter-weight crypto that's still secure against all the attacks people are talking about this year.
I think we've gone a long way with the move to curve25519:
https://gitweb.torproject.org/tor.git/blob/tor-0.2.4.21:/ReleaseNotes#l…
"Replacing it with
"Replacing it with what?".
Isn't OpenSSL somewhat bloated? Tor does not need the many ciphers and operation-modes implemented in OpenSSL. Tor could operate just fine using a single cipher and mode of operation. That can be implemented without the baggage of a huge crypto library.
Yes, OpenSSL is a massive
Yes, OpenSSL is a massive library. with several cipher suites. The protocol has seen many years of (from time to time, shaky) service with a huge install base.
The benefits of keeping the same code versus rewriting are well known. I don't like OpenSSL, and would love to see it fixed in so many ways. Better test suites, static analysis, real verification, additional cipher suites, fixes to the protocol design all spring to mind; some of these cannot be done in a backwards-compatible way. It can be rescued, it's just a herculean effort.
Having lots of ciphers is very useful, for instance, when BEAST, CRIME, etc. came along and exploited padding oracles that were only present in block ciphers, servers could switch to RC4. When RC4 was shown to be broken, but the previously mentioned attacks were fixed, we could switch back. This flexibility is crucial in being able to respond quickly to new attacks, and in providing a smooth migration path for users.
So in practice, what does
So in practice, what does this mean for Tor? Could an adversary like the NSA completely unmask the entire Tor network without anyone knowing, or could they unmask a user that connects to a compromised or honeypot website?
This is quite scary...
Completely unmask the entire
Completely unmask the entire Tor network? Not anymore, since many relays have upgraded. But before the vulnerability was announced? Who knows.
A compromised website won't be a good place to launch an attack, since the Tor Browser shouldn't be affected by the bug, and the website doesn't interact with the Tor client at the link encryption layer.
But an entry guard (the first Tor relay you connect to) can potentially read client-side memory. See the 'clients' section above.
So if I had done something
So if I had done something "bad" in the past before the CVE was out, how much should I worry? By "bad" I mean things on the level of drug dealing, child porn, dissidence from nasty countries, etc. (not that I actually _do_ those specific things, but hypothetically if I did something on that level). Should I toss all my online pseudonyms out the window? I'm not quite sure what _practical_ steps I should take to ensure my safety.
By "bad" I mean things on
By "bad" I mean things on the level of drug dealing, child porn, dissidence from nasty countries, etc.
If you deal in drugs, you should pack your bags immediately and head for Mexico, Colombia or Honduras. You will find sanctuary there with like-minded people.
If you indulge in child porn, you should head for Russia. I heard some of Putin's men are child porners.
If you are a political dissident, you are safe. NSA and GCHQ will never uncover your activities or reveal your identity to North Korea, Iran, China, Turkey, Pakistan, etc.
Please do not feed the
Please do not feed the trolls.
I cannot figure out which people in this thread are the trolls. ;)
hey, I don't even like drugs
hey, I don't even like drugs but i like Mexico beaches, not cool.
What if I am a human rights
What if I am a human rights activist that is an enemy of the state to the US govt?
What if you tripped over a
What if you tripped over a rock and fell to your death? That's how much you should be worrying.
"If you deal in drugs, you
"If you deal in drugs, you should pack your bags immediately and head for Mexico, Colombia or Honduras. You will find sanctuary there with like-minded people." -
Well not necessarily, Mexico, Colombia, Honduras, and some other countries produce huge quantities of drugs, but the drugs are not for them, but for the worldwide drug-hungry-consumer countries like US and EU's. In fact, US is the winner on this subject, It's the greatest drug consumer in the world.
"if you are a political dissident, you are safe. NSA and GCHQ will never uncover your activities or reveal your identity to North Korea, Iran, China, Turkey, Pakistan, etc."
Well Not necessarily, if you are a politically dissident towards US policy, or a journalist, who have profound commitment with US constitution's freedom statements and Law, who also look for the truth and nothing but the truth on what's going on with US government's illegal activities perpetrated against American's citizens and other countries's government that are not fond of with US policy. then you might be careful, they may well say you are a whistleblower, and persecute you around the world. even though your duty and responsability you know will always be to release to public opinion those offensive government activities, Hence, you may be in serious trouble specially if living in US soil.
If you believe NSA or GCHQ
If you believe NSA or GCHQ wouldn't shop your ass to the security services, I've got a bridge I want to sell you. Either of them will do anything to anyone precisely as it suits their perceived needs (which mutate constantly).
Has the bridge upgraded to
Has the bridge upgraded to 1.0.1g?
This is the reason why onion
This is the reason why onion pages cannot be viewed? please help, thanks.
Probably not. Sounds like
Probably not. Sounds like you screwed up your Tor installation somehow. Be sure to use the Tor Browser Bundle (not some other thing), and make sure your time and date and timezone are right. If you still have a problem, try the helpdesk or irc.
https://www.torproject.org/about/contact
Some folks knew about this
Some folks knew about this bug for a while. Well, long enough to set up this nifty website talking about the bug.
They knew about it long
They knew about it long enough to patch it too. That's how vulnerability disclosure works.
I disagree. Vulnerability
I disagree. Vulnerability disclosure starts with the source and based on severity, escalates quickly to vendors. I know of at least two major OS vendors that were blind-sided by this. They did a great job of releasing patches quickly, but there will be serious fiscal impact, some of which could have been mitigated.
Yeah, the disclosure process
Yeah, the disclosure process sure didn't go smoothly on this one.
Agree. Both the NSA and GCHQ
Agree. Both the NSA and GCHQ have been having a good time. Methinks this bug is the work of an infiltrator from NSA who works on the OpenSSL project.
Would the disclosure be
Would the disclosure be limited to the memory that belonged to the OpenSSL process?
It would be limited to the
It would be limited to the memory that belonged the process that linked the openssl library. So that's Tor, or apache, or whatever else you might use.
I made a tool to check the
I made a tool to check the status of your SSL and see if heartbeat is enabled. If it is, you should run this command: openssl version -a
Ensure your version is NOT 1.0.1f, 1.0.1e, 1.0.1d, 1.0.1c, 1.0.1b, 1.0.1a, 1.0.1, 1.0.2-beta1
I made a tool to check the
I made a tool to check the status of your SSL and see if heartbeat is enabled.
http://s3.jspenguin.org/sslte
http://s3.jspenguin.org/ssltest.py seems to do the job nicely, and be easy to audit too.
It did a nice job of giving
It did a nice job of giving me an access denied error.
How sad! I have mirrored it
How sad! I have mirrored it at
http://freehaven.net/~arma/ssltest.py
You're asking the author of
You're asking the author of a tool if they put backdoors, Trojans or malware in their own code. If they did, they're not going to tell you.
another bad news... jesus
another bad news... jesus doesn`t exist also :(
: ]
: ]
DuckDuckGo.com appears
DuckDuckGo.com appears vulnerable according to http://filippo.io/Heartbleed/#duckduckgo.com
Watch yourself out there.
I wonder which CAs will give
I wonder which CAs will give out replacement SSL certs for free.
(I wonder which CAs will discard their CA keys and generate new ones. ;)
Well, anyone who runs a site
Well, anyone who runs a site and is affected by this should call their host and find out. :)
Discarding CA keys is
Discarding CA keys is unnecessary, as only SSL keys, not key-signing keys, are affected.
Fixed, as of 10.04.2014
Fixed, as of 10.04.2014
So was the security bug
So was the security bug introduced on purpose?
Here's a quote I heard
Here's a quote I heard today: "When it comes to deciding between maliciousness and incompetence in OpenSSL, there's a whole lot of incompetence to go around."
It's actually really hard to write a secure crypto library that implements all the things openssl implements.
So I guess that means my answer is "not necessarily".
in that case if some guys
in that case if some guys have unlimited resources imho they do know about this bag from day zero. take just 100 programmers and ask them to watch openssl development. surely they catch this bag at once.
Agreed. Another quote, by
Agreed. Another quote, by Napoleon (incorrectly ascribed to an American, who had just repeated it and became the "author"): "don't ascribe to malice what can be plainly be explained by incompetence".
Out of curiosity: If the
Out of curiosity: If the webserver uses Diffie-Hellmann for the SSL Key exchange, old and new traffic should still be secure, even if the cert was leaked, right?
(You obviously would want to replace your cert either way, but as I said, curiosity).
We have been speculating if
We have been speculating if a tor relay couldn't be made to leak information about the IP address of the next hop in a circuit, since an arbitrary memory leak is possible. Then, in theory, one could walk all nodes in a circuit to eventually uncover the other end of the circuit... (if all nodes in the circuit are linked to vulnerable openssl). Is that somehow prevented by the implementation design?