Wandering Thoughts archives

An irritation with current GUI interfaces

Why are programs so convinced that I have horizontal real estate to give them? Everything seems to want to put important information in sidebars and panels and so on (usually non-optional ones).

I don't know about other people, but for me horizontal screen space is more precious than vertical screen space. If you eat vertical space all that happens is that I get fewer lines of your real content (which is still irritating; please don't). But if you eat horizontal content, your application gradually takes over my entire screen, because I don't have any space left to put things besides it.

(It's no wonder that running one program at a time in full-screen mode is so popular.)

I don't know where this design approach comes from, although I suspect that some of it is a lingering remnant of MDI (itself one of the more wretched and arrogant ideas in GUI interfaces).

(I don't consider the ever-expanding sidebars approach to be true MDI because I restrict my MDI hissing and spitting to interfaces that leave dead space inside their window.)

If programs have to have this sort of interface, I wish for two things: the ability to completely close the sidebars (many programs seem to give them a minimum size) and the ability to rip the sidebars off as separate top-level windows, so I can park them somewhere more useful. Programs earn bonus points for remembering how big I had sidebars before I closed them and then re-opening them at the same size.

(This rant has been brought to you by the current interface of Evolution, which glues a list of accounts and folders to the left side of the content window, even when all I am doing is reading email from one folder and it is a complete waste of space.)

Why host authentication has to check who the certificate belongs to

When using host SSL certificate to authenticate a host's identity, you can't just check that your CA signed the host's certificate; you also have to check that the certificate belongs to the host (usually by checking that the certificate's CN is the hostname, or IP address, or etc). The reason you need to make this additional check of the certificate is that without it, you don't know if the certificate actually came from the host you're trying to authenticate.

Imagine that you have two client machines, A and B. A and B can talk to each other's SSL host authentication service (why not, after all). An attacker wants to impersonate B. If you do not check what host the certificate belongs to, the attack goes like this:

The attacker waits until the real B is down. They configure their impostor machine to have B's IP address, and sets it up to NAT-forward incoming connections on the SSL authentication service's port off to A. Then they make a request that starts an authentication attempt. Your server calls the fake B up to get its SSL certificate; B forwards the request off to A, and passes A's packets back. As far as the server sees, it is talking to B and B is presenting a valid, CA-signed certificate, so the authentication succeeds.

It follows as a corollary that you can't issue generic CA-signed certificates for host authentication; you must issue host-locked ones.

(You can use some additional verification on top of SSL like the host echoing back its hostname to the server, but this is equivalent to checking that the SSL certificate actually belongs to the host.)

I suspect that this is well-known to crypto people, but I didn't realize it until recently. (One moral I draw from this is that designing security protocols is hard and I should do as little of it as possible, just in case.)

Why I want direct certificate checking instead of having to rely on CAs

The common SSL model is that you verify someone's good nature by checking to see that their certificate is signed by an approved CA. For example, if you are verifying that hosts you are connecting to are approved you would make up a CA certificate, then make up a bunch of host certificates and sign them with the CA certificate. When you connect to a machine, you verify that its certificate is signed by your CA certificate.

(Except that that's a simplification; you actually need to verify that the certificate is signed and that some identifying information in it is correct, such as the machine's hostname being the CN.)

The alternate approach is to directly check that each host's server certificate is in your list of approved certificates (and perhaps that it comes from the host that you expect it to). I maintain that this is the better approach for situations such as host verification.

The problem with the CA approach is dealing with bad certificates. First, you need to use not just a CA check but CA plus CRL, because if you just check for your CA signature the only thing you can do when a host certificate is compromised is to change to a new CA certificate, which invalidates all current host certificates. Unfortunately, CRLs are not widely used in the wild, so they are not necessarily well supported in tools.

Even with CA plus CRL you still have the risk that an attacker has managed to get some signed host certificates of his own (whether by quietly compromising your keys or by surreptitiously inserting things into your processing pipeline). Since you do not have copies of these certificates yourself (unless you catch one live during a host verification attempt), you cannot generate CRL entries for them; if you think this may have happened, your only recourse is to change your entire CA certificate.

By contrast, directly checking that you know each host's server certificate is much easier and more direct. You have a complete list of what certificates you accept and who you accept them from. If a certificate is not there, you know it will not be accepted; invalidating a bad certificate is as simple and precise as rm.

(Plus, you do not have to maintain and keep secure a CA signing setup.)

What this boils down to is that the CA approach is 'everything that is not explicitly forbidden is permitted' (if it is signed by your CA certificate it is allowed unless it is in your CRL), whereas direct certificate checking is 'everything that is not explicitly permitted is forbidden' (it is only accepted if it is in your list of good certificates). The latter is a much stronger security model, plus is easier to manage until you grow quite large.

Why I don't have a GPG key

In theory I ought to be just the sort of person who has a GPG key; after all, I'm geeky, quite aware of how easy it is to impersonate people on the Internet, reasonably concerned about privacy, and so on. But in practice I don't have one because I don't feel I could keep it secure enough for what people believe a digital signature implies.

As a system administrator, I get to be quite aware of all the ways that a bad guy could attack the machines I want to use GPG on. For example, even if I just used GPG on my office workstation (instead of the multi-user machine where I actually read most of my email), the workstation is on the Internet, it runs various services, it allows remote logins, I browse the web from it, I view PDFs on it (there have been PDF viewers with exploitable security problems), and it's only moderately physically secure. That's a lot of potential exposure.

This doesn't matter for normal email and the like, because people are prepared to believe that it can be forged, or someone can manage to log in as you, or whatever. But I think that people have been persuaded to have far more trust in digital signatures, enough trust that the consequences of my digital signature getting compromised are too (potentially) severe for me to feel comfortable. People really seem to feel that a valid GPG signature is a guarantee that something is not forged.

(Yes, talk about strong non-repudiation makes me twitch.)

One may argue that I am unlikely to be attacked to get my GPG key. There are two answers to this. First, I don't have to be attacked specifically; most machine compromises are happy to just hoover up anything they can get their hands on, passwords and keys included, and most crackers are happy to collect any vulnerable machine, no matter how small it looks initially. Second, the more weight and non-repudiation and so on people put on my GPG key, the more valuable it is to an attacker, and thus worth targeting moderately specifically. (And we know that people are launching carefully targeted attacks these days.)

Thus, all in all I consider it significantly safer at the moment to have no GPG key.

It's a pity, because I would really like lightweight digital signatures as a protection against SMTP spoofing and the like (and I think we would be significantly better off in such a world). But that's not going to happen until we train people out of heavily trusting digital signatures, and I think that's going to take people getting burned fairly badly by their current beliefs. And I'd rather not play the role of the unfortunate forged victim in that scenario, because it's not going to be a comfortable one.

(Another reason I am jumpy about the security of my theoretical GPG key is that I am sufficiently nervous about forgetting really important and non-recoverable passwords that I want to have them written down in a secure place. Which is of course against all of the principles they tell you about keeping your GPG key safe.)