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.