Wandering Thoughts: Recent Entries For 2010/11/14

Four reasons to have a firewall

Recently I ran across someone asking the question 'why have a firewall?' As it turned out, he had several sorts of host-based firewall protection, but in thinking about the question I came up with four broad reasons that firewalls can be a good idea:

• because your services and servers suck. You're forced to run things that were written by addled monkeys, in environments that either require random services of unknown and dubious security impact or just start them up every so often whenever they feel like it. Or perhaps you are stuck with known-vulnerable machines that you cannot upgrade for various reasons.

  (This is perhaps the leading reason to use firewalls in front of end user machines.)

• because it simplifies and speeds up your internal architecture. Yes, you could put SSL and passwords and whatever on your internal memcached instance and your backend database servers and so on, or run them over a disconnected internal network. But it's simpler to just not let people talk to them, and it may give you faster performance.

• because it reduces the amount of code that handles untrusted network input, what security people call the 'attack surface' (the code that aggressors could attack). Sure, your database server has its own access control system, but that's a lot of code that gets run on untrusted input and historically some of it has had bugs. Just not letting people talk to it at all reduces your risk, possibly substantially.

• because it guards against mistakes and accidents in service and host configuration. Without a firewall you are one errantly started daemon, one omitted access control restriction, or one not yet fully installed and patched host away from a security vulnerability.

  (I once put a new webserver on the network and had hits from automated vulnerability scans within sixty seconds of port 80 starting to respond. This is apparently slow as these things go.)

Whether to use host-based firewalls or an external firewall is an implementation decision, but I tend to think that an external firewall is more reliable and simpler to configure and keep straight (if you have a non-trivial internal architecture of what is where and who can talk to it and so on). Of course it is also a single point of failure, as the no-firewall people keep reminding us, so the right thing to do is to have both well protected hosts and an external firewall.

The ordering of SSL chain certificates

SSL certificates for hosts are usually not directly signed by your CA's trust root certificate, the certificate that is in your browser, your mail client, or whatever. Instead there is generally at least one intermediate certificate (sometimes several), and in order for clients to accept your host certificate you need to send them not just the host certificate but also all of the intermediate certificates in the chain of signatures between you and the CA trust root.

How you configure this depends on the server software, with two general approaches. Apache (well, mod_ssl) lets you specify a certificate chain file separate from your certificate itself; you put your certificate in SSLCertificateFile and any intermediate certificates in SSLCertificateChainFile. Exim doesn't have a separate chain file; instead you put both your host certificate and all intermediate in the tls_certificate file.

All of which raises a question: if you're putting several certificates in one file, what's the right order for them and does it matter?

The correct order turns out to be the host certificate first, then the certificate that signs it, then the certificate that signs the previous certificate, and so on for as many levels as you need. Basically, the most specific certificate to the least specific certificate, with each certificate verifying the previous one. Certificates are plain ASCII (with a variety of extensions, .pem and .crt are common) and can just be joined together with cat.

(This tends not to be clearly documented in the instructions for various software (which tends to assume that you are already an SSL expert), but can be dug out of the TLS RFC with enough determination.)

In practice the order doesn't seem to matter. As you might expect, common clients will accept and verify both out of order certificate chains and certificate chains with unnecessary and unused certificates.

(Clients like browsers and IMAP mail clients have a strong motivation to do so, given that server operators get this wrong with reasonable frequency. Other clients may be more picky and paranoid, generally to no real advantage.)

(This is the kind of entry that I write so that I have a chance of remembering this the next time I care about it.)

Sidebar: why you might have unused certificates in a chain file

Suppose (not entirely hypothetically) that your SSL certificate vendor issues certificates that are signed by a number of different intermediate certificates, depending on the specific circumstances where you got them. If you want to deploy certificates without having to look up exactly which intermediate certificate your CA used, the easy thing to do is to throw them all into a single universal certificate chain file. Then you just install the server certificate and the chain file (concatenating the two of them together for things like Exim) and are done with it.