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

True.

OS X Yosemite 10.10 fully updated is still vulnerable to POODLE attacks.

OS X Yosemite 10.10 with all updates applied is STILL vulnerableOS X Yosemite 10.10 with all updates applied is STILL vulnerable

spacebit wrote:

OS X Yosemite 10.10 fully updated is still vulnerable to POODLE attacks.

Why do you believe that?

I would suggest that you attempt to contact Dr. Ullrich and let him know of your findings.

I would also encourage you to post them to the Apple Bug Reporter. There is a link in the left column which will allow you to sign up for a free Developer Account in order to use it. That will get you a tracking number and the fastest available route to the appropriate Apple Engineering for evaluation.

Apple bug # 18919047 created.

I will attempt to contact Dr. Ullrich.

I spoke to Dr. Ullrich, he confirmed my results. He said it is possible that Apple may have changed something to prevent a protocol downgrade to SSLv3 but could not as yet find any evidence of that, and did confirm that Safari WILL connect with SSLv3 AND cipher block chaining. So, to all appearances so far, this is still an issue for Safari, pending Apple's response to my bug report. Even if they did someone hack the protocol implementation in Safari, who knows at this point how effect that fix will be, how it works, or even if it works at all.

Not sure you are testing what Apple fixed. Have a look at the wording....

About Security Update 2014-005 - Apple Support

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

In other words if you force an SSL 3.0 only connection client will do it. But why would you do that?

If you allow for one of the TLS methods it won't fall back if TLS negotiation blocked and fails.

That is exactly what I tested. I blocked TLS and higher protocols, and only allowed SSLv3 and Safari still connected with a CBC cipher suite, which according to that description, should have been disabled.

I'm very late to fixing my systems, but in researching why Safari was still showing as vulnerable despite having all security updates installed, I found this bulletin from Dr. Ullrich:

https://isc.sans.edu/diary/Safari+8.0.2+Still+Supporting+SSLv3+with+Block+Cipher s/19067

I can only conclude that my OSX 10.9.5 with Safari Version 7.1.2 (9537.85.11.5), along with IOS 8.1.2 is still *potentially* vulnerable.

I called this discussion to the attention of Apple Product Security as well as Dr. Ullrich's update and received the following response:

The Safari behavior you describe is as intended.

Best regards,

Apple Product Security

For the very security (SSL/TLS, especially), can any of you gentlemen confirm or deny that Safari 7.1.7 (9537.85.11.5) running on OS 10.9.5 is still affected by this POODLE risk or not?

The bottom line is many of us may have to "discuss" this with our banking IT staff. I'll quote the Apple Security Updates (which I have run on both Mavericks and Yosemite [running on a mini just for testing/monitoring]), but that may not be much of an argument if the test site still shows Safari as vulnerable.

Thanks! 😐

All I can tell you is what Apple Product Security told me just above your posting. Apparently they are completely satisfied with the fix they made.

they are completely satisfied with the fix they made.

🙂 I guess I'll just have to wait to see what happens when my bank blocks access... I'll attempt to get some info from them, but I usually have to never mention "Apple" or "Mac" until it's absolutely necessary! 😝 If all they do is send me to poodletest.com, they will have little regard to how satisfied Apple is. I do appreciate the comments on this thread and hope Apple has done the correct thing.

The message I got from my bank mentioned only Chrome/Firefox/IE (really?). And their website offered instructions via a graphic so one could not copy and paste the text. 😮 I suppose they don't want anyone to 'borrow' their 'help'! Oh well...

Thanks, again!

There was another SANS Institute blog today on Assessing the risk of POODLE which is fairly technical but might help convince folks that the risk isn't as bad as some have stated. Doesn't really do anything to explain away Safari test results, but might help IT groups to better understand it.

There is a thread on Techsurvivors discussing this thread and the POODLE problem. There is a nice post with a link to a less technical language report about POODLE. More importantly, there is a link to POODLEbleed.com ...which has a link to Qualys SSL Labs ...which has a link to a page ...that shows Sarafi is not vulnerable. I'll save you a bit of trouble by providing that last link! 😝 https://www.ssllabs.com:10443

The Qualys SSL Labs page presents a lot of info, including one section that says, "Your user agent is vulnerable. You should disable SSL 3." And another (the "Click Here" link just below the previous warning) that ends up 'proving' that Safari is not vulnerable. My count now shows 2:1 in favor of Safari is fixed! 😎

My main concern remains how the IT folks at my credit union will handle this. I know they are changing to TLS (v.?). Is it safe to assume to not even notice anything when I use Safari to access their site? I plan on contacting them today or next week.

Have a great, IN-vulnerable weekend!

Hi xairbusdriver,

This link https://www.ssllabs.com:10443 is not a valid test.

Your count of 2:1 is wrong.

A valid test requires trying to connect in a bad way.

https://www.poodletest.com is a valid test because you can only connect in a bad way.

Details are on www.poodletest.com website but the below text explains it all ;

Apple stated that the Safari update released on Oct 17th no longer allows block ciphers via SSLv3. The test site (on purpose) only supports block ciphers as they are vulnerable to POODLE. However, my testing so far shows that Safari will still connect to the test site using ciphers like AES256. Safari should show up as not-vulnerable if it only supports stream ciphers over SSLv3.

How to get apple to respond to another question. Like "Why does Safari support SSLv3 and block-ciphers" ?