The time has finally come to switch everything to https. Actually, I’ve been using https for a while, but now it’s time to inflict, er invite, everyone else along for the ride.

There is some security benefit, of course, but really it’s all about the speed. I want flak to be as fast as possible, thus we need to be using the fastest protocol.

On the security front, however, there may be a few things to mention. Curiously, some browsers react to the addition of encryption to a website by issuing a security warning. Yesterday, reading this page in plaintext was perfectly fine, but today, add some AES to the mix, and it’s a terrible menace, unfit for even casual viewing. But fill out the right forms and ask the right people and we can fix that, right?

I find it strange, to say the least, that I am required to request permission from the authorities to make a secure web site. When I first created flak, there was very little paperwork. I started a server, and that was that. Do we really want an internet where the use of encryption requires authorization?

What if the authorities say no? Maybe not because they find me personally objectionable, though that’s certainly worth considering, but what happens when they inevitably fuck up some simple thing like leap seconds or URL parsing or whatever? In my experience, reliability is not increased by increasing external dependencies.

Having opted out of having the authorities say I’m me, can I opt out of having them say anybody else is me? Alas, no. There is a secret browser handshake to partially opt out, but the wrinkle is that it first requires opting in. No way to actually decline the whole mess.

But not all is lost. I have created my very own certificate of great authenticity. (sha256 on the front page.) Before rushing to install, however, one might consider the consequences. What if I go rogue and sign a bunch of other sites I’m not supposed to? A reasonable concern if you don’t know me. But how well do you know the 300 people controlling the certs you do trust? Do you even know their names?

Or maybe the creation of the rogue cert is not deliberate, but accidental. My signing protocol is currently “try not to fuck up too bad” which is probably shorter than the elaborately documented procedures and safeguards some other people use. Thus, we have the setup for a grand experiment. Who will improperly sign a certificate for a domain they don’t own or release a “testing only” cert into the wild first, me or someone else?

To swing, briefly, back to the good news, my cert uses the name constraint extension, so in theory it should only be valid for my domain and of little risk to the internet at large. Like much of X.509, this seems slightly backwards: as the user about to install this cert, you should be telling the cert for what sites you trust it, instead of the cert telling you what’s trustworthy. Be aware that software support for name constraints is somewhat hit or miss, and it fails open, so make sure to consult the user manual for your browser. I’m sure it mentions name constraints in there somewhere. (I could, should?, mark the constraints as critical which in theory would mean that unsupported software would fail closed, which would indeed be safer, but then it becomes very difficult to override that, returning to the idea that too much information about the trustiness of a cert is contained within the cert itself. The absence of the critical marker does’t affect or degrade security for modern software.)

So how does one verify that the downloaded cert is the original? The same way the CAs do. Perform a DNS lookup, make a web request, trust the result. The addition of HPKP would indicate that people find the CA model untrustworthy, solving the problem with trust on first use key continuity. Why not cut out the middle man? Protesting the CAs is admittedly pretty futile, but if I can’t do it, who can?

One difficult wrinkle is that not everyone controls their own trust chain. A remote service RSS reader may not even offer the option to modify its https behavior. The perils of depending on software one doesn’t control. For now, RSS URLs are exempted from the redirect, but eventually that will be sealed off as well.

Automated sentiment analysis: good news with a side of bad news with a side of good news with a side of bad news with a side of good news with a side of bad news with a side of good news with a side of bad news. Most likely topical match: TLS.