Trust, but verify [LWN.net]

Trust, but verify

Posted Feb 22, 2010 15:19 UTC (Mon) by micah (subscriber, #20908)
In reply to: Trust, but verify by djao
Parent article: Trust, but verify

(disclosure: i contribute to the monkeysphere project)

djao said:
> The critical feature of the SSH trust model is that it has no trust
> model. It is entirely up to the user to verify the key. For a capable
> user, this is no problem, because such a user knows how to verify a key
> out of band. For the unskilled user, this method is still better than
> any other alternative, because it involves the least complexity. The
> concept of "store this key please, and notify me if it ever changes" is
> a lot easier for average users to understand than anything involving
> certificates or webs of trust.

You are right that this method is uncomplicated, however it encourages users to "click through" and fail to verify in the same way that people click through SSL certificate failure windows in their browser. This is bad behavior reinforcement. All too often the most capable users fail to verify keys out of band, and just type "yes" at that ssh host-key prompt so they can get to the machine. The number of admins that I know who accept a ssh host key fingerprint without verifying it are frighteningly low. Even fewer admins make those fingerprints available to others via a cryptographically verifiable mechanism. The reasons why capable people don't do this are varied, but one reason might be that it is not obvious where or how you should check this fingerprint. The fact that so many people accept these host keys without verification because there is no clear way of doing that verification is a problem.

Likewise, if you have verified the FP of a host key, and then it does change because the admin had to re-key (perhaps as the result of a routine rebuild of the box). Next time you connect, you will be presented with the ssh Big Scary Warning(tm) and you will need to remove that host key, find out what happened and then verify a new host key before you can continue. This is a good thing, although annoying to have to deal with when the re-key was done on purpose by the correct people running the machine and if you have no reliable method of verifying that this new host key is the right one and that this change should have happened.

Both the scenario of a user connecting to a machine for the first time and being asked to verify a host key, as well as the scenario of the admin needing to re-key the machine are made smoother by the use of the Monkeysphere because it makes the mechanism more simple, more clear and now only presents you with these questions when absolutely necessary. This reduces the "click through" reinforcement and raises the importance of those messages, as they appear only when something is wrong. The user is now *only* prompted to confirm a host-key fingerprint if they have no mechanism of trust to verify the key, or if there is an actual man-in-the-middle. The admin can do a re-key and re-certification smoothly, without freaking out the end-users.

djao also said:
> I view MonkeySphere in the same category as VeriSign and other
> companies trying to extort money from users for providing
> inferior security. They are worse than a solution in search of a
> problem. They are actually creating new security problems where
> none existed before, in the name of profit.

Clarification: Monkeysphere is *not* a profit-driven enterprise. It is not a company, and it is not involved in extortion of money. The Monkeysphere is a free software project, just a few regular folks getting together to hack, in the name of freedom, not profit.

(Log in to post comments)

Trust, but verify

Posted Feb 22, 2010 17:14 UTC (Mon) by nix (subscriber, #2304) [Link]

(I've said this before. Sorry for repeating myself, but, well, I think it bears repeating every so often.)

All too often the most capable users fail to verify keys out of band

A large part of the problem here is that everyone who uses multiple Unix machines by now uses OpenSSH, but the manpages say nothing about how to verify the validity of the remote host key if you get a man-in-the-middle warning. The SSH book may, but anything that depends for its security on all its users buying an expensive book is not going to work.

(FWIW, it was nine years after I started using OpenSSH that I figured out what the fingerprints that ssh-keygen could print were good for, and I'm not technically clueless, merely not a crypto geek. Maybe if I was a crypto geek I'd have known this instantly on reading the manpage, but, again, not everyone is a crypto geek, and you shouldn't have to be a crypto geek to be secure. Right now, thanks to documentation issues like this, no matter how secure OpenSSH is technically, it's open to all sorts of social-engineering attacks simply because its users can't tell how to respond to reports of potential security problems. I'd fix this, but I can't because I don't know the answers myself.)

This is not an academic problem. Last month I got a panicky Sunday phone call from one huge banking client, who'd reinstalled a production server and had started getting 'IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY' errors. It took a lot of effort to calm the poor man down, and he kept on asking why none of the documentation he'd read had explained what the 'SOMETHING NASTY' might be, or had bothered to say 'if you reinstall your OS but keep the same IP address, you'll get this message on all the machines that connect to it'. Then he asked how to identify all those clients and teach them what the new machine was, and I had to say there wasn't a way: ssh-keyscan(1) does the opposite. That didn't go down very well. He's constructing known-hosts files centrally with ssh-keyscan(1) and pushing them out to clients, now, but of course none of the documentation mentions that you might need to do that, either. (Admittedly I hadn't thought of it either, until it was too late.)

(this is your annual djm@ nose-tweaking. I think it's been almost a year since my last one. Anyone written that HOWTO yet? It's really silly that's not there, it's probably vastly simpler to write it than OpenSSH was to write... at least a wiki somewhere on which people can collect common OpenSSH problems and solutions to them, so Google can pick it up. Now that I can set up, I just haven't, so pre-emptive apologies, also I only thought of it ten seconds ago.)

host key backup

Posted Feb 23, 2010 7:10 UTC (Tue) by xoddam (subscriber, #2322) [Link]

> 'if you reinstall your OS but keep the same IP address, you'll get this message on all the machines that connect to it'.

To save this happening again (and again ...)

Would it make sense to (remotely) backup the host key and restore it after the reinstallation?

There could well be something I'm missing...

host key backup

Posted Feb 23, 2010 22:56 UTC (Tue) by nix (subscriber, #2304) [Link]

Yes, it would. But people don't always do that (often they don't even
realise what the host key is *for* until it's too late, and then, oops!).

More than once I've seen disaster-recovery hosts hotswapped into the place
of the machine they replace, IP address and all... but oops! they have a
different host key! Too late to fix, the original machine is dead now.
(Yes, this is a configuration error. But it's a pretty common one. More
common than not, I'd almost say.)