On Tue, Apr 8, 2014 at 2:02 PM, Joe Btfsplk 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.