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

[Joe Btfsplk]

On 4/8/2014 4:25 PM, grarpamp wrote:
> On Tue, Apr 8, 2014 at 2:02 PM, Joe Btfsplk <joebtfsplk at gmx.com> 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.
Thanks.  Adding one more heartbleed vulnerability site I tried: 
http://rehmann.co/projects/heartbeat/?domain=

It seemed to work (though tough to qualify results).  It came back 
showing my bank was *still vulnerable* (not surprising).
So, made a payment over the phone instead of using their bill pay system 
(this should probably be taken this seriously, but some won't).

I checked a few other major sites at the rehmann link - it showed them 
as OK.

*"So you have to trust they did..."*

When something like this comes along, you shouldn't ASS-U-ME anything, 
or your ass may regret it. :)
Hard to imagine any reasonably large financial instit. NOT having a 
prominent banner on all main pages,
"We have (have not) fixed the openSSL issue. Customers can (should not) 
now do online banking." But not a peep.