Let’s Encrypt certificate expired on older Macs

I have a number of older machines that I use on a regular basis, so I’m no stranger to the struggles of not being able to browse current websites on older machines with older browsers and the typical SSL/TLS support issues that you run into. I was surprised to see this error this week on my 2008 Mac Pro running Mac OS X 10.11 El Capitan and a latest version of Chrome:

Looking at the certificate for any site not loading it looks like the certificate has expired:

I’m not seeing this on my other later/current machines though, so clearly something on these older machines is no longer getting updates. Browsing around a few other sites and seeing the same issue on many sites so it was not just limited to a single site, so I realized something else was going on. Some Googling found this article:

Following the steps to download the updated certificate from LetsEncrypt and install it into Keychain did the job.

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.