Duane wrote:
yes it does. If you can't trust you've made a connection to the site you thought you made a connection to, you have no security. Saying you do is like saying "I'm secure because I have an RF shielded cable running from my computer".Nelson B wrote:
and that the user will have NO security thereafter, and should turn off the lock to make the point.
But that's just as misleading, just because the certificate isn't in the browser doesn't mean there is no end to end security, this isn't something that can easily be shown as either on or off, I disagree with the whole binary security thing, security isn't binary, it's a whole bunch of grey...
<begin SOAPBOX>
There is a growing myth at you can get most of the security you want by using unauthenticated encrypted pipes. This myth has been enhanced by such systems as SSH, PGP, and use of self-signed certs. These tools -- when used properly -- can be secure. It requires a diligent, knowledgeable operator, who painstakenly checks all fingerprints of all the keys he trusts in the system. These tools depend on an already existing *human* relationship between the people communicating. The problems come because the operator verification burden is too high. Most of us --- even those of us who know better --- simply rely on the fact that we trust our underlying intra- or inter- net infrastructure and click 'accept' when asked to do the check.
Now add there scores of intelligent programmers and admins, who understand enough to start these products, but aren't familiar with applied cryptography and their protocols. Suddenly everyone thinks "look it's encrypted, so it's safe", without understanding the underlying attacks.... and they get away with it because,for the most part, our unencrypted connections are secure actually enough. They clammer for us to remove the warning dialogs and 'just let me get on with it...' because they've never been bitten before. We are already at risk and are only talking the most intelligent 5-10% of the population.
The issue is for most of our operations, the risk isn't that we are going to loose our sensitive information to some internet snooper.
SSH doesn't prevent any more practical attacks against my system than Telnet does (unless I only turn on client auth). There are very few scenarios where snooping is feasible, but redirection of the packets isn't. If we aren't protecting against the redirect attack, we aren't supplying enough extra security to warrant telling the user he's 'secure'.
<end SOAPBOX>
One more 'myth' that has been around for a long time is "little bits of security is better than no security". This is only true if you understand the magnitude of "the little bits". I've heard developers say obscuring the password is better than nothing at all, but that's like saying "putting a fake lock on a gate is better than just a latch" where the user isn't told the lock is fake. It's true the novice thief may pass up the gate because it is too much work to get through, but even a casual thief would recognize the lock as fake and break in. If the user had known the lock was fake, he may not have secured his valuables behind it.
In short, providing the connection without accepting it as secure is, IMHO, an excellent way to solve the problem and start breaking down the myth.
bob
smime.p7s
Description: S/MIME Cryptographic Signature
