Contact Us

To help prevent spam, Javascript is required in order for you to use this form.

Statement on CVE-2014-3566 "POODLE"

Overview

In September 2014, an attack was described against the SSLv3 protocol used in HTTPS, allowing partial plaintext recovery if a lot of identical requests could be intercepted. A downgrade attack was included, allowing users of more secure connections (TLS) to be downgraded to the now-vulnerable SSLv3.

A successful attack would reduce the security of an HTTPS connection down to that of HTTP.

The majority of the internet community has responded to this serious issue by disabling SSLv3 on their web properties. SSLv3 could be disabled by either the client (browser) or the server (website).

Notes

Alternative protections

  • The TLS_FALLBACK_SCSV option prevents the protocol-downgrade attack, allowing clients who use a more secure connection (TLS) to remain secure even though SSLv3 may be enabled.
  • Chrome 33 supported TLS_FALLBACK_SCSV since well before the attack was publicised, and was not vulnerable to this issue.
  • Firefox 34 disabled SSLv3.
  • Chrome 39 disabled SSLv3.
  • Firefox 35 added support for TLS_FALLBACK_SCSV.

Microsoft have announced plans to prevent protocol-downgrade to SSLv3 in IE 11 or above.

Compatibility constraints

  • Microsoft IE 6 in default configuration only supports SSLv3.
  • Certain mobile browsers only support SSLv3.

Every large-enough backup provider will appreciate that some customers still haven't upgraded from Windows 2000, let alone Windows XP - disabling SSLv3 could cause these customers to be unable to log in to the Customer Portal to download software updates. For some users who read email on older mobile devices, disabling SSLv3 could cause these users to be unable to read their backup report emails.

POODLE and MyClient

At the time of writing, MyClient Global.com Ltd has chosen to not yet disable SSLv3 on all the web servers we manage, because (A) we believe the attack is sufficiently mitigated in other ways; and (B) disabling SSLv3 has a bad impact on our long-tail of web browsers.

Update July 2015: MyClientGlobal.com have disabled SSLv3 on all the web servers we manage in response to IETF RFC 7568. In addition to this, the internet-wide response to this issue has correlated with significant upgrades of our long-tail of customer web browsers. The long-tail of web browsers impacted by this issue is no longer a significant concern.

POODLE and AhsayOBS

Overview

Release 6.21.2.0 of AhsayOBS disabled SSLv3 on the server-side in order to protect the AhsayOBS web console (this applies to full installations only, not patch updates).

AhsayOBS communicates with AhsayOBM and AhsayACB via HTTPS. Disabling SSLv3 on AhsayOBS caused a compatibility issue with all OBS/ACB versions prior to 6.21.2.0, as they were configured to connect to AhsayOBS using SSLv3 only.

It is mandatory to upgrade your AhsayOBS servers to 6.21.2.0 or later, as the Ahsay licensing server will no longer accept connections on SSLv3 as of early 2015. For a licensing extension, please contact Ahsay.

Solution 1: Upgrade

Upgrading all clients to 6.21.2.0 or later resolves the compatibility issue. Note that you must upgrade the clients before upgrading the server, as the clients will not recieve an AUA from the incompatible new server version.

Solution 2: Re-enable SSLv3

Since it's not possible to coerce AhsayOBM into making network requests, let alone the same network request several tens of thousands of times in a row in a short space of time, we believe the POODLE attack would be ineffective against the client-server communication. For customers who have a large number of OBS/ACB installations older than 6.21.2.0 and cannot easily upgrade, you can therefore safely resolve the compatibility issue by re-enabling SSLv3 on AhsayOBS as long as you take the alternative precautions above when accessing the AhsayOBS web console (i.e. using a supported web browser version).

Solution 3: Use HTTP only

As mentioned in AhsayOBS SSL certificates with multiple SubAdmins », AhsayOBM/ACB already whitelist an SSL certificate with a publicly available private key. Against a determined attacker, the client-server security is therefore reduced to HTTP regardless. Therefore there is no security loss in switching to use HTTP connections only.