Saturday, February 22, 2014

SSafari SSL SSucks

Apple apparently created a major bug in the OS X SSL stack in 10.9, a one-line error that causes certain kinds of SSL handshakes to never fail. Because of the nature of the SSL failure, you can't prove that the server possesses the certificate's private key matching the public key it advertised in the handshake. This is a severe flaw and makes man-in-the-middle SSL attacks greatly facilitated.

Apple has fixed this in iOS, but to date they have not fixed it in OS X. Fortunately, the error was newly introduced in 10.9 and earlier versions of OS X are not vulnerable -- you can prove that with this test site, appropriately named, which tries to trigger the bug. That said, you will notice that the error isn't actually in WebKit ... it's in the operating system security library.

I think this bears repeating, because anything that uses the operating system libraries to securely access the network could be vulnerable to other security flaws. Safari, for example, is precisely in this situation; WebKit does not implement SSL per se, and certainly not in the way that Mozilla does. Every time you update TenFourFox (and for that matter SeaMonkeyPPC), you get an updated network library, current security certificates and an up-to-date SSL implementation. Although Leopard WebKit at least fixes the problems with WebKit proper it cannot defend against a deficiency in, say, NSURL, and if one were discovered then you would be vulnerable if you use Safari or any other application accessing the network in that manner, even if you have Leopard WebKit installed. (Even OmniWeb, which embeds its own custom WebKit framework, suffers from this problem, and it is highly unlikely OmniWeb will issue future releases for 10.4.)

Because Tobias no longer has the resources to maintain WebKit for Tiger, I think this bug serves as a warning that 10.4 users should not Safari any longer for any purpose, and even for 10.5, if you depend on your Power Mac for banking or paying bills I would look at something with a more robust secure network implementation for those tasks. This failure (even though it's on 10.9) demonstrates in a painfully clear manner that the strength of your encryption in virtually all WebKit-based browsers is entirely dependent on an operating system component that on Power Macs has not been updated in almost three years.

Thanks to those of you who have reported your tests with garbage collection optimization. Turning off incremental GC does not appear to be an option; it stalls out too much after awhile, even worse than incremental GC. Increasing the time slice to 100ms does not seem to make anything worse, and pairing it with reducing browser.sessionstore.max_tabs_undo to, say, 2, does seem to allow the browser to recover memory a bit better. (There is still an issue with slow creep up to an unpredictable maximum even when the browser is idle, and it's hard to determine if the operating system or the browser is doing this or a combination of both.) These prefs make significant changes to the browser's behaviour, so as stated before they will not appear in the current stable branch. Remember to restart your browser after making changes to them.

Finally, and almost unexpectedly, SourceForge named us one of their Projects of the Week. I know some of you are frustrated with SourceForge's download system and the pages and advertising are certainly much more heavy than they were on Google Code, but they welcomed orphan projects like us, the site administration has reached out to me directly, and little kindnesses like this show they've supported us in a way Google never did. Plus, $FREE is a powerful motivator, even if it comes with drawbacks. Hopefully they can fix some of the network issues on their mirrors that some of you have experienced.

I pulled Firefox 29 from Aurora a couple days ago and I will be uploading 26 changesets when I get a chance later today, so watch for them. This includes a very preliminary, awfully buggy, only partially working implementation of IonMonkey, but you must run it in gdb7 because it has trap opcodes. One way or another, I should have an idea very quickly if Australis is going to be in any way workable.


  1. Great thoughts.

    I use Webkit sporadically, but I find it isn't as fast or smooth as TenFourFox. I'm not sure why - loading webpages in WebKit results in a significant hang before the site loads. TenFourFox instantly brings up the results. Even something like Google search can make WebKit pause for a bit. I've tried disabling extensions to see if it was something extra, but no luck.

    By the way, I linked to your blog and this article specifically on my new Power Mac G5 website ( to indicate that folks should think twice before using WebKit regularly since it's security features are based off of operating system code. Good advice. As far as we know, Leopard doesn't suffer from any SSL vulnerabilities, though, right?

    1. The stalls upon site loading might eventually be worked around by disabling IPv6 in the configuration of the network device you use for internet connection (System Preferences -> Network). Even when your internet provider doesn't support IPv6 your router might provide IPv6 tunneling.
      You might also try using alternative DNS servers like OpenDNS.

      Please try my suggestions and report your results!

    2. Hey Tobias - thanks for the reply.

      Just to up date you - I did try a series of things - turning off pre-fetching, clearing caches, turning off AdBlock and plug-ins, and some other things. A little improvement.

      Ultimately, you were spot on - turning off IPv6 sped up WebKit instantly. Awesome stuff. Thank you.

      Is this is a limitation with Leopard? Does Leopard have an outdated IPv6 spec/implementation?

    3. Here you get a detailed description of the underlying problem(s):
      However that site doesn't mention turning IPv6 off in the System Preferences.
      I suspect there wouldn't be a problem if your provider and router fully supported IPv6 - but that might take another 20 years to actually become true.

  2. What do you think of compiling openssl-1.0.1f in /usr for replace the original libssl.0.9.7.dylib?


Due to an increased frequency of spam, comments are now subject to moderation.