| |||||||||||||
Trust, but verifyTrust, but verifyPosted Feb 19, 2010 20:30 UTC (Fri) by djao (subscriber, #4263)In reply to: Trust, but verify by tialaramex Parent article: Trust, but verify I would go even farther: the truth is, even the centralized trust model is too complicated for average people to use. Note that I am a professional cryptography researcher, although unlike many other researchers, I pay attention to what is practical and what is not. It doesn't take very much searching to dig up various instances (1, 2) where centralized certificates fail to provide the level of security that they theoretically guarantee. SSH, however, has never been attacked cryptographically via its trust model, even though it's clearly a worthwhile and lucrative target -- if you don't think so, just look at the number of SSH brute force attacks in the wild. 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. It is also interesting that, in practice, the null trust model used by SSH tends to produce better results than any other trust mechanism, quite independent of the human factor advantage of its lower complexity. Most of the time, when you make a secure connection to a server in a context where you care about security, you are connecting to a server that you have used before. In this situation, you know what the server's key was before, and you can compare it to the key that it has right now. It turns out that, contrary to expert opinion, the SSH technique of simply raising an alarm whenever a key changes is in fact one of the best ways to prevent man-in-the-middle attacks. In order to perform a man-in-the-middle attack against SSH, where any new key will raise an alarm, you need to have an "always on" network presence to react to all new connections as they are made, and even the best network engineering that money can buy is not capable of providing 100% network reliability, even in a friendly (non-adversarial) context. On top of all that, technology has evolved to the point where most people today (in developed nations, anyway) have multiple lines of access to the internet: work, home, wifi, smartphone, and so on. Once you give someone two different views of the internet, caching and comparing keys really is the best way to prevent man-in-the-middle attacks, and it's certainly a lot better than blindly trusting a central authority, or introducing the complexities of a web of trust. 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.
(Log in to post comments)
Trust, but verify Posted Feb 21, 2010 21:07 UTC (Sun) by cassee (subscriber, #5336) [Link]
> SSH, however, has never been attacked cryptographically via its trust model [...]
Actually, it has. There was a neat trick way back when SSH servers still accepted both protocol 1 and 2. A man-in-the-middle could force a change in protocol by changing the packets so that it was probable that the host key would not be in the client's known_hosts file. The user would receive a relatively benign 'The authenticity of host X can't be established' message instead of the hostile 'WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!'. It would be easy for an inattentive user to ignore the warning and accept the compromised connection.
More details (although with awkward text flow) at: http://hubpages.com/hub/sshprotocol
Trust, but verify Posted Feb 22, 2010 15:19 UTC (Mon) by micah (subscriber, #20908) [Link]
(disclosure: i contribute to the monkeysphere project)
djao said:
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:
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.
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 bandA 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
|
|||||||||||||