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 gotofail.com, 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.