Recent posts about security protocols like SSL and DNSSEC got me thinking. In an orthogonal direction.
You know what's wrong with protocols like SSL, SSH and PGP/GPG? They let users pick the stupid. Bruce Schneier has trained me to call this the "dancing pigs" problem, though I'm too lazy to go look up the guy Bruce says he got it from.
It goes like this: "There's a problem with the security gizmo; click OK to see the dancing pigs."
Unless you're a security researcher who lives for the chance to investigate a malicious server, you just click OK to see the dancing pigs.
All my kids have been computer users since before they could read. They don't know what the dialog says, but they learn to click OK to see the dancing pigs. Even when they do learn how to read, they aren't necessarily so concerned with expired certificates or DNS name mismatches.
The reason these protocols all suck is because they let just anybody make the security policy decisions. Stupid.
(OK, so it's not the protocols/file formats themselves, just every app that implements them.)
So, what am I suggesting instead?
Dan Kaminsky wrote an excellent chapter on spoofing for me, for the first edition of Hack Proofing your Network. I hope to have it available for download one of these days. In it, he makes a perfect case for reliability == security. If your service is going down all the time, then you are being trained to live with unreliability and ignore strange problems. Your judgment is shot.
So much for the idea that a DoS isn't a security problem.
As a QA guy, I really want bugs to crash, and crash hard. Crash dump or core file too, please. The alternative is random behavior, unreproducible issues, caught exceptions that I really needed to know about, and maybe memory scribbling that could exhibit random symptoms. You don't want it to be kinda tolerable, not that big of a deal, I haven't seen it in a while I guess it's gone kind of a problem.
So security protocols need to break and break hard.
If there's a problem with the certificate, then just drop the connection. Don't prompt the user. Don't try to rate how bad of a problem it is. Don't toss a yield sign in the corner, don't show me a key with fewer teeth. Just stop.
If the SSH server keys have changed, don't connect. Don't offer to connect anyway. Don't ask if I want to save over my keys. Don't tell me the command-line switch to disable my security.
If the GPG email signature doesn't verify, don't let me read it anyway. Don't invite me to keep searching keyservers until I happen to find one with keys that agree.
Why? Because if it breaks properly, people will be forced to get someone competent to fix it. And they will HAVE to fix it.
Examples. If someone's SSL cert expires, right now they can sort of ignore it for a little while, or tell people to click OK, and so on. Do it my way, and it breaks entirely, and the person who should have renewed the cert does so, right now. Don't get me started on self-signed certs. If you've done something and blown away your server SSH keys, you think no big deal, just tell everyone to accept the new ones. Do this enough, and what have you trained users to do? If instead SSH doesn't work at all, how much more careful would you be about bothering to restore the original SSH keys?
But this is painful for people? That's the point. People learn through pain. Some things should be punished. Some events should be disruptive.
People should be trained to take security seriously.
skip to main |
skip to sidebar
Followers
Full RSS FeedContributors
Labels
- books (5)
- cloudbaiting (1)
- egoblogging (22)
- IT (1)
- locks (1)
- malware (3)
- OS X sucks (7)
- pneumopunk (2)
- RE (6)
- review (1)
- secphil (30)
- security (9)
- spare brain (5)
- stories (10)
- v12n (2)
- work (6)
6 comments:
There's a large class of web applications that people use --- particularly in enterprises --- where we don't expect the server to give us a cert signed by Verisign, and we don't care. As long as we have key continuity, we're comfortably accounting for our threat model.
So, why would I want those applications to explode just because I didn't fork over some money to Verisign?
And how often do you "click through" the scary SSH warning? Swear to god, I strings my SSH binary every time I get it. =)
Thomas,
I don't care if you use self-signed certs for programs. Programs are too stupid to be fooled; if keys don't match, they bail, right? That's what I want. Humans are smart enough to pick the stupid choice.
You don't have to use Verisign, but I am saying you have to pay one of the vendors that comes preinstalled with IE. That's the ONLY way this works to keep your mom from getting MITM'd. It's part of the certificate chain/CA design. You depend on the barrier(s) for getting a cert, including cost.
Of course, if you make your browser break hard like I suggest, which means there's a competent IT person involved somewhere, then that person can also pre-install the local company CA cert. This takes care of probably the only special case you want to have.
Believe it or not, at one point the SecurityFocus IT people that replaced me did something to change the server SSH key on the machine we all read our mail on. I went to connect one morning, and was told the keys were different. I believe I actually picked up the phone.. and was told to accept the new keys, yes they overwritten the old ones. They had mailed us... but you couldn't get to the mail until after that step.
And I'm sure that I've done the same thing myself, caused server keys to change. I don't want to act like I'm perfect.
But my point is that if this broke a little harder, then it would be a bigger deal when people did that, and (I hope) would cause people to do that less.
The SSH key replacement thing is harmless when it's just you and your own boxes, and you know every single time when the keys have been legitimately replaced. Doesn't scale to >1 person, though.
And you know, I guess I also click through the (slightly different) warning every time I connect from a new client. So maybe I'm being mis-trained there, too. Maybe it deserves a full cert setup.
Hello Ryan,
I agree, you're right. It would be better for security if the protocol crashed hard.
However, it's not good for the application vendor when there's competition that provides a workaround. For example, we have an SSH client and server for Windows, Tunnelier and WinSSHD. If we change Tunnelier so that it won't allow a connection unless the host key of the server is pre-installed on the client, the user will have an incentive to switch to some other client because ours is "too difficult to use".
So we do the next best thing - we provide a stern dialog with bold text telling the user to verify the fingerprint - which is what an SSH user expects and which is what most SSH clients do.
Similarly for SSL, if Firefox were to make it impossible to connect to servers with invalid certificates, people would have a reason to switch to IE. And so on.
The problem is that strict behavior is not an equilibrium. As soon as one application breaks the strictness, other applications have to break it as well, or be perceived as harsh, and difficult to use.
Strictness might work if there was consensus that it is the right thing, and if vendors would experience some repercussions, such as hearing it from a standardization body or someone if their product doesn't adhere to the strictness that was agreed on by a practical consensus.
Only then would there be an equilibrium in implementing strictness. And I agree, it might then be a good thing.
Denis,
An interesting perspective, thank you. I've specifically taken issue with protocols that (I think) were born with a dancing pigs option. The first time I ever used SSL with probably Netscape 1.something, it had all these exceptions, including the 40-bit export rule silliness. The first time I used SSH (and I would have been late to the game on that) it did the complain/connect anyway.
So from my perspective, the bar started low, and stayed there. Actually, maybe with some minor improvements (see: 40-bit silliness.)
I hadn't thought much about the case of starting high, and vendors trying to out-stupid each-other, as a sales tactic.
To be clear, no, I don't think you can get away with fixing SSH now. I assume it would have had to start that way.
But I think you may have a point to consider. I think I've made similar arguments myself when discussing Windows vs. Linux security. The standard for Windows (Mac, too) MUAs is to double-click to launch the attachment. The Linux party indicated that Linux MUAs didn't do that. I think that the Linux MUA that did launch attachments would be extra popular with everyone's mom, if they suddenly found themselves running Linux.
D'you suppose the "dancing pigs" options started appearing around the same time as http (that is, when the World Discovered the Internet, and people like my mom could start using a computer)?
The Web was when you got the exponential growth curve for the number of users of the Internet. I think that's also when you start to get users that aren't self-identified "computer people". Not that all computer people are security savvy, but the barriers to entry mean a certain amount of competence.
I could be wrong, but I also don't recall all that much crypto in use back then, beyond your cipherpunks population. I think the browser might have been the first app normal people had that could be expected to do crypto occasionally. Or ask about other security options on a regular basis, for that matter.
So yes, I think the Web was the event and cause that led to attempting to put decisions in the hands of people not equipped to make them.
Couple that with a big enough population and motives for the attackers to come, and you've got a problem.
Post a Comment