Safari 8.0.2 Still Supporting SSLv3 with Block Ciphers

Safari 8.0.2 Still Supporting SSLv3 with Block Ciphers
In October, Apple released Security Update 2014-005, specifically with the intend to address the POODLE issue [1]. The description with the update stated: There are known attacks on the confidentiality of SSL 3.0 when a cipher suite uses a block cipher in CBC mode. An attacker could force the use of SSL 3.0, even when the server would support a better TLS version, by blocking TLS 1.0 and higher connection attempts. This issue was addressed by disabling CBC cipher suites when TLS connection attempts fail. However, even with the most recent version of Safari, I am still not able to prove this statement as true. Instead, I am able to connect to a test server that ONLY supports SSLv3 and block ciphers. [2] Multiple users of the site confirmed this observation, and the logs also confirm that current versions of Safari will happily ignore Apple's statement above and connect via SSLv3. Here is a breakdown of a packet capture showing the entire handshake: The Safari client hello: SSL Record Layer: Handshake Protocol: Client Hello Content Type: Handshake (22) Version: TLS 1.0 (0x0301) Length: 183 Handshake Protocol: Client Hello Handshake Type: Client Hello (1) Length: 179 Version: TLS 1.2 (0x0303) Random As it should, it indicates support for TLS 1.0. My server is now sending back the Server Hello message: Handshake Protocol: Server Hello Handshake Type: Server Hello (2) Length: 90 Version: SSL 3.0 (0x0300) ... Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039) The server offers AES, a block cipher (CBC) which is accepted by Safari. Other issues we discovered with the poodletest.com website is the use of proxies. Some proxies still support SSLv3, and if they are configured as a trusted proxy terminating SSL connections, then they may downgrade a connection to SSLv3. How serious is it? The POODLE attack is still a low probability attack. I am not aware of any active use of the attack. So no need to panic. But vendors like Apple aren't helping with incomplete statements. It is possible that Safari is doing some form of downgrading protection. But this is not explained in the very brief advisory. [1] https://support.apple.com/en-us/HT203107 [2] https://sslv3.dshield.org/vulnpoodle.png --- Johannes B. Ullrich, Ph.D. STI\|Twitter\|LinkedIn I will be teaching next: Defending Web Applications Security Essentials - SANS Cyber Defense Initiative 2020	Johannes 4001 Posts ISC Handler Dec 15th 2014
Thread locked Subscribe	Dec 15th 2014 5 years ago
Hi Can you report if your server that is testing this is using TLS_FALLBACK_SCSV? Similar to poodletest.com.... Is your connection reporting in error SSLv3 for TLS, pound perhaps? Curious?	steve 7 Posts
Quote	Dec 17th 2014 5 years ago
I count this is the 3rd major security misstep by Apple in recent months. First, icloud.com did not enforce a brute force attack lockout. Second, IOS did not enforce a brute force attack lockout. Third, Safari failed to disable SSL3. All three of these vulnerabilities seem to me to have been easily preventable by the most basic of testing prior to them going to production. I don't get it.	PhilBAR 24 Posts
Quote	Dec 18th 2014 5 years ago

In October, Apple released Security Update 2014-005, specifically with the intend to address the POODLE issue [1]. The description with the update stated:

There are known attacks on the confidentiality of SSL 3.0 when a cipher suite uses a block cipher in CBC mode. An attacker could force the use of SSL 3.0, even when the server would support a better TLS version, by blocking TLS 1.0 and higher connection attempts. This issue was addressed by disabling CBC cipher suites when TLS connection attempts fail.

However, even with the most recent version of Safari, I am still not able to prove this statement as true. Instead, I am able to connect to a test server that ONLY supports SSLv3 and block ciphers. [2] Multiple users of the site confirmed this observation, and the logs also confirm that current versions of Safari will happily ignore Apple's statement above and connect via SSLv3.

Here is a breakdown of a packet capture showing the entire handshake:

The Safari client hello:

SSL Record Layer: Handshake Protocol: Client Hello
Content Type: Handshake (22)
Version: TLS 1.0 (0x0301)
Length: 183
Handshake Protocol: Client Hello
Handshake Type: Client Hello (1)
Length: 179
Version: TLS 1.2 (0x0303)
Random

As it should, it indicates support for TLS 1.0. My server is now sending back the Server Hello message:

Handshake Protocol: Server Hello
Handshake Type: Server Hello (2)
Length: 90
Version: SSL 3.0 (0x0300)
...
Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)

The server offers AES, a block cipher (CBC) which is accepted by Safari.

Other issues we discovered with the poodletest.com website is the use of proxies. Some proxies still support SSLv3, and if they are configured as a trusted proxy terminating SSL connections, then they may downgrade a connection to SSLv3.

How serious is it? The POODLE attack is still a low probability attack. I am not aware of any active use of the attack. So no need to panic. But vendors like Apple aren't helping with incomplete statements. It is possible that Safari is doing some form of downgrading protection. But this is not explained in the very brief advisory.

[1] https://support.apple.com/en-us/HT203107
[2] https://sslv3.dshield.org/vulnpoodle.png

---
Johannes B. Ullrich, Ph.D.
STI|Twitter|LinkedIn

I will be teaching next: Defending Web Applications Security Essentials - SANS Cyber Defense Initiative 2020

Johannes

4001 Posts
ISC Handler

Dec 15th 2014

Hi

Can you report if your server that is testing this is using TLS_FALLBACK_SCSV? Similar to poodletest.com....

Is your connection reporting in error SSLv3 for TLS, pound perhaps?

Curious?

steve

7 Posts

I count this is the 3rd major security misstep by Apple in recent months. First, icloud.com did not enforce a brute force attack lockout. Second, IOS did not enforce a brute force attack lockout. Third, Safari failed to disable SSL3.

All three of these vulnerabilities seem to me to have been easily preventable by the most basic of testing prior to them going to production. I don't get it.

PhilBAR

24 Posts