Jump to content

Heartbleed and Vulnerble Sites


gregorio2

Recommended Posts

The Heartbleed OpenSSL bug has definitely brought out the paranoid side to any web activity.

It behooves all who run HTTPS sites to first check their site maintenance and if at any time since Dec 2011,

OpenSSL Versions 1.0.1a through 1.0.1f were used, then 1.0.1g should be applied and certificates re-keyed or revoked

and new ones issued. If OpenSSL was replaced certificates still must be re-keyed or revoked and new ones issued.

 

I would like all HTTPS sites to make it publicly clear that they have checked and addressed this to

take some of my paranoia away. Even if they did not use OpenSSL!!

 

LastPass and McAfee both have posted tools to check sites. LastPass tool link found by going to their

blog page and searching for Heartbleed article. I used it to check this page and results follows:

 

/LastPass Heartbleed Checker
 

Site: forum.eset.com

Server software: Apache/2.2.15 (CentOS)

Was vulnerable: Probably (known use OpenSSL, but might be using a safe version)

SSL Certificate: Possibly Unsafe (created 1 year ago at Mar 14 22:40:10 2013 GMT)

Assessment: It's not clear if it was vulnerable so wait for the company to say something publicly, if you used the same password on any other sites, update it now.

/End of results.

 

Since supposedly 66% of internet or 66% of HTTPS sites use OpenSSL that paranoia is probably good right now and

also why techs stocks are nose diving right now.

 

Please ESET post as why you have not replaced your certificate. Or tell us you have not used OpenSSL since most Apache servers usually do.

 

If the bad guys compromised the certificates then the man in middle attack is like an in the clear wire tap, right?

 

tool links:

hxxp://tif.mcafee.com/heartbleedtest?utf8=%E2%9C%93&q=forum.eset.com&commit=Scan

https://lastpass.com/heartbleed/

 

Edit: Earlier I said revoke and re-issue certificate because most blogs I read said that but re-keying is being cited as

what maybe all that is necessary. The details are between the CA and the server in question to determine that question. 

Here lies another question as how each website handles this risk to customers. Certificates are not free and neither is

time paid to have this problem fixed. Re-keying is sometimes free except for time to do it.

And is re-keying anywhere reflected in certificate by a date? It does not seem to be if looking at standard certificate details page??

Only dates I see are issue and expire dates.

Edited by gregorio2
Link to comment
Share on other sites

  • Administrators
Link to comment
Share on other sites

Marcos, do you speak for the person maintaining that server? A shorter answer then the short long story would be the version of SSL that is used.

 

Edit: I finally read to bottom of link Marcos provided. See reply below.

Edited by gregorio2
Link to comment
Share on other sites

Arakasi posted link to another test at hxxp://filippo.io/Heartbleed/ .

Results:

/ All good, forum.eset.com Fixed or seems unaffected!

/ End results.

 

The results are similar to the no detail, feel good results McAfee gave.

That is why I posted the results from LastPass that showed Apache server which usually uses OpenSSL.

 

Marcos posted link to ESET blog that at bottom had this quote:

"Web services are not used ESET affected versions of OpenSSL, customers therefore do not change passwords."

That quote is neither clear or referencing forums.eset.com. I assume Marcos you were pointing to that vague quote.

But it seems to imply ESET did use OpenSSL and therefore should replace certificates even if they are currently

using safe version or not using OpenSSL now. They have not replaced certificate since 4/9/2013.

Edited by gregorio2
Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...