Wandering Thoughts archives

The consequences of your SSL certificate getting compromised

Suppose that your web server's SSL certificate's private key is compromised and stolen by an attacker. Further suppose that you detect this and replace the compromised certificate with a new one. Now, here's a question: what damage can the attacker still do with their stolen certificate?

• they can impersonate your web server. In theory they can only do this until their stolen certificate expires; in practice, I think that many users ignore 'expired certificate' errors because they are relatively common.

  (SSL certificate revocation would protect against this, if it worked.)

• they may be able to decrypt any past SSL conversations that they've already captured, depending on what cipher was used.

The attacker cannot decrypt future SSL conversations, because those will be protected by your new certificate even if the SSL conversation uses a cipher without forward secrecy.

If the attacker compromised a wildcard certificate they can imitate any of your web servers, regardless of what certificate the web server normally uses, but can only potentially decrypt past conversations from web servers that used the wildcard certificate. (Of course, if you went to the bother and expense of getting a wildcard certificate, you're probably going to use it on all of your web servers.)

I believe that the only relatively certain way of stopping an attacker's use of the stolen certificate is to remove the name from your DNS. Of course, this often presents certain difficulties.

(It is not safe to turn the compromised name into a website that just redirects people to the new name, because that means that users are still using the old name; the attacker could interpose their fake version and just not redirect to your new name.)

A side note to the attraction of file-based blog engines

One grumpy view of the attraction of 'file as blog entry' blog engines is that they are only attractive to people who don't know enough about their problems and once you come to really understand the issues you can see that they are actually a bad idea. That they are fairly popular is just because most people fall into the 'don't know enough' category and can only see the 'superficial attractiveness' of such engines.

(This should sound awfully familiar; similar things have been said about all sorts of other technologies.)

Adopting this point of view is a mistake. Regardless of any theoretical flaws that they may or may not have, it is very clear that file-based blog engines work in practice, and work well enough for people to be happy with them. Saying that such people don't know what they're missing and will regret it later is, while potentially correct, basically pointless. In this regard, good enough is the enemy of perfect and always has been.

And despite my words on the subject, I have to note that this point of view also overestimates the current practical importance of the things that file-based blog engines make difficult. Things like truly stable syndication feed identifiers and good handling of entry updates may become crucial features at some point in the future, but they are manifestly not that important right now, given that lots and lots of blogs get by fine without them. (Heck, I'm still not sure that having a syndication feed is an essential blog feature yet.)

(So, what's an essential feature? I'd say one that costs you a significant number of potential readers if you don't have it, something that has become part of the minimum accepted features of blogs for people. While I and most people I know use a feed reader, I'm not an average blog reader, so I'm not sure that feed reader usage is widespread enough in general to make syndication feeds qualify.)

The attractions of 'file as blog entry' blog engines

Despite their issues, blog engines based around the idea an entry is a file are undeniably popular (after all, I wrote one myself). Clearly there is something inherently attractive about the idea. In fact, I think there are two main attractions:

• you can do a lot of things by hand in a simple environment, starting with writing entries. You do not need to log into an administrative interface and start ticking checkboxes and filling in form fields; you go to a directory and start your editor or whatever.

  (As part of this, you get a decent editor. In fact, you get a whole suite of tools for free, up to and including sophisticated version control, provided that you overcome a potential issue.)

• the system is (or at least appears) simple and directly inspectable. The state is immediately obvious and visible, not locked up in a more or less opaque thing by the application. As a side effect, it is possible to manipulate the state of the blog engine by manipulating files.

  (I think that part of why this is attractive is that to most people, the important thing about a blog is the data, the entries and so on. Everything that the blog engine does just puts a pretty frame around the data, yet the blog engine wants to swallow up the data in the process. For your own good, of course. Honest.)

These two advantages are more or less independent; for example, it is possible to have a blog engine where you cannot hand-author entries, but the entries are still stored as plain files in the filesystem. Conversely, you could have a blog engine where you hand-wrote entries but the blog engine maintained an internal database of necessary metadata about entries that you couldn't touch.

Because the two are independent, people can have different opinions on how important each advantage is. For example, I am very attached to being able to write entries by hand but less attached to what I could call the blog engine's storage format.

Sidebar: a third attraction for technical people

Okay, honesty compels me to admit to the third attraction: if you're a reasonably technical person, the idea of a 'file as blog entry' blog engine looks pretty simple and easily to put together. (Doing a good job of the implementation is, I am convinced, not as easy as it looks.)

This makes the blog engine feel reassuringly simple and predictable; after all, it's clearly not a complex job and we could code one if we had to. In fact, any number of people do code their own simple blog engine built around this model.

I suspect that this particular attraction is more or less an accident of history, and that in the future people will be at least as comfortable with database-based technology and approaches such as Ruby on Rails.

999 days is not forever

One of my peculiar perversions is that I want my browser's history of visited URLs to stick around forever (or at least to not expire in a a crude time-based way). Firefox doesn't have an option to do this, but it does have an expiry time in days in a field that only accepts three digits, and back in the halcyon days of yore when I switched to Firefox and set it up, 999 days seemed acceptably close to forever.

Recently, I noticed that some of WanderingThoughts' old entries were coming up as unvisited URLs when I looked at the index page. I was immediately alarmed, thinking that I might have some sort of history file corruption issue (a big deal when you care as much about an intact history as I do), until the penny dropped.

To wit: 999 days is not forever; instead it is less than three years (in fact, it's about 2.7 years). As it happens, I've now been writing WanderingThoughts for longer than that, so of course the earliest entries were getting expired from my browser history. In fact, things must have been quietly expiring for some time (probably several years), and this is just the first time I have actually noticed it.

(If you ever find yourself in this situation, the way to work around the issue is to use about:config to directly set the values of browser.history_expire_days to 9999 days or so; you may also have to set browser.history_expire_days.mirror. I am sufficiently old-fashioned that I edited my prefs.js by hand.)

Amusingly, I ran into this issue again during some recent testing. I wanted to test how Firefox 3, with its fsync() issue, would work on our new ZFS-based NFS fileservers, and I figured that the problem was most likely to manifest with a big history file, such as my normal personal one. However, I couldn't just copy my regular history file into a test account's Firefox 3 setup, because I am still using a much older version of Firefox, with an older history file format.

So I had to set up Firefox 3 in the test account, delete its regular new-format history file, copy in my old history file, run Firefox 3 again, and after I quit out, check to make sure that it actually had migrated my history file to its new format. Which it didn't seem to have done, because the new history file was much, much smaller than my normal history file. But at the same time, some of the links that should show up as visited were doing so, so it clearly wasn't ignoring it entirely.

That's when I realized that, of course, the test account's Firefox 3 setup was using the default browser history expiry interval, and so most of my very large, very old browser history was being converted, just as I wanted, and then promptly getting expired when I closed the browser down. A quick preference change later and everything was fine (and our ZFS-based NFS fileservers seem to be okay with Firefox 3, which was good news for putting them into production).