Sunday, May 4, 2014

On Heartbleed: Some Updated Guidance (A Newsflash)

Although Heartbleed has "fallen off the radar", it is still out there.    I received this from an IBM Contact.  The opinions are his own--some key insights to be aware of:

Important new/updated information is highlighted in green.

IBM's list of vulnerable products:

- V7000/Unified
- Campaign v9.1
- Contact Optimization v.91

Recent AIX & VIOS update:

These are my opinions alone.  These are not IBM's opinions:

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.

An incomplete list of home/SOHO devices are affected:

- Routers; Examples:  AirportExtreme, CeroWRT
- Firewalls; Examples:  WatchGuard, FortiGate
- Printers
- Backup devices; Example:  Apple Time Capsule
- NAS file servers; Examples: Western Digital's "My Cloud", Synology
- NEST thermostats
- Polycom video conference
- Plesk Panel

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
How-to Scan/Test for Vulnerable Systems/Devices on Your Local Subnet:  (Windows-only)

BROWSERS ... for Users

Users need to insure that their web browsers (all of them), correctly handle revoked

security certificates. To test your browser, use:

Your web browser should return an error message in the spirit of:
- An error occurred during a connection to
- 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:

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.)

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 substantive 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.

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.

#6:  Optional; but a REALLY good idea:

- Implement Perfect Forward Secrecy (Ephemeral Diffie-Hellman)

- Verify your website's security configuration using:

Sunset support for olde, tired, weak & broken encryption.

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:


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...

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


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.

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: