How do I disable SSLv3 in Safari (OSX & iOS)

Anyone have a solution for pre-10.9 systems?

I still have a number of users running 10.7 & 10.8 that can't be upgraded to 10.9. So, is the only solution for these older systems is to stop using Safari on them?

Thanks,

Kristin.

kristin. wrote:

Anyone have a solution for pre-10.9 systems?

I still have a number of users running 10.7 & 10.8 that can't be upgraded to 10.9.

There is no solution for 10.7, but as I said above, for 10.8 use Security Update 2014-005 Mountain Lion.

MadMacs0 wrote:

There is no solution for 10.7, but as I said above, for 10.8 use Security Update 2014-005 Mountain Lion.

Yea, sorry about that! I completely missed the 10.8 link (so that's good news). So, are there any suggestions for users on pre-ML systems? I guess I could remove Safari from these systems and have users run Chrome and Firefox only?

k.

kristin. wrote:

are there any suggestions for users on pre-ML systems? I guess I could remove Safari from these systems and have users run Chrome and Firefox only?

I have not read any suggestions and I doubt that Safari will receive any more updates on those systems.

Firefox won't be fixed until November 25th, so they will all need https://addons.mozilla.org/en-US/firefox/addon/ssl-version-control/.

Google has said that a future version of Chrome, now in testing, will fix this, but no time frame. It tests as Not Vulnerable for me, but I'm running an up-to-date Mavericks right now, so not sure what it would do on Lion and previous. Users report mixed results with the suggested patch mentioned above that has to be run at every launch.

My testing indicates that Safari is STILL vulnerable, even after the patch. The web server that display the poodle image for www.poodletest.com (https://sslv3.dshield.org) ONLY supports vulnerable protocols, so if the poodle image displays in Safari, it MUST be using SSLv3 AND a CBC block cipher. I have confirmed that this is in fact the case.

https://www.ssllabs.com/ssltest/analyze.html?d=sslv3.dshield.org&hideResults=on

There is simply NO way to connect to this web site and display any image without using SSLv3.

star2root wrote:

My testing indicates that Safari is STILL vulnerable, even after the patch.

It is, but according to the SANS institute "Apple has not blocked SSL 3.0, but has disabled cipher block chaining, which underlies the POODLE flaw." So you won't be able to utilize SSL 3.0 in any application that might try to use it, including Mail and Messages, for instance.

You missed the point, Safari is still vulnerable, and I confirmed it IS STILL using cipher block chaining WITH SSLv3. I am not as concerned about my email as I am about my bank web site.

star2root wrote:

You missed the point, Safari is still vulnerable, and I confirmed it IS STILL using cipher block chaining WITH SSLv3. I am not as concerned about my email as I am about my bank web site.

Actually, I didn't miss any of your points, I just don't accept them. None of the test sites mention cipher block chaining, only "block cipher". The vulnerability was discovered by Johannes Ullrich, PhD, Dean of Research and head of the Internet Storm Center at the SANS Institute. The poodletest site is his. The quote I gave is from his organization. The last comment that I could locate before responding to you earlier was that "my testing so far shows that Safari will still connect to the test site using ciphers like AES256" and that he was studying it further. Since the quote I gave you then from his organization's latest newsletter is that it is disabled, I will take them at their word until such time as he gets back to us or somebody else proves that it's possible to exploit it.

I have a lot of respect for the Qualys SSL Labs site and have used it often, but they too are subject to misinterpreting such things. I used them extensively during the early Heartbleed era (still going on) and it took them a few days to get all those tests exactly right. BTW, the site you give a link to is for Server testing. The client test is at SSL/TLS Capabilities of Your Browser, but does show "Your user agent is vulnerable. You should disable SSL 3."

In addition to using multiple test sites on the web as resources, I setup my own internal test server to use ONLY cbc (Cipher Block Chaining) encryption methods also using ONLY SSLv3. Safari was STILL able to connect, and I confirmed which cipher it was using by using a php script I wrote. Excuse me but what testing have you personally done??? As near as I can tell, Safari only exhibits this behavior if no other ciphers are offered, but that would still leave it open for a modified version of the attack.

Unfortunately, all of the fixes for Safari fail, including the Mavericks security patch. While the Safari browser may be fixed, the financial system (Schwab) does not recognize it as being fixed and does not allow access to their web site.

macsteve_va wrote:

While the Safari browser may be fixed, the financial system (Schwab) does not recognize it as being fixed and does not allow access to their web site.

Can you post a screenshot of what you are being told? I have never had a problem logging into any of my Schwab accounts using Yosemite or Mavericks since this started and checked just now as you can see from:

This was Safari 8.0 in Yosemite.

star2root wrote:

In addition to using multiple test sites on the web as resources, I setup my own internal test server to use ONLY cbc (Cipher Block Chaining) encryption methods also using ONLY SSLv3. Safari was STILL able to connect, and I confirmed which cipher it was using by using a php script I wrote.

Wondering why you didn't mention that earlier. What cipher was it? I think we already established it would connect using AES256 and Dr. Ullrich apparently hasn't found a problem with that one yet.

Excuse me but what testing have you personally done???

That's not really my job, my work focuses on the threat end of things, so harvesting samples, analyzing their impact on OS X, collaborating with a Macintosh Malware focused group on a daily basis, reporting results to Apple Product-Security, VirusTotal and selected A-V Scanners and advise users on how to detect and prevent infections from what we know. My primary job currently is Uncompensated Tech Support on the ClamXav Forum. But I do need to stay up-to-speed on vulnerabilities in case one of them is exploited. So, for instance I've spent most of the last 24 hours getting to the bottom of the WireLurker / MacHook Trojan in order to feed factual details to my colleagues for publication and assure users that everything is under control. As a result, this discussion had to be deferred.

But to directly answer your question, I've used all the test sites I've been made aware of since day one, including the two you pointed out. I have neither the time nor the equipment to conduct the type of test you discussed above.

At any rate, since you have apparently decided that Safari is not safe for your use on Financial sites is to use a different browser to do that until either the problem is eliminated to your satisfaction or better evidence that it is already fixed is presented.

I'd really like to do something with your findings, but at this point I have the word of Apple and a highly regarded PhD that it's fixed and an anonymous Internet person telling me that it isn't. Clearly, if I had the time and expertise to explore this for myself I would, but Cyber Security is way too complicated for any one person to know all there is, so for now I'll have to do what I can on the Threat front.

Please keep us informed of any new information.

Using my own Apache server, I forced Safari to connect with this Cipher...

Protocol in use=SSLv3

Cipher in use=DES-CBC3-SHA

Cipher bits=112

Export cipher?=false

I am pretty sure that is insecure.

This is the relevent part of the Apache SSL configuration used...

SSLProtocol SSLv3

SSLCipherSuite DES-CBC3-SHA

It has the server only offer that one cipher. Below is the php I used to see what cipher was used in the connection.

<!DOCTYPE html>

<html>

<head>

<title>SSL connection info</title>

</head>

<body>

Protocol in use=<?php print $_SERVER['SSL_PROTOCOL']; ?><br>

Cipher in use=<?php print $_SERVER['SSL_CIPHER']; ?><br>

Cipher bits=<?php print $_SERVER['SSL_CIPHER_USEKEYSIZE']; ?><br>

Export cipher?=<?php print $_SERVER['SSL_CIPHER_EXPORT']; ?><br>

</body>

</html>

MadMacs0 wrote:

Wondering why you didn't mention that earlier. What cipher was it? I think we already established it would connect using AES256 and Dr. Ullrich apparently hasn't found a problem with that one yet.

This web site indicates that even AES256 is at risk:

https://www.tinfoilsecurity.com/blog/how-to-fix-poodle-and-why-you-are-probably- still-vulnerable

There are a number of cipher suites, specifically AES128-SHA, AES256-SHA, and similar, that do not contain CBC in the OpenSSL cipher suite name. In reality, these cipher suites are named TLS_RSA_WITH_AES_128_CBC_SHA and TLS_RSA_WITH_AES_256_CBC_SHA, respectively. These cipher suites do work in CBC mode, no matter what OpenSSL chooses to call them!

A cipher like RC4 might keep you safe from the POODLE attack, but RC4 is vulnerable to other types of attacks.

http://threatpost.com/attack-exploits-weakness-rc4-cipher-decrypt-user-sessions- 031413/77628

It’s been more than 25 years since Ron Rivest invented his RC4 stream cipher, and after all that time it’s still being used widely, which is something of an achievement in the crypto world. However, for more than 15 years researchers have known about a weakness in RC4 that could enable an attacker to decrypt the keystream. Now, a cryptographer has published an attack that exploits that vulnerability and causes serious problems with TLS implementations. - See more at: http://threatpost.com/attack-exploits-weakness-rc4-cipher-decrypt-user-sessions- 031413/77628#sthash.w0Qw9180.dpuf

I got these results testing with openssl acting as a server:

# openssl s_server -ssl3 -cipher "DES-CBC3-SHA" -key /etc/apache2/ssl.key/server.key -cert /etc/apache2/ssl.crt/server.crt -www -accept 10443

Safari sent this request

GET / HTTP/1.1

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_5) AppleWebKit/600.1.17 (KHTML, like Gecko) Version/6.2 Safari/537.85.10

Safari displayed this page...

s_server -ssl3 -cipher DES-CBC3-SHA -key /etc/apache2/ssl.key/server.key -cert /etc/apache2/ssl.crt/server.crt -www -accept 10443

Secure Renegotiation IS supported

Ciphers supported in s_server binary

TLSv1/SSLv3:DES-CBC3-SHA

---

Ciphers common between both SSL end points:

ECDHE-ECDSA-AES256-SHA ECDHE-ECDSA-AES128-SHA ECDHE-ECDSA-RC4-SHA

ECDHE-ECDSA-DES-CBC3-SHA ECDHE-RSA-AES256-SHA ECDHE-RSA-AES128-SHA

ECDHE-RSA-RC4-SHA ECDHE-RSA-DES-CBC3-SHA ECDH-ECDSA-AES128-SHA

ECDH-ECDSA-AES256-SHA ECDH-ECDSA-RC4-SHA ECDH-ECDSA-DES-CBC3-SHA

ECDH-RSA-AES128-SHA ECDH-RSA-AES256-SHA ECDH-RSA-RC4-SHA

ECDH-RSA-DES-CBC3-SHA AES128-SHA RC4-SHA

RC4-MD5 AES256-SHA DES-CBC3-SHA

DHE-RSA-AES128-SHA DHE-RSA-AES256-SHA EDH-RSA-DES-CBC3-SHA

---

New, TLSv1/SSLv3, Cipher is DES-CBC3-SHA

SSL-Session:

Protocol : SSLv3

Cipher : DES-CBC3-SHA

Session-ID: 00E0FAF4C4861D25DD85E76F0A9A1239EF3E4B8D9BBFF7A78138A2AEF1C9D39E

Session-ID-ctx: 01000000

Master-Key: ~key~removed~from~post~

Key-Arg : None

PSK identity: None

PSK identity hint: None

SRP username: None

Start Time: 1415380510

Timeout : 7200 (sec)

Verify return code: 0 (ok)

---

1 items in the session cache

0 client connects (SSL_connect())

0 client renegotiates (SSL_connect())

0 client connects that finished

1 server accepts (SSL_accept())

0 server renegotiates (SSL_accept())

1 server accepts that finished

0 session cache hits

0 session cache misses

0 session cache timeouts

0 callback cache hits

0 cache full overflows (128 allowed)

---

no client certificate available

This seems to indicate that Safari will still negotiate CBC ciphers (in this case DES-CBC3-SHA) using SSLv3.