An Old IBM Associate was good enough to share his personal views on what should be done regarding Heartbleed. I wanted to report on it here for all:
Important new/updated information is highlighted in green.
IBM's list of vulnerable products: https://ibm.biz/BdRJfE
Why all the heartache about HeartBleed?
The 2012-2014 editions of the OpenSSL https/SSL/TLS authentication and encryption
protocols have a serious defect (named HeartBleed). On a 10-point scale, one respected
security researcher rates HeartBleed 9:10.
Why? HeartBleed enables the mass theft of the security certificates (private keys) used
to negotiate the authentication and encryption used between clients and servers.
What appls & services are vulnerable?
Everything using OpenSSL's heartbeat function.
Note: OpenSSH is not affected, because it does not use OpenSSL's heartbeat
feature. Other appls and services built on-top of OpenSSH are not vulnerable.
Example: scp
BROWSERS ... for Users
Users need to insure that their web browsers (all of them), correctly handle revoked
security certificates. To test your browser, use: https://revoked.grc.com
Your web browser should return an error message in the spirit of:
- An error occurred during a connection to revoked.grc.com.
- Peer's Certificate has been revoked.
- Error code: sec_error_revoked_certificate
If your web browser connects to GRC without complaint, your
web browser is defective. Hopefully, it will be patched.
WEBSITES ... for Users:
Users should "test" all websites they visit that use https/SSL/TLS.
I suggest testing using: https://www.ssllabs.com
Select the "Test your server" feature. Once a website passes this check, you
need to change your password (because you have no definitive method to
determine if your login credentials were stolen during the vulnerability period.)
How-to Scan/Test for Vulnerable Systems on Your Local Subnet:
http://www.crowdstrike.com/
WEBSITES ... for Sysadmins
The most recent surveys show that ~17.5% (~500k) websites are running vulnerable
OpenSSL editions. 17.5% is little comfort ... as most of the remaining websites are
running even older editions, which have other defects.
Required actions for those with web servers that support OpenSSL's 2012-2014 edition:
#1: Update/patch to the MOST CURRENT edition of OpenSSL.
#2: Update all appls & middleware that rely on OpenSSL.
#3: Replace your encryption key & security certificate with a new key & certificate.
You must replace as you have no way to positively determine that your
certificate has (not) been stolen.
Please consider upgrading to Extended Validation certificates. Yes, they
are more expensive. Yes, they are a PITA. But they will help secure iOS
Safari clients as soon as you adopt EV certificates.
#4: Revoke the prior security certificate to insure that the blackhats cannot
re-use it. If you do not revoke the prior certificate, your site is still
subject to impersonation/spoofing/MITM.
#5: Force users and sysadmins to change their passwords; by mass expiring
all passwords.
Browsers; IMHO; the Certificate Revocation Ecosystem is Insufficiently Trustworthy
The dirty secret about (all?) browsers' revocation defaults, is that they are all
defaulted to Soft-Fail if a security certificate cannot be validated. Bluntly; if
they cannot validate a certificate, they treat it as-if it is valid.
- Apple Safari & Google Chrome cannot be reconfigured to support hard-fail. For this
reason, I am changing my opinion of all IE, Safari & Chrome implementations to "fail."
- IE can be [re]configured to support Hard-Fail, but it requires a Registry hack. There
are also other, very good certificate validation reasons that all editions of IE
ought not be trusted be trusted for secure ops.
- Firefox can be [re]configured to support Hard-Fail:
> Tools
>> Options
>>> Advanced
>>>> Certificates
>>>>> Validation
>>>>> Put a checkmark in the box: When an OCSP server connection fails,
treat the certificate as invalid.
Preliminary findings compiled from a few trusted sources:
MAC OSX:
Safari: Fail - Cannot be configured for Hard-Fail.
Safari obeys system settings. The default behavior is to
make a best-effort to determine if a security certificate
has been revoked. i.e. If it cannot determine status, the
certificate is assumed to be secure.
Chrome: Fail - Ditto.
Firefox v3.x: Pass - Blocked by default.
Firefox v28.x: Fail - APPEARS to be configured, by default, for blocking...
but DOES NOT BLOCK.
iOS:
Safari: Fail - cannot be configured for Hard-Fail.
Standard validation certificates: No blocking and no
apparent option to enable it. Sigh ...
Extended Validation certificates: Blocking is enforced.
Good news; but, why did Apple choose to mishandle
standard validation?
Chrome: Fail - cannot be configured for Hard-Fail.
Windows XP:
IE9: Fail - Ignores revocation AND no apparent way to
enable.
There are other very good reasons certificate validation
reasons to not trust any edition of Internet Explorer for
secure ops.
Chrome: Fail - Ignores revocation AND ignores its own setting.
Two fails in one.
Firefox v28.x: Fail - Erratic behavior observed.
Win7/64:
IE8: Fail - Not for HeartBleed, but for other serious certificate
(mis)handing matters.
Defaults to Soft-Fail. Hard-Fail support only by a
Registry hack.
IE11: Fail - Not for HeartBleed, but for other serious certificate
(mis)handing matters.
Defaults to Soft-Fail. Hard-Fail support only by a
Registry hack.
Chrome: Fail - Cannot be configured for Hard-Fail.
Firefox v24.x: Pass - Properly handles/blocks sites with revoked certificates.
Firefox v28.x: Pass - Properly handles/blocks sites with revoked certificates.
Android KitKat:
Chrome: Fail - Shows revoked content. No visible way to turn it on.
Cannot be configured for Hard-Fail
Firefox: Pass - Properly handles/blocks sites with revoked certificates.
IBM's list of vulnerable products: https://ibm.biz/BdRJfE
Why all the heartache about HeartBleed?
The 2012-2014 editions of the OpenSSL https/SSL/TLS authentication and encryption
protocols have a serious defect (named HeartBleed). On a 10-point scale, one respected
security researcher rates HeartBleed 9:10.
Why? HeartBleed enables the mass theft of the security certificates (private keys) used
to negotiate the authentication and encryption used between clients and servers.
What appls & services are vulnerable?
Everything using OpenSSL's heartbeat function.
Note: OpenSSH is not affected, because it does not use OpenSSL's heartbeat
feature. Other appls and services built on-top of OpenSSH are not vulnerable.
Example: scp
BROWSERS ... for Users
Users need to insure that their web browsers (all of them), correctly handle revoked
security certificates. To test your browser, use: https://revoked.grc.com
Your web browser should return an error message in the spirit of:
- An error occurred during a connection to revoked.grc.com.
- Peer's Certificate has been revoked.
- Error code: sec_error_revoked_certificate
If your web browser connects to GRC without complaint, your
web browser is defective. Hopefully, it will be patched.
WEBSITES ... for Users:
Users should "test" all websites they visit that use https/SSL/TLS.
I suggest testing using: https://www.ssllabs.com
Select the "Test your server" feature. Once a website passes this check, you
need to change your password (because you have no definitive method to
determine if your login credentials were stolen during the vulnerability period.)
How-to Scan/Test for Vulnerable Systems on Your Local Subnet:
http://www.crowdstrike.com/
WEBSITES ... for Sysadmins
The most recent surveys show that ~17.5% (~500k) websites are running vulnerable
OpenSSL editions. 17.5% is little comfort ... as most of the remaining websites are
running even older editions, which have other defects.
Required actions for those with web servers that support OpenSSL's 2012-2014 edition:
#1: Update/patch to the MOST CURRENT edition of OpenSSL.
#2: Update all appls & middleware that rely on OpenSSL.
#3: Replace your encryption key & security certificate with a new key & certificate.
You must replace as you have no way to positively determine that your
certificate has (not) been stolen.
Please consider upgrading to Extended Validation certificates. Yes, they
are more expensive. Yes, they are a PITA. But they will help secure iOS
Safari clients as soon as you adopt EV certificates.
#4: Revoke the prior security certificate to insure that the blackhats cannot
re-use it. If you do not revoke the prior certificate, your site is still
subject to impersonation/spoofing/MITM.
#5: Force users and sysadmins to change their passwords; by mass expiring
all passwords.
Browsers; IMHO; the Certificate Revocation Ecosystem is Insufficiently Trustworthy
The dirty secret about (all?) browsers' revocation defaults, is that they are all
defaulted to Soft-Fail if a security certificate cannot be validated. Bluntly; if
they cannot validate a certificate, they treat it as-if it is valid.
- Apple Safari & Google Chrome cannot be reconfigured to support hard-fail. For this
reason, I am changing my opinion of all IE, Safari & Chrome implementations to "fail."
- IE can be [re]configured to support Hard-Fail, but it requires a Registry hack. There
are also other, very good certificate validation reasons that all editions of IE
ought not be trusted be trusted for secure ops.
- Firefox can be [re]configured to support Hard-Fail:
> Tools
>> Options
>>> Advanced
>>>> Certificates
>>>>> Validation
>>>>> Put a checkmark in the box: When an OCSP server connection fails,
treat the certificate as invalid.
Preliminary findings compiled from a few trusted sources:
MAC OSX:
Safari: Fail - Cannot be configured for Hard-Fail.
Safari obeys system settings. The default behavior is to
make a best-effort to determine if a security certificate
has been revoked. i.e. If it cannot determine status, the
certificate is assumed to be secure.
Chrome: Fail - Ditto.
Firefox v3.x: Pass - Blocked by default.
Firefox v28.x: Fail - APPEARS to be configured, by default, for blocking...
but DOES NOT BLOCK.
iOS:
Safari: Fail - cannot be configured for Hard-Fail.
Standard validation certificates: No blocking and no
apparent option to enable it. Sigh ...
Extended Validation certificates: Blocking is enforced.
Good news; but, why did Apple choose to mishandle
standard validation?
Chrome: Fail - cannot be configured for Hard-Fail.
Windows XP:
IE9: Fail - Ignores revocation AND no apparent way to
enable.
There are other very good reasons certificate validation
reasons to not trust any edition of Internet Explorer for
secure ops.
Chrome: Fail - Ignores revocation AND ignores its own setting.
Two fails in one.
Firefox v28.x: Fail - Erratic behavior observed.
Win7/64:
IE8: Fail - Not for HeartBleed, but for other serious certificate
(mis)handing matters.
Defaults to Soft-Fail. Hard-Fail support only by a
Registry hack.
IE11: Fail - Not for HeartBleed, but for other serious certificate
(mis)handing matters.
Defaults to Soft-Fail. Hard-Fail support only by a
Registry hack.
Chrome: Fail - Cannot be configured for Hard-Fail.
Firefox v24.x: Pass - Properly handles/blocks sites with revoked certificates.
Firefox v28.x: Pass - Properly handles/blocks sites with revoked certificates.
Android KitKat:
Chrome: Fail - Shows revoked content. No visible way to turn it on.
Cannot be configured for Hard-Fail
Firefox: Pass - Properly handles/blocks sites with revoked certificates.
No comments:
Post a Comment