Adventures with SSL
Google is pushing it. It began two years ago at Google I/O. Not only all their services support SSL by default, but they will “penalize” websites not running SSL soon. There’s a pretty controversial post by Dave Winer about why Google is enforcing SSL.
I’ll be way less controversial and more pragmatic. SSL is good, the intentions of people installing it are (probably) good. Security is important, but doesn’t come without overhead. Here’s a bunch of adventures I had recently. Some are just road bumps, some other can be serious for me and anybody adopting SSL.
A few days ago I was provisioning a virtual machine on my Mac. I had an image, I deleted all the snapshots to start fresh and run my provisioning script. The installation of Ruby failed. I thought it was a glitch, so I restarted again from scratch. Failed again. I dug deeper and I discovered the download of Ruby was failing. Copied the URL in a browser and it downloaded pretty quickly. Uhm, the plot thickens. Bottom line I spent almost an hour until I stumbled upon the real error, triggered by ruby-build. I don’t remember the exact message but it was along the lines of
"Certificate not yet valid".
What? Why the “yet”? Bottom line, as I deleted all the snapshots my machine went back to the day I installed it, so the date was some day of October 2015. Clearly certificates emitted after that day were not “yet” valid. As I updated the date everything worked as usual.
Many of the critiques towards Dave Winer’s post are along the lines of “cost is not a problem because now Let’s Encrypt is free”. Good. Now read this post about the adventures that the Grow the Team folks had with Let’s Encrypt and iTunes. Succinctly, iTunes didn’t update the podcast feed because there was a failure with SSL. The Let’s Encrypt certificate was not “valid” to the eyes of the iTunes bot. Here’s the discussion on the Let’s Encrypt forums.
By the way this is the same problem that I am having with Podrover. I pull in the feeds to display the timeline of episodes along with podcast reviews. Around 10% of the feeds I pull in fail due to SSL issues. And almost 100% of that 10% are podcasts hosted on third party services that, unlike the Grow the Team folks, can not fix the issue directly.
To be clear, these are not permanent issues. They usually get fixed in at most a few days, usually just hours. But the point stills stands. SSL doesn’t come without overhead. If a service that hosts many podcasts forgets to promptly update their certificate HTTP calls will fail and episodes will not show up in iTunes. Same if the iTunes bot, or the recently released Google podcast service, lazily update their list of trusted certificate authorities. With browsers things are a bit more flexible, and falling back to plain old HTTP is still widely supported. So far.
We rely more and more on processes, scripts and automation. SSL is good in principle but requires orchestration in trusting the same pool of root certificates at the same time on both sides, clients and servers. At the moment I don’t think we are ready for such an orchestrated effort, and as SSL adoption grows we will probably see more and more friction.