Wandering Thoughts archives

You can only really expire cookies on the server

(Every so often I feel like stating outright something that I have previously mentioned in asides in other entries. Today is one of those times.)

Here is an important corollary of the basic rule of website security: if you want your cookies to expire you must force them to expire on the server, not count on web browsers to expire them for you. Neither using session cookies nor putting an explicit expiry time on your non-session cookies will actually make your cookies expire if the user doesn't want them to. Session cookies don't work because users may keep their browser sessions running for weeks or longer, and users can perfectly well edit cookie expiry times for non-session cookies (I've done it to reduce the annoyance level of being repeatedly prompted for a site login).

So you need something on the server to make cookies expire, no matter what the client tells you. If you use session IDs, you need to put the expiry time in your database record for the session. If you don't use session IDs, you need to put the expiry time in the login or whatever cookie and include it in what you sign (and authenticate).

(In the long run it may be better to put in a creation time instead of an expiry time. Using a creation time and then computing the expiry time on the fly in your application means that you can change the expiry duration later without having to rewrite database records or the like.)

A theory on why most browsers control their own list of CA roots

As part of the ipsCA failure, a number of people are noticing that most browsers keep their own list of CA roots, instead of deferring to whatever system-wide list your operating system keeps. There are at least three ways to explain this, depending on how cynical or optimistic you are.

The first is that it is the natural outcome of a ruthless but completely uneven Darwinian struggle for influence (and the benefits it brings) between SSL CA vendors, browser vendors, and OS vendors. Since browser vendors ultimately hold all of the cards in this, they won; how SSL works, including who controls what certificate authorities are trusted (and thus which of them get to make money and who goes bankrupt) is something that they dictate.

(Note that IE 8 is not an exception here; while it uses the Windows list of CA roots, it's written by the same people (well, the same company) as the OS, so the two are effectively the same. Safari and MacOS X is the same way. Chromium is an interesting exception, but Google probably was uninterested in stepping into the SSL snakepit.)

The second and more optimistic view is this has happened because it is the browser that is ultimately on the hook for who they trust. Regardless of who is really at fault, people will not say 'Windows trusted this evil site with a certificate from a bad CA vendor', people will say 'Firefox trusted this clown'. When you are being blamed for things that goes wrong, you have a natural motivation to control it so that you can do something about it.

(Or the shorter version: if you're going to get blamed for it anyways, it might as well actually be your fault.)

The third is that this is at least partly a relic of both the development history of these browsers and, for many of them, their cross-platform nature. Not all operating systems supported by browsers such as Firefox and Opera have any concept of an OS-level CA root list (especially back at the time of their early versions), and so those browsers necessarily have to have their own list on some platforms. Once you are going through the work to have your own list of trusted CAs on some platforms, you might as well do it on all of them (it's less code overall). As a bonus, you make your browser behave the same on all of the platforms that you support; imagine the fun of a bug report of the form 'Firefox accepts this https website on my Mac, but not on three out of five of my Windows machines'.

Brief bits from the evolving ipsCA failure

Some bits on various aspects of the ipsCA root certificate failure.

First, I've seen comments that the new ipsCA CA root certificate should be included in the next update of Firefox. However, I've now found the Mozilla bug about this (via Jeff Ballard), and it makes it seem very unlikely that the root certificate is going to be included in the near future (especially as ipsCA apparently had problems even before this). Interested people can watch Mozilla's CA:Schedule wiki page.

(Here I pause to admire the very long list of CAs asking for inclusion in Firefox et al. I admit that it makes me vaguely nervous. Also, since I just looked this up, it appears that the certificate list for Firefox is in security/nss/lib/ckfw/builtins/certdata.txt in the Firefox source tree. When built, it is embedded in the NSS shared library or DLL.)

Due to this I now have a useful pointer to a bunch of SSL resources. Looking at the complicated procedure for verifying SSL certificate chains makes me wish for a simple utility that read all bundled SSL certificates including in a SSL handshake and then reported any surprise in the Not After expiry dates (chained certificates should never expire in the wrong order, where a certificate 'up' the chain expires before your SSL certificate).

(Then you'd want to configure all of your machines to include the full certificate chain for your CA in their SSL responses.)

So far I am somewhat surprised by how little turmoil and noise there has been about this. If there's going to be much, it may start on January 4th when a lot of universities start up again after the Christmas break. (After all, it was entirely coincidence and luck that I found out about this when I did.)

(Interestingly, Twitter is much more active about this than than the bits of the blogosphere that I can easily search. This may mean something.)