Re: [tor-talk] Tor and Openssl bug CVE-2014-0160

[kendrick eastes <keastes@xxxxxxxxx>]

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
design<https://www.torproject.org/docs/faq#KeyManagement>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.
   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<https://blog.torproject.org/blog/debian-openssl-flaw%3A-what-does-it-mean-tor-clients%3F>,
   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?
> GD
>
> --
> 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
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
>
-- 
tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk