New WoSign/StartCom certificates issued after Jan 1st 2017 blocked on Apple products

My first 1 year free SSL certificate with StartSSL is about to expire this month, so time to renew for another year. At this point last year I wasn’t sure what would happen at this point 1 year later, but appears you just apply for another new certificate, and then replace it on the servers where you are using it.

 

However, once I had requested my new certificate and uploaded it to my OpenShift account, Chrome blocked access to my site with a ‘certificate revoked’ error. I bit of digging turned up this article. Due to a number of security related issues with the Certificate Authority WoSign and later their undisclosed purchase of StartCom/StartSSL, it appears use of certificates from either of these companies are now blocked on all Apple products if issued after Jan 1st 2017, and also on Firefox and Chrome too. More info on Wikipedia here, and Mozilla here and here.

Cookie blocking and using third party logons (like OpenID)

It’s one thing to block cookies because you don’t want to be tracked, but in most cases cookies provide essential functionality for some sites, like sites using a logon via another third party site, like OpenID.

Trying to logon with your Google account to the Kinja network of sites for example doesn’t work if you’re blocking third party cookies in Chrome. The logon fails silently. To work around this (and presumably for other similar sites too), just add a ‘Cookie and site data exception’ in your Chrome settings, in this case for [*.]kinja.com

‘Security by obscurity’ is not an effective security approach

This is a true story. I just came across a website, which I will not name (yes, I have emailed them to let them know of their issue), that provides a number of tutorials for download for a fee. They also have some free samples that you can download for free that are excerpts from the main materials.

I found the website from a Google search, and one of the search results was a pdf from their site on the topic I was looking for. Once I started browsing the tutorial contents however, I noticed that the file I’d found from my Google search appeared to cover far more pages in one chapter than should have been covered by one of the listed sample downloads, it was a complete chapter.

Thinking this was odd, I noticed that each sample download pdf listed in the tutorial table of contents had a range of pages in the file name, for example chapter1_1-2.pdf, but the file I had come across was chapter2_10-20.pdf

Out of curiosity it didn’t take too much guess work to change my url to point to chapter1_1-9.pdf and I’d downloaded a whole another chapter of material that should have only been accessible as paid materials. Looking at the other file names for the other chapter samples, it was easy to guess all the other filenames for all the other chapters too.

This wasn’t an isolated case. This particular website has a number of tutorials online following the same pattern. Given the example filenames from the free samples, it’s possible to guess all the full download files for all of their tutorials.

What the website owners and/or developers of their site had done was rely on ‘security through obscurity’ – the direct links to the paid materials were not listed on the website, but there was no security to prevent anyone from downloading the paid materials for free, even if they hadn’t paid to access the paid content. They had in effect hidden the paid materials in plain view.

The second mistake was to use an obvious pattern in the file names so that it was easy to guess the file names for the paid content. The table of contents which included links to a small number of sample pages made this easier, because it illustrated that the chapter files were numbered sequentially, and since there was a sample download for the first couple of pages for each chapter, it was easy to deduce that the files names were for all the other pages for the paid content.

If there was another authentication mechanism in place for paying customers to logon on to the site first before they could download content then the sequential nature of the file names wouldn’t be as much of an issue. The fact that there was no other security on the site however, meant that the table of contents with it’s sample links pretty much gave away the names of all the paid content.

‘Security by Obscurity’ is a very ineffective security mechanism. You can assume that ‘no-one will be able to find these files, right?’ but that’s a pretty bad assumption. If you think there’s a chance that no-one will find the files, it also means there’s a chance that someone will find the files. If your business is to make money from selling access to these paid materials, then this is a risk you cannot afford to take.

Latest Mac OS X patch for Java removes browser applet support

Following the recent press attention various security vulnerabilities in Java’s browser applet plugin have had in recent weeks (here and here), the latest Java patch from Apple removes the applet plugin from your browsers:

This update uninstalls the Apple-provided Java applet plug-in from all web browsers. To use applets on a web page, click on the region labeled “Missing plug-in” to go download the latest version of the Java applet plug-in from Oracle.

Since Oracle now maintain the official version of Java for Mac OS X, this is a smart move for Apple to remove the older/prior versions that end users may have of the applet plugin that shipped with older JREs previously supplied by Apple.

More details here.