My current Apache SSL cipher settings
Like a number of other security protocols, TLS (aka SSL) comes in several generations and offers a large selection of potential ciphers. Many of these options are actually a bad idea from a security perspective; the ciphers are weak or use things that have been broken, and older versions of SSL have known weaknesses. By default, Apache's mod_ssl enables them all and even sometimes defaults to (very) bad choices, all in the vague name of accommodating some export version of a browser from 1997 that might perhaps show up some day and be unable to do any version of SSL since then.
(More realistically, the mod_ssl defaults were probably set ten years or more ago and have not really been changed since then for all sorts of reasons. Well, actually these are more like the OpenSSL defaults, since mod_ssl defers most of these decisions to OpenSSL.)
I've recently decided to start changing that in our Apache SSL configurations, partly prompted by this and this (PDF). My current settings are to not support SSL v2 at all, disallow 'export' ciphers, which were deliberately made really weak so that they could be easily decrypted, and disallow everything that OpenSSL considers a low-strength cipher (which actually includes export ciphers).
Specifically, I'm setting:
SSLProtocol all -SSLv2
This is more or less researched from the Apache documentation. It's tempting to explicitly disallow MD5, although I don't know if this is just superstition.
Now, two cautions apply here. First, our SSL sites are by and large for internal use, so I can afford to be somewhat casual about how many ciphers I support; if this turns out to be a too small set, I will hear about it. Second, our web servers are nowhere near CPU constrained so I don't care very much about which good cipher is the most CPU-efficient; a more active site might well.
(Considering that SSLv3 dates from 1996, disabling SSLv2 should be really quite safe by now.)
It would be nice (I say wistfully) if software like mod_ssl would come preconfigured with a sensible and limited set of ciphers and perhaps notes on really ancient software that's known to require you to use less than ideal cipher choices.
(Partly I am writing all of this down now so that I have a reference for it later.)
Thinking about how long our infrastructure will last
Something that I've been thinking about recently is when we need to start thinking about turning over our fileserver infrastructure, or in the alternate way of thinking about it, how long we can make the infrastructure last. Since this could get very theoretical, I'm going to nail down a specific question: is it reasonable to assume our current infrastructure will last at least five years from our initial deployment? We don't seem likely to run into capacity limits, so one major aspect is the issue of how long the hardware and software will last for.
(Our initial deployment was about two years ago, depending on how you count things; we started production in September 2008 but only finished the migration from the old fileservers some time in early 2009.)
On the hardware front, our servers are not running into CPU constraints or other hardware limits that would push us towards replacing them with better machines. This leaves the lifetime of the mechanical parts in them (such as fans), and we have both spares and similar servers that have already been running for four years. So the odds are good. The SATA data disks in our backends are more problematic. They're under relatively active load and asking five years or more from consumer grade SATA drives may be a lot. While we have spares we don't have a complete replacement for all disks, which exposes us to a second order risk: long term technology changes.
SATA drives are not going away any time soon, but they seem likely to be changing a lot as vendors move to SATA drives with 4k sectors. It's possible that our current stack of software will not perform very well with such drives, given that other environments have already run into problems. If that happens we could be forced into software changes.
(I don't think 10G Ethernet is a risk here for reasons beyond the scope of this entry.)
On the software front, our software is both out of date and basically frozen (we have very little interest in changing a working environment). However, we aren't going to be able to do this forever; the likely triggers for forced major software changes would be the end of security updates for the frontends or significant hardware changes (such as 4k sector drives). Both are currently unknowns, but it seems at least possible that we could avoid problems for three more years.
(The backends run RHEL 5, which will have security updates through early 2014 as per here. The practical accessibility of Solaris 10 security updates for the frontends is currently quite uncertain, thanks to Oracle.)
One obvious conclusion here is that we should get a 4k sector SATA drive or two in order to test how well our current environment deals with such drives. That way we can at least be aware in advance, even if we aren't prepared.