[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-talk] [cryptography] The Heartbleed Bug is a serious vulnerability in OpenSSL



On Tue, Apr 8, 2014 at 2:02 PM, Joe Btfsplk <joebtfsplk@xxxxxxx> wrote:
>> On 4/7/2014 6:14 PM, grarpamp wrote:
>> http://heartbleed.com/
>> Patch your stuff.

> Comments / suggestions from those w/ in depth knowledge in this area?  How
> users should proceed; how to check if sites used (banks, email, retail
> sites, etc.) were / still are affected, so one knows if & when to change
> passwords or other data?
>
> If the number of sites potentially affected is as large as indicated on
> heartbleed.com, changing PW on even 60% of sites I use could take a long
> time - even to do it once.
>
> It would do little good to change a password on a site that hasn't patched
> this.
> Or perhaps it would do some good, to change the password before logging out
> of a site?  Then when a site must be accessed again, change the password
> again.
>
> Either way, this might not provide perfect safety, but might ? be better
> than nothing.

https://blog.torproject.org/ covers what to do for Tor things.

For everything else on the net, fix the clients and servers you're
responsible for. Then...

You're right, there's a big gotcha in all this, users won't really know if
the services they interact with have been fixed [1] because huge swaths
of services simply don't publish what they do on their pages, they bury
it to keep quiet and shiny happy sites. Only some banks, insurers, utilities,
schools, etc will post "we're fixed" anywhere remotely prominent. So
you have to trust they did [2], which is a reasonable assumption given
regulation and liability of big institutional services. You should already have
a regular password changing/logout/session management regimen, so
inserting some extra instances of that along guesstimates of [2] should
suffice with these classes of service.
[2] Sometime during the falloff curve starting yesterday afternoon.

The real user risk is likely on mid to small services, embedded things, shared
platforms, legacy systems, services that didn't get the news, don't have
the resources or knowledge to fix, etc. Again, consider some form of
reasonable regimen.

And there are all sorts of tools and site testing services coming out
now for which a brave user might be completely warranted in using to
determine [1 above] so they know when to utilize [regimen 2].
(Far better to use a testing service or email their help desks seeking
a positive statement than risk being potentially considered an exploiter
of things you don't own.)

Partial list...

http://s3.jspenguin.org/ssltest.py
https://gist.github.com/takeshixx/10107280
https://github.com/FiloSottile/Heartbleed
https://www.ssllabs.com/ssltest/index.html
(Note, this is a TLS in process bug, so more than HTTP/S services are
affected...)

This bug will no doubt trigger some thinking, analysis and change in
the services,
security, infrastructure and user communites... that's a good thing.
-- 
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