Back in June 2015 I decided to force all connections to trivia over TLS rather than allow plain unencrypted connections. I decided to do this for the obvious reason that it was (and still is) a “good thing” (TM). In my view, all transactions over the ‘net should be encrypted, preferably using strong cyphers offering perfect forward secrecy – just to stop all forms of “bad guys” snooping on what you are doing. Of course, even in such cases there are still myriad ways said “bad guys” can get some idea what you are doing (unencrypted DNS tells them where you are going for example) but hey, at least we can make the buggers work a bit harder.
Unfortunately, as I soon discovered, my self-signed X509 certificates were not well received by RSS aggregators or by some spiders. And as Brett Parker at ALUG pointed out to me, the algorithms used by some (if not all) of the main web spiders (such as Google) would down rank my site on the (in my view laughably specious) grounds that the site could not be trusted.
As I have said before, I’m with Michael Orlitzky, both in his defence of self-signed certificates and his distaste for the CA “terrorists”. I think the CA model is fundamentally broken and I dislike it intensely. It is also, in my view, completely wrong to confuse encryption with identification and authentication. Admittedly, you might care about the (claimed) identity of an email correspondent using encryption (which is why PGP’s “web of trust” exists – even though that too is flawed) or whether the bank you are connecting to is actually who it says it is. But why trust the CA to verify that? Seriously, why? How did the CA verify that the entity buying the certificate is actually entitled to identify itself in that way? Why do you trust that CA as a third party verifier of that identity? How do you know that the certificate offered to your browser is a trustworthy indicator of the identity of the site you are visiting? How do you know that the certificate exchange has not been subject to a MITM attack? How do you know that your browser has not been compromised?
You don’t know. You can’t be sure. You simply trust the nice big green padlock.
Interestingly, banks, and I am sure other large organisations which are heavily regulated, are now beginning to add features which give more feedback to the end user on their identity during transactions. I recently applied for a new zero interest credit card (I like the idea of free money). In addition to the usual UID, password and security number requested of me (in order to identify me to them) the bank providing that card asked me to pick a “personal image” together with a personally chosen secure phrase known only to me in order that they could present those back to me to identify them to me. I am instructed not to proceed with any transaction unless that identification is satisfactory.
So even the banks recognise that the CA model is inadequate as a means of trusted identification. But we still use it to provide encryption.
For some time now browsers have thrown all sorts of overblown warnings about “untrusted” sites which offer self-signed certificates such as the ones I have happily used for years (and which I note that Mike Orlitzky still uses). As I have said in the past, that is simply daft when the same browser will happily connect to the same site over an unencrypted plain HTTP channel with no warning whatsoever. Now, however, there is a concerted effort (started by Google – yes them again) to move to warning end users that plain HTTP sites are “insecure”. Beginning in July 2018 (that’s now) with the release of Chrome 68, Chrome will mark all HTTP sites as “not secure” (sigh). And where Google goes with Chrome, Mozilla, Microsoft and Apple will surely follow with Firefox, Edge and Safari. As much as I may applaud the move to a more fully encrypted web, I deplore the misuse of the word “secure” in this context. Many small sites will now face balkanisation as their viewers fall away in the face of daft warnings from their browsers. Worse, the continued use of warnings which may be ignored by end users (who, let’s face it, often just carry on clicking until they get what they want to see) will surely desensitise those same users to /real/ security warnings that they should pay attention to. Better I feel to simply warn the user that “access to this site is not encrypted”. But what do I know?
I write articles on trivia in the expectation that someone, somewhere, will read them. Granted, blogging is the ultimate form of vanity publishing, but I flatter myself that some people genuinely may find some of my “how-to” style articles of some use. Indeed, I know from my logs and from email correspondence that my articles on VPN usage for example are used and found to be useful. It would be a shame (and largely pointless) to continue to write here if no-one except the hardiest of souls persistent enough to ignore their browsers ever read it. Worse, of course, is the fact that for many people, Google /is/ the internet, They turn to Google before all else when searching for something. If that search engine doesn’t even index trivia, then again I am wasting my time. So, reluctantly, I have decided now is the time to bite the bullet and apply a CA provided TLS certificate to trivia. Some of my more perceptive readers may have already noticed that trivia now defaults to HTTPS rather than plain HTTP. Fortunately, letsencrypt, offers free (as in beer) certificates and the EFF provides an automated system of both installation and renewal of the necessary certificates. So I have deployed and installed a letsencrypt certificate here.
I still don’t like the CA model but, like Cnut the Great (and unlike his courtiers), I recognise my inability to influence the tides around me.
[Postscript]
Note that in order to ensure that I do not get a browser warning about “mixed content”, in addition to the necessary blog and lighttpd configuration changes I have run a global search and replace of all “http://” by “https://” on trivia. Whilst this now gives me a satisfyingly good clear green A+ on the SSL Labs site, it means that all off-site references which may have previously pointed to “http://somewhere.other” will now necessarily point to “https://somewhere.other”. This may break some links where the site in question has not yet moved to TLS support. If that happens, you may simply remove the trailing “s” from the link to get to the original site. Of course, if that still doesn’t work, then the link (or indeed entire site) may have moved or disappeared. It happens.