The authenticity of host 'delicious.cake.net (110.120.130.140)' can't be established.
RSA key fingerprint is 18:93:ea:38:81:84:ae:34:b4:56:0e:51:7c:28:ef:cd.
Are you sure you want to continue connecting (yes/no)?
How about a few bets? So many stupid things are said about security, more often than not by drastically overestimating importance of security measures to people... Should we try prediction markets instead? I haven't heard about any research on prediction markets with thought-experiment money, but they do work with both real and play money, so I'm accepting your though-experiment bets!
First, let's find a random ssh user trying to access delicious.cake.net or some other server. I bet they're not going to check the ssh key fingerprint. Instead, they'll just blindly type yes without thinking. What rates do you take?
A second bet. Let's find someone who did not bother to check the ssh key fingerprint. I bet they're not under any kind of man in the middle attack, and everything will be perfectly fine. What are your rates here?
And one more. Assume someone is under man in the middle attack. I bet they would be owned by some other channel anyway, and so ssh key fingerprint check wouldn't help them at all.
My initial guesses as for the rates are 100:1, 10000:1, 10:1. I bet 9000 internets on each one of the possibilities. Yes, I know this is ridiculous, but go on and offer counter-bets if you think I'm wrong.
Why the magical thinking?
So assuming I'm right, and the ssh key fingerprint check is useless, why don't we turn it off, or at least provide an option of doing so? This silly question is asked even with EC2 instances, where the instance key is randomly generated, so it's impossible for you to know it; and the instance already has your public key, so hopefully man in the middle attack shouldn't be possible (unless ssh works in some perverted way where that's not enough).I bet the process goes something like this - ssh developers realized that man in the middle attack is possible. So what were their options? First, they could bother with the public key infrastructure of some sort, but seriously, that would be too much work, both for them and for admins. Second, they could just accept the possibility of man in the middle on the first connection. Both options make sense.
But no - instead they did some magical thinking, and added a completely useless security ritual, a bit of security fairy dust that magically "makes things secure" even though in reality it does nothing other than annoying the user.
It's not ssh's fault really - we're all trapped between irrational belief in importance of security, and reality of most kinds of attacks never happening due to high cost and low benefit to attackers in absence of economies of scale. So instead of reevaluating our beliefs we implement useless security rituals like that. And they work! After all, I don't see any ssh man in the middle around, do you?
3 comments:
> why don't we turn it off, or at least provide an option of doing so?
from `man ssh_config`: (empahsis mine)
StrictHostKeyChecking
If this flag is set to ``yes'', ssh(1) will never automatically
add host keys to the ~/.ssh/known_hosts file, and refuses to connect to hosts whose host key has changed. This provides maximum protection against trojan horse attacks, though it can be annoying when the /etc/ssh/ssh_known_hosts file is poorly maintained or when connections to new hosts are frequently made. This option forces the user to manually add all new hosts. If this flag is set to ``no'', ssh will automatically add new host keys to the user known hosts files. If this flag is set to ``ask'', new host keys will be added to the user known host files only after the user has confirmed that is what they really want to do, and ssh will refuse to connect to hosts whose host key has changed. The host keys of known hosts will be verified automatically in all cases. The argument must be ``yes'', ``no'', or ``ask''. The default is ``ask''.
What I think it needs is another option between ask and no. If the host is unknown, act as 'no' and add it to the known_hosts file. If the host is listed in known_hosts, refuse to connect if the key is incorrect (part b of 'ask').
My estimates are 1 million:1, 1 billion:1 & & 1.05:1.
As much as it's fun to rail on security theater, I think the ultimate cause stems from what I call the No Evil Geniuses paradox: http://blog.bumblebeelabs.com/nov-12th-day-30-no-evil-geniuses/
In short, we focus on protecting against attackers who are just like us, except evil without really looking at what actual attacks on the system would look like.
Post a Comment