Apple disabling the SSL3 support in Push Notification Service

Apple are about to disable SSL3 support in Apple Push Notification Service at Wednesday, October 29.

Developers experiencing issues with Provider Communication interface in the development environment consider immediate updating the code. After this date – Push notification using SSL3 will stop working.

Official apple notification is below

The Apple Push Notification service will be updated and changes to your servers may be required to remain compatible.

In order to protect our users against a recently discovered security issue with SSL version 3.0 the Apple Push Notification server will remove support for SSL 3.0 on Wednesday, October 29. Providers using only SSL 3.0 will need to support TLS as soon as possible to ensure the Apple Push Notification service continues to perform as expected. Providers that support both TLS and SSL 3.0 will not be affected and require no changes.

To check for compatibility, we have already disabled SSL 3.0 on the Provider Communication interface in the development environment only. Developers can immediately test in this development environment to make sure push notifications can be sent to applications.

POODLE Vulnerability found in all latest Checkpoint portals


POODLE Vulnerability found in all latest Checkpoint versions portals (Multi-Portal, GAIA WEBUI Portal, IPSO Portal, Secure Platform WEBUI, LoM card WEBUI)

In continuation to SHELLSHOCK bash vulnerability found exploitable in Checkpoint WEBUI the company is currently working on closing SSL 3 in all portals since found vulnerable for CVE-2014-3566 POODLE Bites vulnerability.

The Checkpoint sk102989 explains step by step procedure about disabling SSL 3 in all portals and howto enable IPS and HTTPS inspection protections in order to block the endpoint user browsers from successful SSL 3 negotiation in case the remote WEB site is trying to force it. The SK is being updated in mostly daily basis. There is no full solution for diskless IPSO systems can survive reboot  yet as well as pending solution for SmartPortal and LOM card WEBUI.

Of course all portals without solution provided shouldn’t be normally available from unsecured networks because designed to manage OS and hardware settings only.

All Checkpoint customers should check their publicly available portals and use the SK in order to fix. In addition it is highly recommended to disable the SSL 3 protocol on browser and network inspection gateways (UTM, Antivirus, Proxies).

There are free online tools customers can easely use in order to verify SSL 3 protocol support as well as POODLE vulnerability and configuration issues for their public portals

The death of SSL 3.0

POODLE vulnerability hastens the death of SSL 3.0

Systems that support only SSL 3.0 are being abandoned as systems operators cease server-side support for the outdated standard following the disclosure of a critical bug.

The latest in 2014’s saga of server-side issues is POODLE, an acronym of Padding Oracle On Downgraded Legacy Encryption (otherwise designated as CVE-2014-3556) that was named by the publishers of the disclosure, Google researchers Bodo Möller, Thai Duong, and Krzysztof Kotowicz.

POODLE is a flaw in how browsers handle encryption; by negotiating down to SSL 3.0, attackers can alter padding data at the end of a block cipher in a way that forces a slow leak of data. Many of the cipher suites in SSL 3.0 have already been abandoned as insecure, due to small key sizes, biases, and simply having support already removed from browsers.

The POODLE vulnerability allows attackers to exploit the design of SSL 3.0 to decrypt sensitive information, including secret session cookies (and, therefore hijack sessions for users’ accounts). Because the exploit is not being a patchable flaw, it is necessarily hastening the death of SSL 3.0 as a viable standard.

In finer detail, from Möller, Duong, and Kotowicz:

Encryption in SSL 3.0 uses either the RC4 stream cipher, or a block cipher in CBC mode. RC4 is well known to have biases, meaning that if the same secret (such as a password or HTTP cookie) is sent over many connections and thus encrypted with many RC4 streams, more and more information about it will leak. …Unlike with [other] attacks, there is no reasonable workaround. This leaves us with no secure SSL 3.0 cipher suites at all: to achieve secure encryption, SSL 3.0 must be avoided entirely.

The paper goes on to describe a workaround in the event that SSL 3.0 must absolutely remain for compatibility with legacy systems — the exposed systems are unpatched, unsupported versions of Windows XP and Internet Explorer 6 — using TLS_FALLBACK_SCSV to head off the handshake portion of the exploit, though it does not do anything to fix the underlying and preexisting cipher issues. To summarize, the SCSV fix sends a flag if a client system is being forced to downgrade for a connection the server should be capable of supporting.

In all fairness, SSL 3.0 was replaced by TLS 1.0 in 1999 — it is time for the standard to be deprecated.


The public response

Akamai, a popular CDN, has accelerated its deprecation of SSL 3.0, which at present stands at 90% complete, and should be finalized for Secure CDN customers by late October to early November 2014. The firm is also working on a phased deployment for TLS_FALLBACK_SCSV for legacy systems, though they note that since few browsers support this patch, it does not help anyone for the short term. SSL 2.0 traffic is now blocked, and customers supporting only SSL 3.0 are urged to upgrade as soon as possible.

CloudFlare has disabled SSL 3.0 support by default for all customers. Business and enterprise customers have the option of enabling it manually, though CloudFlare strongly discourages users from doing so. The company’s research notes that for HTTPS traffic, only 0.65% of this traffic uses SSL 3.0, which they characterize as being mostly attack traffic and crawlers. They also note that Windows XP traffic constitutes only 3.12% of all “real visitor traffic,” and of those users, only 1.12% use SSL 3.0.

Twitter announced an immediate end to SSL 3.0 support for its services, forcing users to use a browser that supports TLS 1.0 or higher.

Mozilla rolled out an extension for users to immediately disable SSL 3.0. SSL 3.0 will be disabled by default in Firefox 34, which will be released on November 25, 2014. Plans are also in the works to include support for SCSV in Firefox 35.

Möller indicated in a Google blog post that Chrome has supported SCSV since February 2014, and that SSL 3.0 support will be removed completely from client products “in the coming months.”

Does this dog bite?

What, if any, precautions will you take to mitigate this issue? Do you still have production servers that support SSL 3.0? Let us know your thoughts in the comments.




Credit:  James Sanders, techrepublic