Wandering Thoughts archives

Why a free SSL Certificate Authority is not horrifying

Back in this entry I casually mentioned in passing that there is a CA that will give you completely functional SSL certificates for free. To some people this will be horrifying; after all, as the story goes, SSL certificates are supposed to cost money so that they mean something and verify your identity (well, your website's identity).

The truth of what is going on here is that these free certificates contain exactly as much verification of your identity as everyone else's. In fact they may contain more verification, because this CA actually performs automated tests to verify that you have some control over the domain you want a certificate for; I don't know how much checking other CAs do besides making sure that they can charge your credit card. This particular CA is simply being honest about how much this particular 'service' costs to provide, ie essentially nothing. So they give you basic SSL CAs for free and charge you if you want additional features.

(There are a number of CAs that will give you free but short duration SSL certificates for testing purposes. This CA gives year-long ones and will happily issue you new ones for the next year.)

Given my long-standing irritation with what I've called the SSL CA racket, I'm kind of glad that there is a CA that is willing to be honest about exactly what's going on. If it horrifies people and offends them that such a CA is trusted by browsers, well, good, maybe it will spark a little reflection about what SSL CAs are really providing and not providing.

On a pragmatic basis, given that SSL certificates are a commodity and you can now obtain this commodity for free (which demonstrates its actual natural price) I see no reason to pay for basic SSL certificates any more.

(I continue to not name the SSL CA for a number of reasons including that I don't feel like doing their marketing for them. It isn't difficult to work out what CA it is, either with some web searches or by checking the SSL certificate chain for the website I mentioned in the earlier entry.)

Sidebar: what I mean by a basic SSL certificate

By a basic SSL certificate I mean one for a single name without wildcards. Single name certificates are slightly inconvenient but my impression is that SNI support is now common enough in both servers and (modern) clients that you can deal with this if you have to.

(I was pleasantly surprised about how few things I tried had problems with SNI after I set it up on various subdomains of my personal domain. Of course smartphones may complicate this pleasant picture.)

Some thoughts on going to HTTPS by default

My Twitter feed recently dropped a link to Tim Bray's Private By Default in front of me so I read it, nodded along in agreement, and started thinking about doing it myself for my personal domain. The technical side was easy and pain-free, since there's a Certificate Authority who'll give you free basic SSL certificates. But that's as far as I've gone due to what I've come to think of as the problem of really committing to HTTPS.

If I was doing this seriously, I would redirect all HTTP traffic to the HTTPS version of my site (because otherwise much of the existing traffic won't shift). But doing that implies an ongoing commitment to HTTPS. If people are using HTTPS URLs I need to keep those URLs working and in turn that means I need a duly CA-approved SSL certificate. Right now I can get such a thing for free but there's no guarantee that this will continue to be the case in the future; at that point, well, I have to cough up some money. And I'm not at all sure that I'm enthused enough about HTTPS everywhere to actually pay for it.

(I agree with all of Tim Bray's arguments for it intellectually. But buying a SSL certificate is not just money, it's also hassle. For that matter, using an SSL certificate is an ongoing hassle if you really care about security because then you get to wade into the great SSL cipher swamp every time a new threat emerges.)

But is this actually a real worry? Presumably I ought to have at least some warning that my next certificate will cost me money; at that point I could start redirecting my HTTPS traffic back to the HTTP version of the site and I should have some amount of time for the redirections to take effect before the certificate expired. In the extreme case I could get the cheapest one-year certificate available to have a full year for the transition (and extremely cheap SSL certificates don't seem likely to go away). Also the HTTPS version of the site wouldn't go away entirely because I'd probably put up a self-signed certificate just to keep the URLs valid (although visitors would get the usual scary browser warnings). How much this affected people in practice would depend on how many saved HTTPS URLs there were for my site out there in the wild.

(In a world of ephemeral social media and search-driven navigation that's probably a good question in general. I have no answers.)

The apparent source of my Firefox memory bloat problems

I recently took another shot at trying to get rid of my long-running Firefox performance problems, which I had narrowed down to garbage collection stalls resulting from memory bloat. The good news is that I seem to have found what was causing my memory problems. The bad news is that it's in extensions that I more or less care about.

The first necessary disclaimer is that I haven't gone through the painstaking work to test extensions in isolation (especially in my normal browsing environment). What I can say is that using just my core extensions of NoScript, FireGestures, It's All Text, the last working version of CookieSafe, and the Mozilla all-JavaScript PDF viewer leaves Firefox's memory usage stable and performance excellent. If I add either or both of Stylish and GreaseMonkey, memory usage climbs slowly but steadily and I see my usual performance issues. Given that GreaseMonkey is a heavily used extension, I suspect that my problems with it are due to either some interaction with my other extensions or with the specific user script that I use. The same may be true for Stylish (although there is one review that suggests other people are having memory problems with it).

(While I haven't seen memory bloat with Status-4-Evar, having it active seems to make Firefox's scrolling somewhat less snappy for me. Without GreaseMoneky and Stylish, the status bar is relatively empty anyways so I've currently experimenting with disabling S4E.)

Although I called GreaseMonkey and Stylish essential extensions back here, I can in practice live without them. Having mangled Google search results and various badly formatted websites irritates me, but I can sort of live with them (and the cure for the latter is to stop visiting those websites). I wish I didn't have to, so I keep hoping that Firefox will come up with a better solution for whatever is causing these leaks.

(Given that my bloat seemed to involve a lot of compiled JavaScript code sitting around, I'm now wondering if Firefox has something like Java's PermGen issues with loaded code and compiled/JIT'd functions sticking around when they shouldn't.)