Moving to HTTPS
Some notes on my journey to move to HTTPS for the Wok and related sites
Some of you may have noticed that the Wok is now accessible via HTTPS. I expect this may break things here and there (in fact, I've already had to patch up stuff, especially in older articles, which has been an interesting dive into the past), but the transition so far has been going surprisingly (for me) smoothly.
So, why?
I actually tend to lean towards Dave Winer's position concerning HTTPS, although possibly somewhat less extreme. It's a nice-to-have with its valid raisons d'être, but most of those don't actually apply to an open-access, passive, statically generated site such as this.
(And honestly, even most of the claimed benefits of HTTPS are not what they are claimed to be. Just to mention one of my pet peeves, social networks: does HTTPS being used to serve them guarantee in any way that my Mastodon profiles are “genuine”, for any meaning of the word? Of course not. Any administrator with access to the database can pretend I wrote things there I never wrote, for example. And the situation isn't any better —if anything, in fact, much worse— for content served by Big Tech. Some more notes on my position: 1 2 3 4 5 6 7 8 9)
(Maybe I should have called this section “Why not?”)
So, why did I ultimately choose to add it? You'll never guess why.1
So, how?
I took advantage of the Let's Encrypt initiative for the certificate management:
installed certbot and its GANDI plugin
(since that's the registrar for my domain)
got a certificate for oblomov.eu
and then realized I needed one for the subdomains too,
and because it was late at night and something I'm not familiar with,
I ended up issuing a new one instead of just adding *.oblomov.eu to the existing one,
which turned out to be a problem for access to my “main” site,
and finally found how to add domains to a certificate,
so added oblomov.eu to the new certificate and revoked the first one,
and then had to convince Firefox that yes, the certificate had changed
(it's possible I did something wrong in these final steps).
For the webserver configuration, I used certbot itself to configure HTTPS on my main site,
after which I hacked up the configuration files so I didn't need to duplicate stuff
for the HTTP and HTTPS virtual hosts
(the trick here is to put the actual directives in a separate file,
which is then included from from the :80 and the :443 virtual hosts specifications).
My intent was (and remains) to keep my sites accessible both via plain HTTP and HTTPS (for reasons), but I had to ensure that when going through HTTPS it would be “secure” (meaning: no loading of plain HTTP resources). This is generally easy to achieve, by simply omitting the protocol part of URLs (which means the browser will use whatever protocol is currently being used for the page). I was not happy however to find out that this isn't possible to the fullest extent I intended, since —for example— links in RSS and Atom feeds (or in sitemaps, for example) require a protocol, so one has to decide on a canonical protocol. I've ultimately decided to make HTTPS the protocol for canonical URLs, to save Egyptian politicians from MITM attacks, but I'm not happy about the decision.
I'm wondering if it would be worth looking again into the Gemini protocol now that I have certificates and everything, although there's still the issue that Gemini clients expect Gemtext and don't play nice with HTML, (and I'm not really looking forward at “Gemtextifying” the Wok, nor does Ikiwiki support Gemtext as an output format, even though it shouldn't be too hard given that the source is mostly plain Markdown).
The Gamepad API requires a secure context, and I wanted to add gamepad support to Finger Maze. Of course, once I had to get a certificate for one subdomain, why not go the whole way? ↩