[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-talk] Tor and Openssl bug CVE-2014-0160
from https://blog.torproject.org/blog/openssl-bug-cve-2014-0160 :
1. *Clients*: Tor Browser shouldn't be affected, since it uses libnss
rather than openssl. But 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.
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
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.
3. *Hidden services*: Tor hidden services might leak their long-term
hidden service identity keys to their guard relays. Like the last big
this shouldn't allow an attacker to identify the location of the hidden
service, but 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; we'll try to publish more details here soon.
7. It looks like most of the webservers in the
https://www.torproject.org/ rotation need upgrades too, and maybe we'll
need to throw away our torproject SSL web cert and get a new one â
hopefully we'll deal with all that soon.
On Mon, Apr 7, 2014 at 7:56 PM, Geoff Down <geoffdown@xxxxxxxxxxxx> wrote:
> On Tue, Apr 8, 2014, at 12:17 AM, Roger Dingledine wrote:
> > A new OpenSSL vulnerability on 1.0.1 through 1.0.1f is out today,
> > which can be used to reveal up to 64kB of memory to a connected client
> > or server.
> > https://blog.torproject.org/blog/openssl-bug-cve-2014-0160
> > The short version is: upgrade your openssl (unless you're running an
> > old one), and also more packages coming soon.
> > --Roger
> So this is the openssl *binary*, the version of which is found by typing
> openssl version
> not some library used when compiling Tor?
> If the latter, how do we find the version?
> http://www.fastmail.fm - Access all of your messages and folders
> wherever you are
> tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
> To unsubscribe or change other settings go to
tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to