Slashdot Mirror
Attacks Against SSH 1 And SSL
AndyR writes: "SecurityPortal has a very interesting article by Kurt Seifried in which he writes "dsniff 2.3 allows you to exploit several fundamental flaws in two extremely popular encryption protocols, SSL and SSH." He makes many very strong arguments about key validity and the problem with not having a trusted third party signing keys." Don't throw away SSH just yet, it's still a lot better than nothing.
yawn. I have seen windows machines that have no open ports run arbitary code. There is something wrong with their TCP/IP stack. It's sad but true. Unfortunately you have to take my word for it and you never would so you will continue to run a toy operating system.
How we know is more important than what we know.
I consider myself somewhat knowledgable about cryptography in general and SSL in particular. I read the articles by Kurt Seifried, especially the "foundation" articles dates Sep 30, 1999 and Oct 7, 1999. He is very cagey about actually demonstrating an attack, but I think his points are either technically wrong or technically useless.
First, the technically useless. Every security product/protocol I am aware of is vulnerable to so-called social engineering attacks. That's their whole point! They go around the security perimeter and get "behind" the protection to get humans to give away information. It is certianly fair to analyze the ease to which some products/protocols facilitate this, but I didn't see much of that. Instead, the articles discuss a company called DigitalBond with a solution that perhaps is also vulnerable to social engineering attacks.
Now lets look at the technical attacks and claims, which are contained in the Sep 30th article. I'll only comment on the weaknesses he alleges are in SSL. His first claim is that you should not order from a store that uses the http GET method. He doesn't say why, and I cannot think of any reason. If the form is submitted with an SSL-secured action (action="https:...") then both are equally secure.
His next claim is that the user must inspect the certificate of the server every for every SSL connection. He does not say what attack he can mount if the user doesn't do this. I am guessing that he believes the man-in-the-middle can substitute his own certificates and appear to be legitimate. This is firstly not an attack on the SSL protocol, only perhaps on implementations, and secondly it does not work with the implentations I have tested, IE 5+ and Netscape 4.7+. These implementations verify that the hostname you asked the browser to connect to matches the hostname specified in the CN field of the certificate. Of course, you must trust that the CA will do some checking to make sure hostnames actualy belong to the entity getting the certificate, but that is way outside the scope of the SSL protocol. These "flaws" cannot be the basis for later claims of insecurities. These implementations do not rely entirely on having savvy users carefully inspect every certificate.
I'd like to check up on earlier broswer versions to see if they also behave similarly. I'd be particularly interested in browsers that were in play at the time the article was written, say fall of 1999.
--greg
I always do electrical work with the power on. Of course, I turn the power off first. And then I work as if I still had the power on. Cuz ya never know, it might be on.
-russ
Don't piss off The Angry Economist
http://www.fs.net
this is not a problem in ssh.
/etc/ssh/ssh_host_key
this is not a problem in ssl.
It is a very old, very well known attack approach, which both already guard against (that's what the 'host key changed' message is all about in ssh). If you see that message and haven't been notified (and sent a new key fingerprint to veryfy against by the admins), you *MUST* assume that a man-in-the-middle attack is being employed - it's what the message means!
Someone in the middle of your connection pretends to be the server to you, and pretends to be the client to your server. Poof, two valid connections, he forwards your data (he has it in plaintext, as he is your server), and you notice only one thing to tell you that something is amiss - that he *did't* know the right server key (ssh has caches it from previous connections to that server's IP, ssl can check the CA's notes about whose key it is) and had to send you a different one.
So your client warns you that the key has been changed. You need to get the key fingerprint from the server admin (out-of-band, not over the same potentially compromised network) and compare it to the one you recieved (you did do that when you first connected to the machine too, right? it should have come along with your account credentials, if not you needed to ask for it if you cared a bit about security) and make sure it matches the new print the server is offering.
to get a fingerprint for a host, use ssh-keygen -l -f
SSL is in a similar situation - the key bears the DNS name if the site it is for, and your browser will warn you if it recieves a key for the wrong site, or not signed by a recognized CA. You didn't turn those off did you? If not, then one or the other will come up when confronted with a man-in-the-middle attack (either he'll send a properly signed key, but not for the right site, or he'll have a forged and unsigned key for the site you were really going to) and you'll know what you're facing.
for ssl, if in doubt, click the little padlock in your browser, and read the key - see that it's for the site you think it is, and signed by a recognized CA.
If you don't use these tools correctly, you may as well not use them at all. Everything is in place to detect these attacks (which are not new), but if people simply ignore warning messages that indicate the presence of known attacks, there's not much else that can be done
The Matrix is going down for reboot now! Stopping reality: OK. The system is halted.
I disagree, the strength of your locks reflect your assessment of risk. If sufficiently valuable in the real world, locks are replaced with security guards and automatic rifles. Most people don't have anything that valuable, and find it more cost effective to place limits on their credit cards, check up on protection from their credit card companies and take up insurance policies.
If there were no banks and no insurance policies, would you, with your life savings under your mattress, still say that your locks are to keep honest people honest?
Besides, this SSH and SSL attack is very well documented, known and understood for a long time to be a limitation of the system. If your life savings are on the line, use callback, challenge response, or don't use remote logins at all.
These vunrubilities have always existed. It comes from the fact that SSH is not signed by a certificate authority, and as such you cannot trust the server on the other end. If someone cracks DNS etc to direct you to another server, you won't know about it, except for a warning that the key is different from last time.
SSL is similar, but it is signed on the server side, usually not on the client.
This isn't anything new, it's just not there are publically available tools to exploit this.
--
enterfornone - logging in for a change
Well then, you'd lose your wager. OpenSSL has cert handling OK, but the SSH protocol can't use certificates directly
I did patch OpenSSH (version 1) a while ago so that it can use certificates if they are available via local files or an LDAP server, and am currently trying to get OpenSSH2 similarly able.
So there's hope yet
Only the ssh.com implementation.
OpenSSH supports SSH2 for free (beer and speech).
"don't fall into the fallacy of believing that Perl can solve social problems. Maybe Perl 6 can, but that's a ways off"
Some notes to slashdotters:
The article is long, why? Because I had to explain what SSL and SSH are, most people do not know how public key crypto/etc works. If I do not explain this trying to explain the security problems and why it's an issue would be pointless.
Before it was hard to attack SSL/SSH connections and do man in the middle. You'd have to write your own software or find some, which as a rule wasn't publically available (you could see it demo'ed at security conferences/etc but I don't remember anyone ever putting it up for anon ftp or on the web). Well now it is trivally easy to find, and the entry level for attacks just got a lot lower. Users should be aware of this.
Unfortunately I can't offer any really good solutions (go get software package foo and everything will be better). For now dsniff only does SSH1 attacks, so going to SSH2 should help (until somone modifies dsniff, as I point out in the article). How can you verify SSH keys, print out lists of key signatures and tape them to every workstation and teach users to verify them? Not likely. Ditto for SSL, how many of you actually look at the certs servers hand to you, and how many of you have clicked on OK or Continue when the cert is out of date or issued by a non trusted entity (i.e. a self signed cert).
Been there, done that (this week). All the systems where I've changed out the sshd still have the same key. The key itself is stored in a separate file and isn't going to be affected by changing the binaries.
I just got through a few of those this week as well, and the systems still have the same key. Again, the key file is not part of the OS, and as such it isn't affected.
Okay, I haven't seen this one for a while, but I've still gone through it and had the key come through intact. IIRC, the most extreme case was switching a system from running on a sun4c machine to running on a macppc box. I moved the harddrive over, booted from CD, and installed the new binaries from there. When I rebooted from the harddrive, the machine came up with the same key.
The only case I've seen where the key changed was when a machine that wasn't important enough to back-up went down and was replaced with an entirely new machine. The only thing the new box had in common with the old one was the hostname.
Basically, you should only see key changes in extreme circumstances like that, and in the less extreme case of a CNAME changing to point to a different box, you would hope for some warning, too.
T. M. Pederson
"...and so the moral of the story is: Always Make Backups."
T. M. Pederson
"Lies, Damn Lies, and Documentation"
it is never the users. It is the policies of the network. If you don't run an ftp server, and a telnet server then you can't have people using unencrypted protocols. But people insist on running these protocols. Ok, so maybe it is the users now and then, like postit notes on the computer.
How we know is more important than what we know.
There is also a project underway to allow OpenSSH to use keys distributed by DNSSEC.
This attack then comes back to user apathy (i.e not bothering to verify key fingerprints). An alternative (not yet implemented) is some form of PKI, which has its own problems (complexity, centralised trust, revocation issues).
For administering a private network, SSH and SSL
:-).
are perfectly secure. You can surely trust keys certificates that you generate yourself. As most of the dsniff tools rely on being on the same segment of ethernet, with careful key management they're not really a threat. Ever tried changing a ssh host key and then sshing into it ? You get the largest, scariest warning that makes you feel totally paranoid.
Also, if you are connecting to a server for the first time - fingerprints allow you to check the validity of the keys.
The problem is with connections to machines you can't personally validate, where DNS spoofing could be used, for example with e-commerce sites. But this is what CAs are for. So where's the problem (until a CA gets cracked that is
because windoze boxen are inheritently insecure. Just read my tag line, I bet you get at least three "cute" flash games and the like every month. Even if you don't, I'm sure you don't have the Outlook security patch installed (the one that makes it impossible to open exe's and vbs scripts and the other 100 - yes there's a list - file formats that are infectable). Patching binaries on windoze is trivial. Intercepting keypresses on windoze is trivial.
How we know is more important than what we know.
This is definitely FUD. The SSH documentation deals specifically with this issue. This is a good thing and SSH's handling of the situation is more secure than a central signing authority.
What he's basically advocating is removing the need for people to have secure methods for exchanging keys. Instead of having the chance of a "man-in-the-middle" attack during the first connection (which, if you've exchanged the fingerprint of the server with the admin of the server involved, is eliminated), he'd rather that we trust some other person with our security.
What if:
If any of these happen then your security is FUBAR. Bear in mind that the key could potentially be used to attack e-commerce sites, and is therefore pretty valuable. If the secret of the key being leaked is kept well enough, it is quite possible that no-one will ever find out - except for the odd sum of money missing from random credit cards worldwide.
Compare that to SSH, where upon connecting to the server, you are notified that you are connecting to an unknown host key, and it gives you its fingerprint to check against what you have recorded it should be. If the key ever changes, you are presented with a huge warning message saying that the host key has changed, and that a man in the middle attack may be in progress.
If you were using this commercially, you generally would be using SSH between two machines that you admin yourself, or between one that you admin and one that your peer's company admins, and you can verify the keys, set them up in each systems ssh_known_hosts file, and rest secure that you are not vulnerable to man-in-the-middle attacks.
Personally, I think he's trying to promote the idea that "security needs trusted arbitraries" to the corporate IT world - I wonder if Kurt Seifried has received any "donations" from any large key authorities recently?
Let's face it - if people use security that doesn't need key authorities, then they'll go away.
Every security system that uses a trusted authority is vulnerable to a purchase-key attack, and don't let anyone convince you otherwise!
If the guide is not respected, or the material not cared for, confusion will result, no matter how clever one is.
This usually happens when a new version of the OS is installed on a given server, and the sysadmin is careless about not moving the contents of the SSH host key to the new server.
There are some protections against this attack. When the host key is changed, ssh for Unix gives you a warning that you would have to be blind to miss. If you want better protection than that, the best solution is to hack OpenSSH or what not to only accept a key with a given key fingerprint for a given IP. In other words, if the host key is changed, the hacked client will not connect to the host in question.
- Sam
The secret to enjoying Slashdot is to realize that it should not be taken too seriously.
Interesting thought. I was just thinking whether we should be more secure if we used public keys as 'net addresses, so that the address and the authentication are coupled together (I know, I know, this is puuure fiction). Sending data to one address then ensures no-one is tapping that line.
In your scheme, the following might occur:
- client: hey router, pass this package on to the server, will ya?
- evil router: OK (looks inside the package, finds a key request. Starts producing a fake key) Hey client, I just got this package from server. Any idea what's in it? Open it, quick!
- client: none of your biz! (turns side to router and opens package) Aah, finally, the keys from server! (encodes a package o'data) Hey router, pass this package on to the server, will'ya?
- evil router: Well, OK.
This would for instance mean that your ISP can still check out on you if you use SSH and if they desperately want to do so (government!).
It's... It's...
"We can confirm that Debian does *not* ship the version with the trojan horse. Our version predates it." [CA-2002-28]
"And there comes a point where too much security slows down the system. Hey, yeah, we could go to 4096-bit encryption, but what's the point? "
;)
.|` Clouds cross the black moonlight,
Go? I'm already there for the more secure stuff...
It all boils down to the concept of an `identity'. There is the identity that pays my enormous phone bills, one that writes this here and now, one that drives the car, another one that exists on my driving license, and a few GPG/PGP identities as well. Tying them all together into one is possible, but legally necessary. I think that's where the problem lies.
~Tim
--
~Tim
--
Rushing on down to the circle of the turn
Bob : 245.345.0.20
Alice : 245.345.0.40
Charlie: 245.345.0.50
Now Alice wants on Bob's machine so he (Bob) opens up the firewall to allow Alice to access his server (don't forget; SSH isn't about encrypting and decrypting email, its a real time connection. And hey; if you need security and therefor use SSH but no firewall I think you're missing the point). Their keys get intercepted by Charlie. Charlie tries to access Bobs machine but is rejected by his firewall. Now what?
One of the main things that secure protocols are designed to stop is that man-in-the-middle attack.
The basic idea is to exchange session keys and verification data before a random public key. That way, the attacker can't substitute other public keys, because the attacker would have to be able to generate data based on information which has not yet been sent.
The article isn't actually talking about the described attack at all, but about spoofing servers. Identification of servers is a substantially different problem, and is a human-engineering one rather than a protocol one: what makes a server the one you are trying to connect to?
The attack is where the attacker wants to convince you that you're talking to the server you think you are by having you actually talk to that server, except that you are not talking directly. Most encrypted protocols do a good job of insuring that you are connected directly, over an encrypted channel to whatever it is you seem to be talking to. Whether the server you're talking directly to is the one you want to talk to is up to the user and other parts of the system.
SSH is as secure as you make it. If you validate server keys rigorously, MIM attacks are impossible. If you regenerate your keys frequently, it's even less likely that you will be compromised. Until quantum-based encryption becomes reality, the 'perfect' security system is just theory. Until then, SSH is certainly good enough for me.
TCP/IP and UDP provide no built-in encryption or authentication, and it will be a very long time before there is widespread use of IPSec.
IPSec isn't a solution either. Well, Bruce Schneier certainly doesn't think so, anyway. Check out this at Counterpane.
Sample quote:
We strongly discourage the use of IPsec in its current form for protection of any kind of valuable information, and hope that future iterations of the design will be improved. However, we even more strongly discourage any current alternatives, and recommend IPsec when the alternative is an insecure network. Such are the realities of the world.
If you want better protection than that, the best solution is to hack OpenSSH or what not to only accept a key with a given key fingerprint for a given IP. In other words, if the host key is changed, the hacked client will not connect to the host in question. In OpenSSH the directive StrictHostKeyChecking does exactly this, provided the IP in question is in your known_hosts file.
Ha! I kill me!
I find the quest for the holy grail of perfect encryption/perfect protocol rather odd.
Why do we put locks on doors? To stop people walking in an stealing our stuff, So lets lock the windows, fair enough better security, people are less likely to break in that good. Fit an alarm?
So why not fit better locks? etc etc every upgrade costs money, and as it gets more expensive I get less return on my money. However this is completely ignoring one factor, insurance!
My SSL connection to buy a porn flick via my credit card... Hmm, how much do I care about it being broken.. well a thief just wants my number, my gf might be interested in my buying porn.
My GF does not have the skills to break the encryption, so SSL is secure. A thief, well so long as the Credit Card company pays up if someone else uses it I really don't care.
A tool should be fit for the job, SSL with real world insurance is seccure for credit cards, the day they don;t pay out, SSL falls!
James
Since neither SSH or SSL use signed certificates on both ends they are potentially open to attack.
I'll put my hand up in the air and admit I don't know much about SSH -- but SSL most certainly supports signed certificates on both ends: it's up to the server whether it requires a valid client certificate, up to the client whether it requires a valid server certificate. Try adding 'SSLVerifyClient require' to your Apache/Mod_SSL directory stanzas sometime.
Just because many deployed SSL applications choose not to use client certification (presumably because of the hassle for users of obtaining a client certificate) does not mean the protocol doesn't support it.
Actually I'll wager OpenSSH is able to require client certificates, since it is built on OpenSSL.
--
What this guy needs is a "freshman shooters course". Every FAQ, HOWTO, Guide for Lamers states that the most dangerous process is the key exchange. If you don't trust the channel don't exchange keys. JUST DON'T DO IT!!! Grab a disquette, write the key, pick an envelope and send it to Alice's Aunt in the name of your dog. That's if you and Alice are thousands of kilometers apart and you are damn paranoid. On smaller distances it is much simpler. On local networks it should not be a great problem. Depends on the sysadmin and your colleagues but hey, Alice is a desk away... If you are a sysadmin it SHOULDN'T be a problem. If this doesn't happen then what are you administering?
That's the main problem. Key trnasfer. And this is the same problem as transferring and storing cypher books, passwords and many other things. In the rest SSH has shown that problems drop several orders of magnitude.
Now a problem. Why do I need a third party here? I need thrid parties only for a very specific set of problems. I can come to Alice and drop the key in her computer. Now in cases of extreme paranoidism I may ask a third party to do that job for me. For example, I know that Alice's Uncle is really angered for kicking his car. And I still remember what he said about me and Alice with that old rifle in my nose. But I do trust that Alice's Aunt will deliver her my diskette...
Other case is chenging info with a party I do know too much. For example a commercial transaction with some e-shop. We may use a third party we trust to process our transactions.
However, in these two cases we have a problem. We should trust the third parties. And the level of trust depends on how good I know them, if the channel between me and them is secure and what do I need them for. Interknowledge is something quite relative. We see many third parties in e-commerce and even don't know a thing about them. It does not matter too much if we just wanna buy a computer and we don't want our credit/debit card numbers being stollen. The problem of the channel gets up to the same level as Alice's problem. What if someone intercepts this "certificates" and keys? In the end, the need. Do I need them for e-commerce? Sure. For my local network. No thanks! Wanna come? Cool, where's the AK-47? It's our private property and no one has a damn to do here. I can myself run over the workstations and exchange the keys...
Besides there is a problem of centralization. Certifications are a form of centralization. What may happen when huge corps, states, mobs, large and small nets, individuals and computers will be tighten to such a thing? Forcing certifications over everything is the biggest error possible. That will break exactly the fundament of public key encryption, that each individual has the possibility to set its own key for private exchange of information. Such move will be the revival of such things like CLIPPER...
I would rather get fired than have management dictate security issues to me. Thankfully I've never run into that kind of pigheadedness. If the geek says it aint safe, it aint safe.
How we know is more important than what we know.
I don't think twice about giving my credit card to a waiter at a restraunt, although its rather easy for the waiter to use the information to charge false expenses to my account (and it has happened to other people before). Its nice to have security holes pointed out, but really, locks are to keep honest people honest, any transaction is potentially insecure, and it pays to double check any financial records you receive to find any false charges or transactions. I don't fear this hole, statistically speaking, I suspect real life is a lot riskier.
"In the end nothing is 100% secure... "
.|` Clouds cross the black moonlight,
Of course. I knew that.
But the article doesn't say anything new at all. I've long-since known about the possibility of interception, and when it comes to signed documents, the presence of a digital signature on a document, even one that matches someone else's signature, does not mean that that person wrote that document. (It means there exists at least one person out there who knows the private key password for that identity and/or chose to apply it to the document; if you go around signing things you didn't even write yourself willy-nilly, the whole concept loses any strength it had.)
Again, this is a luser-space problem. There is no security vulnerability in ssh that's been discovered, this is an "if you abuse it you'll lose it" article. Well woopie-doo.
~Tim
--
~Tim
--
Rushing on down to the circle of the turn
And I forgot to carry on ranting... ;)
.|` Clouds cross the black moonlight,
You should always double-check identity for yourself instead of taking someone's word for it. Anyone can ask Thawte or Verisign for a certificate; the money does not by security of identity for later transactions, unless you're a very gullible PHB, basically.
Oops, there goes "e-commerce", oh well.
This applies even more so to SSH, where you really must check the server's fingerprint before connecting. If that means phoning up the sysadmin remotely to confirm it, go ahead.
~Tim
--
~Tim
--
Rushing on down to the circle of the turn
If you don't run an ftp server, and a telnet server then you can't have people using unencrypted protocols. But people insist on running these protocols.
/etc/inetd.conf, then either reboot or kill -1 [pid] where [pid] is the process id of the inetd daemon).
Sometimes it is the users, particularly those users with authority over you (like the ones who sign your paycheck). If they demand a service despite your protestations that the service in question compromises security, you are left with little choice but to provide the service knowing full well that it creates a security hole in your network, or look for a new job. In this case it is the user's fault, not the administrator's whose advice is being ignored or overridden.
That being said, you make an excellent point. The first thing anyone should do when building a new system is install ssh (including sshd) and disable telnet and ftp (on Linux/Unix: comment out the two entries in
As we've seen in this article, running ssh isn't a panacea, but it is a hell of a lot better than using no encryption at all
The Future of Human Evolution: Autonomy
If each administrative domain could maintain its own key-signing/authentication service, then at least enterprises, ISPs, and the like could provide solid security between their own systems. Contact between such entities could be preceeded by "out-of-band" authentication or exchange of keys (e.g. something like a PGP key signing party, a phone call, or an exchange of keys signed by a trusted third party).
The flexibility of the current approach could be maintained, with added levels of trust ranging from completely secure to completely open to "man-in-the-middle" attack.
There is still the possibility of abuse, however, as the "trusted third party" (particularly in the case of ISPs) could easilly be subverted by a law enforcement or spook agency into signing counterfeit keys. Indeed, they could legally be required to do so with legislation akin to the wiretapping laws requiring phone companies to provide technical facilities that facilitate evesdropping by law enforcement on demand.
The Future of Human Evolution: Autonomy
The interlock protocol, invented by ron rivest and adi shamir, has a good chance of foiling the man-in-the-middle attack. Here's how it works:
- Alice sends bob her public key.
- Bob sends alice his public key.
- Alice encryptions her message using bob's public key. She sends half of the encrypted message to bob.
- Bob encrypts his message using alice's public key. He sends half of the encrypted message to alice.
- Alice sends the other half of her encrypted message to bob.
- Bob puts the two halves of alice's message together and decrypts it with his private key. Bob sends the other half of his encrypted message to alice.
- Alice puts the two halves of bob's message together and decrypts it with her private key.
The improtant point is that half of the message is useless without the other half; it can't be decrypted. Bob cannot read any part of alice's message until step 6; Alice cannot read any part of bob's message until step 7. There are a number of ways to do this:- If the encryption algorithm is a block algorithm, half of each block (e.g., every other bit) could be sent in each half message.
- Decryption of the message could be dependent on an initialisation vector, which could be sent with the second half of the message.
- The first half of the message could be a one-way hash function of the encrypted message and the encrypted message itself could be the second half.
To see how this causes a problem for Mallory, let's review his attempt to subvert the protocol. He can still substitute his own public keys for alice's and bob's in steps 1 and 2. But now, when he intercepts half of alice's message in step 3, he cannot decrypt it with his private key and re-encrypt it with bob's public key. he must invent a totally new message and send half of it to bob. When he intercepts half of bob's message to alice in step 4, he has the same problem.Has anyone tested dsniff 2.3 against the Stanford SRP? SRP has several different aspects from SSH, and is advocated by many as a more secure alternative to SSH. It wraps legacy applications like telnet and ftp around an encrypted package. Also, I would be curious from anyone who uses SRP to see if dsniff can be modified to exploit SRP. Thanks!
wow, an on topic FP.
Basically as long as you are 100% sure who you are talking to on the other end your connection will be secure.
The problem comes from there being no way to be 100% sure who is on the other end without signed certificates on both ends. Since neither SSH or SSL use signed certificates on both ends they are potentially open to attack.
--
enterfornone - logging in for a change
True.
"On the Internet, no one knows you're a dog."
Just because I say I'm someone doesn't mean I am really that person. Just because I am using the PGP or SSH key of Joe Smith doesn't mean I am Joe Smith. Now, it's pretty likely that I am, but the possibility still exists that some 733t h4xx0r or script kiddie got them from Joe.
And there comes a point where too much security slows down the system. Hey, yeah, we could go to 4096-bit encryption, but what's the point?
Basically, it boils down to a couple points:
1) If you absolutely, positively don't want anyone else but the intended reader to see some private communication, hand it to them. No transmission media is 100% secure.
2) There comes a point where security paranoia limits efficiency. We're damn close to the paranoia limit.
Just my 2 shekels.
Kierthos
Mr. Hu is not a ninja.
Information on burnable credit-card sizeed CD-ROMs is available at:
http://www.fadden.com/cdrfaq/faq07.html#[7-15]
For those that want to check out dsniff itself, the URL is:
http://www.monkey.org/~dugsong/dsniff/
Clever stuff...
--
Blaming GW Bush for the Iraq war is like blaming Ronald McDonald for the poor quality of food.
For instance, what are the certification policies for your CA? How does he check that you really are who you say you are? How does he know that you manage the server you are requesting a certificate for? How does anyone else know that?
A VPN doesn't really help. Whenever you get authentication material from certificates there still remains the problem of identifying what entity is bound to that key, and what level of trust you should give to it.
The article doesn't really establish weaknesses in either SSL or SSH. It simply explores the problem of how to trust public keys -- which has been going on ever since PK systems were developed (think PGP, X.509, etc)
I'm also pretty sure that rebooting the system isn't supposed to change the key. So what else is there that can legitimately change a key?
(And yes, I *did* try to RTFM. Checked the SSH specification, but that just says that hosts MUST have keys and MAY have multiple keys. STFW didn't help either; bunch of tech support announcements that some host somewhere was changing its key.)
I don't think you can plausibly apply the interlock protocol to SSH. When I log into a server, I expect a conversation in which each side reads the message from the other before generating their own messages. If that's the fundamental top-level conversation, any attempt to impose an interlock underneath that, unbeknownst to the communicating parties, can be spoofed.
Interlock only works if the actual communicating parties know they're interlocking. No attempt at automated interlock is going to work, because the MITM can separately spoof two separate interlocked conversations.
No, the correct answer is strong password protocols like SRP and B-SPEKE, as another poster has already observed ("Encrypted Key Exchange").
--
Xenu loves you!
Strong password protocols are the Correct Answer to this problem. If one party (the client) can't carry around the keys needed for strong authentication of both parties, if all you can carry is a password in your head, then strong password protocols like SRP, B-SPEKE, and some others on their way (AMP) are the correct route to strong security. The most effective attack known on these protocols is
1. Decide which end you want to spoof - client or server
2. Choose a guess at the password
3. Do a protocol run.
3a. If you're pretending to be the client, try and log on using the password you've guessed.
3b. If you're pretending to be the server, somehow persuade the client to try and log onto you thinking you're the real server.
4a. If you guessed the password correctly, congratulations! You've successfully spoofed your way in.
4b. If you did not guess the password correctly, you lose! And you have learned *nothing* except that your guess was wrong.
5. If you want to have another guess, you'll have to return to step 1 and persuade the other end to play with you again. They may tire of this game before you do.
(Caveat. Password files have to be kept secret for this: compromise that and you can spoof the client into thinking your the server, while running a dictionary search against them on your supercomputers. Guard password files)
Strong password protocols are Right and Good and should be used everywhere that stronger authentication is not available. Remember to use key stretching on your passwords too.
--
Xenu loves you!
I meant to say: explanation of key stretching, and the paper about it.
--
Xenu loves you!
Encrypted key exchange algorithms such as SRP and SPEKE provide strong password authentication which is resistant to all known passive and man-in-the-middle attacks. An added benefit is that they authenticate the server to the client as well as the other way around. And all this is done without PKI and without even requiring particularly strong passwords.
/etc/shadow, passwd and requiring all users to change their password to move to the new system is never going to be very popular with system administrators.
Why are they not in widespread use? It might have something to do with the fact that (AFAIK) all these algorithms are patented. SRP is patented by Stanford but apparently they allow it to be used without licensing fees in free software.
Another problem is that these algorithms cannot be used with the existing password databases. Replacing critical components such as
----
Stop worrying about the risks of nuclear power and start worrying about the risks of not using nuclear power.
Now, W is talking to Z, and since Z was presumably smart enough to supply a question it can answer, W will never know that its speaking to Z instead of X.
/etc/ssh_host_key.pub to the ~/.ssh/known_hosts key you just got; if they're different, watch out! It would have to be a very smart sniffer program to realize 'cat /etc/ssh_host_key.pub' and all other variations should get the 'fake' key substituted in.
Not entirely true.
If you are using SSH to connect to a machine, the automated key exchange and authentication may be 'impossible' to do without being vulnerable to man-in-the-middle attacks. However, once you've logged in, compare the
bah. I have seen a few people intercept SSH before but only at demonstrations. I knew all of these guys and they said they have never wanted for accounts - there's enough unencrypted traffic to not bother going after the encrypted traffic. If there is one box that no-one connects to without using ssh, it is almost always connected to from an insecure box and, at present, there is nothing to stop tty sniffing. I wont even bother mentioning people who use windoze ssh clients. On most "secure" networks, ssh is the strong link in the weak chain. As for SSL, I have never seen an intercept of SSL by anyone who didn't have the SSL certificate.
How we know is more important than what we know.
First it was firewalls, then intrusion detection systems, then VPNs, and now certification authorities (CAs) and public-key infrastructure (PKI). "If you only buy X," the sales pitch goes, "then you will be secure." But reality is never that simple, and that is especially true with PKI.
Certificates provide an attractive business model. They cost almost nothing to make, and if you can convince someone to buy a certificate each year for $5, that times the population of the Internet is a big yearly income. If you can convince someone to purchase a private CA and pay you afee for every certificate he issues, you're also in good shape. It's no wonder so many companies are trying to cash in on this potential market.With that much money at stake, it is also no wonder that almost all the literature and lobbying on the subject is produced by PKI vendors. And this literature leaves some pretty basic questions unanswered: What good are certificates anyway? Are they secure? For what?
Taken from a prior document written by Bruce Schneier which can be found here.
Man in the middle attacks have been rampant for some time now so I don't know why anyone would use an article such as this for 'clarity's' sake where security is concerned. Sure it assists in dealing with issues and bringing them to light but when you need that much of a level of trust the easiest way to circumvent ANY man in the middle attack or any other form of an authentication issue can be achieved simpler via way of verifying a PGP key id over the phone before any trusted information is encrypted and sent down the wire using any key.
Would've made a nice longer post but Monday morning hangovers leave me feeling pissy
My Slashdot Spoof
Thanks for the memories