Announcing: Slashdot Deals - Explore geek apps, games, gadgets and more. (what is this?)

Thank you!

We are sorry to see you leave - Beta is different and we value the time you took to try it out. Before you decide to go, please take a look at some value-adds for Beta and learn more about it. Thank you for reading Slashdot, and for making the site better!

Attacks Against SSH 1 And SSL

michael posted about 14 years ago | from the only-a-matter-of-time dept.

Encryption 170

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.

Sorry! There are no comments related to the filter you selected.

Re:So what does SSH2 do that makes it more secure (1)

klops (5179) | about 14 years ago | (#552469)

There WERE known exploits (read: script-kiddies friendly) for SSH1 protocol against its RSA-based encryption (if you compiled ssh1 with it). SSH2 doesn't use it.

Beside, as the other guys said, they just haven't
spoof for ssh2 is just not available, YET.

Re:I fail to see how.... (1)

j-pimp (177072) | about 14 years ago | (#552472)

Dsniff can be used by u17r4 37337 h4X0r5 to make scr1pts that the k1dd135 can use to do simple local attacks. Once they 0wn3d a router they can download said 5cr1pt and 0wn all the un1x b0x35 on the subnet that have users stupid enough to accept the new keys.

Kurt's SSL article is wrong! (3)

chicago greg (264786) | about 14 years ago | (#552473)

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.

Re:...wanna tell us something we DON'T know, Kurt? (1)

mugwumpjism (200010) | about 14 years ago | (#552475)

Getting on the phone to call a (potentially unreliable or corrupt) representitive of amazon.com to verify their server id is not likely to measurably improve the security of the transaction, and is almost certain not prevent me from losing anything of value (since my credit card numbers aren't worth that much to me anyhow -- I'd lose some time, but not money, if they were stolen, but I'd probably lose more time if I called every e-commerce site to verify the server id before placing an order). As long as people understand what the CA's are capable of doing, and what they're not capable of doing, I have no problem with them. It does seem that many people are confused about their capabilities, though.

Printed means of distributing fingerprints should not be overlooked; you could include the fingerprint in small print in printed advertisements. Or perhaps a printed publication listing current correct fingerprints for major e-commerce sites; a "yellow pages" of the internet. It seems "backwards" but it solves a lot of problems. No, wait - I claim copyright on that idea!

Alternatively, a government-run key signing authority, that only signs keys requested by companies and requires signatures of the company owners/CEOs would be another way of dealing with this. Or perhaps a government "tree of trust" - with Governments able to issue signing keys to certificate authorities, with the proviso that if they are abused the company will be shut down, and the abusers hung, drawn and quartered.

Then you can be assured the signing authority is as good as the Government. Personally, in a world so corrupt that alcohol is legal and marijuana illegal, I still wouldn't trust it :-)

How about it, politics?

Real life vs. Network life (1)

infiniti99 (219973) | about 14 years ago | (#552477)

It is amazing how insecure most real life (for lack of a better term) things are.

Last time I was at Bank of America they asked me to change my PIN# to one with 4 digits, instead of the usual max of 6 numbers. In the network world, you find administrators that configure systems to require more characters in a password than before, *never* less.

Take a look at Credit Cards. That's like: "I'm lazy, here's my login and password. Take only what you're supposed to." You try to tell a sysadmin that and he would flip out.

So yes, "real life" is a lot riskier. Why do we babble over our SSH bits-per-key, when in the real world we give our passwords away to the waitress?


Re:This isn't as bad as it looks (1)

coolgeek (140561) | about 14 years ago | (#552478)

Yeah, or hack the firewall at your house.

So what does SSH2 do that makes it more secure ... (1)

Rohan Talip (91270) | about 14 years ago | (#552479)

... than SSH1?

Kurt up to his usual tactics (1)

Anonymous Coward | about 14 years ago | (#552480)

I am really getting tired of Kurt. He sends out false alarms and really stupid and sometimes incorrect information. Kind of reminds me of another person (anti-online).

"For example -- this is oversimplified but essentially correct -- user Alice wants to
talk to server Bob, and Charlie wants to snoop in on her session so he can read her
mail. Alice initiates a connection with Bob, Charlie sees this and intercepts it.
Charlie talks to Bob and pretends to be Alice; on the other side he talks to Alice
and pretends to be Bob. Alice sends her public key out, which Charlie intercepts;
Charlie then sends his own public key to Bob. Bob then sends his public key to
Alice, which is again intercepted by Charlie; Charlie sends his own public key on to
Alice. "

Yeah no kidding. Everyone has known this from the beginning. Can you please tell us something we DON'T know?

You have to check with the person who's site it is or the owner of the SSH server.

Get the fingerprint directly from them, then you won't have this problem. His little stupid analogy only works when you don't know the person's fingerprint.

So learn their fingerprint...duh.

SFS - DNS the way you want it (3)

Frac (27516) | about 14 years ago | (#552481)

some guys at MIT developed a file system called SFS - Secure File System. Knowing how untrustworthy DNS really is, they used a novel authentication scheme by embedding the public key and hostname into a string called the HOSTID that's required to connect. Their implementation is based on NFS3, but the key-certifying scheme is applicable to everything.

http://www.fs.net [fs.net]

Re:man in the middle is hard (1)

xp0rnstar (199803) | about 14 years ago | (#552482)

Well even using ssh in 'secure' network can still introduce the issue of someone snagging passwords along the wire via other methods such as someone using ssh and then using ftp instead of scp or sftp so I would guesstimate that 80% of the times it is always going to be users that are the weak link and not the protocols.

So as of now I will wait for the next security based document pimping IPSec, Secure Tunneling, Diameter [diameter.org] , SSH over SSL over Biometric based authentication, then point out the clueless (l)user who just did something stupid like use a protocol which doesn't provide any encyption down the strech.

Re:So what does SSH2 do that makes it more secure (1)

Smthng (71777) | about 14 years ago | (#552483)

Read again carefully. Nothing is the difference. It's just that he hasn't coded up an attack for ssh2 yet. But it could be done in a similar way, just a few more details (I am guessing).


Re:Ouch. (2)

puetzk (98046) | about 14 years ago | (#552487)

this is not a problem in ssh.
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 /etc/ssh/ssh_host_key

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

Re:So when *should* it change? (1)

puetzk (98046) | about 14 years ago | (#552488)

of course it has to run as root - how else could it give your your own account perms when you connect to it (instead of whatever menail ones it would otherwise have)?

what about VPN? (1)

Anonymous Coward | about 14 years ago | (#552489)

I guess this has consequences for VPN systems using SSH1/SSL technology as well?

This isn't as bad as it looks (4)

enterfornone (7400) | about 14 years ago | (#552493)

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.

Pity... But: (1)

John Betonschaar (178617) | about 14 years ago | (#552496)

In the end nothing is 100% secure...

Ouch. (1)

moz25 (262020) | about 14 years ago | (#552498)

Not the best news to start the day with... considering I use SSH on all of my machines. You can bet quite a few people will be following these developments *grumble*


Re:So when *should* it change? (2)

Howie (4244) | about 14 years ago | (#552500)

Only the ssh.com implementation.

OpenSSH [openssh.com] supports SSH2 for free (beer and speech).

Re:So when *should* it change? (1)

joto (134244) | about 14 years ago | (#552501)

The program ssh2 is non-free. The protocol is not and is already implemented in openssh. Just use the command "ssh -2" if you are using openssh.

Re:Locks are to keep honest people honest (1)

Kierthos (225954) | about 14 years ago | (#552502)

*nod* However, if yon waiter uses your credit card illegally, it's usually pretty easy to track down when it started and who the guilty party is. Most credit card 'thefts' like this are done by people with a minimum of the daily recommended intake of intelligence.

However, with online security, all too frequently, the people who are intercepting transmissions or forging them are quite intelligent (or have read the user docs for their script kiddie toy). Therefore it takes a little more then the standard protocols to insure a minimum level of safety.

No protocol is 100% safe. We accept that. Well, most of us /.'ers do. It's the clueless masses that get all of their tech news from Headline News that panic over this.

Oh well. Wonder how long it will be before the next "X isn't secure" story on /.?


Re:So when *should* it change? (1)

Sc00ter (99550) | about 14 years ago | (#552503)

OpenSSH supports the SSH2 protocol, it has for a while now.

Re:I don't get it (1)

Chris Hind (176717) | about 14 years ago | (#552504)

SSL2 doesn't have client certificates; that's SSL3. The article says

While SSL requires that the server authenticate to the user, it is usually an option for the user to authenticate to the server. And since so very few users own personal certificates, it is exceedingly rare for a user to be able to prove their identity to the server in question -- leaving the connection open to attack.

To which the obvious answer is: pull your finger out and issue client certs to your users. If it's that important that you know who they are, then the effort must be worth it. This article is basically just an enormous troll.

Re:So what does SSH2 do that makes it more secure (1)

Chris Hind (176717) | about 14 years ago | (#552505)

Well, SSH1 goes up to 1 right? Whereas SSH2 goes up to 2. That means it's one more secure.

Re:man in the middle is hard (2)

QuantumG (50515) | about 14 years ago | (#552524)

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.

OpenSSH helps here (4)

dmiller (581) | about 14 years ago | (#552525)

With OpenSSH [openssh.com] you have a chance to thwart these attacks - not only does it support SSH protocol 2, it also displays "fingerprints" for each unknown key it receives from over the network. You can use this fingerprint to do out-of-band checking of key authenticity (eg. by phone, in person, PGP signatures on a web page, etc).

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).

Re:man in the middle is hard (1)

Vanders (110092) | about 14 years ago | (#552526)

What, prey tell, is wrong with "Windows ssh clients"? I'm behind a corporate firewall and use an ssh client to connect to a server outside of the network. How is that any less secure than connecting to the server using a Linux or BSD ssh client?

Not a probelm for local nets (3)

veg (76076) | about 14 years ago | (#552527)

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 :-).

Re:This isn't as bad as it looks (3)

Idaho (12907) | about 14 years ago | (#552528)

Well, it may be a little more serious than it looks.

Okay, these vulnerabilities have always existed and you could live with them because it was quite hard to exploit them.

However, as the author of the article points out, there is now a very convenient, easy to compile/install, almost 'off-the-shelf shrinkwrapped' set of applications that can do these kinds of things, which means the l33t 5(r1pt k1dd135 are probably going to find it a lot easier to use then before.

So that's why he writes the article, and I think he certainly has a point here.

Re:Kurt up to his usual tactics (1)

Anonymous Coward | about 14 years ago | (#552529)

I think this whole article is about the fact that users don't pay too much attention to fingerprints or server key changes. He's just talking about how the user's ignorance/negligence can by exploited.

Re:man in the middle is hard (2)

QuantumG (50515) | about 14 years ago | (#552530)

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.

Re:I don't get it (1)

cryptic (48987) | about 14 years ago | (#552531)

Yeah, but the point I am trying to make is that
server certificates and a decent random number generator are enough to establish a shared secret, and thus secure communication.

Obviously, the server will have no prove of the identity of the client.

...wanna tell us something we DON'T know, Kurt? (4)

mugwumpjism (200010) | about 14 years ago | (#552532)

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:

  1. Someone actually manages to break the key authority's signing key
  2. Someone replaces the key authority's signing key in your browser/software
  3. Somebody working for the key authority secretly leaks the key (a "purchase-key" attack)

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!

This does not mean SSL is insecure for shopping! (1)

andrew cooke (6522) | about 14 years ago | (#552545)

This article is very misleading. It implies (to my reading at least) that a connection secured at the server side only is not secure in some general sense.

This is not true, as far as I understand these things. Consider connecting to Amazon (say). You verify the certificate and give your credit card number. This is enough to guarantee that:

(1) you are connected to the person that has the private key associated with Amazon (ie that this is Amazon or they have had a security breach - the private key cannot be obtained by sniffing alone)

(2) man in the middle attacks are not possible.

What is not guaranteed is that you are you - all the server knows is that someone is giving your credit card number. But that's OK - no-one else has that number (at least, they didn't get it by sniffing this transaction).

This *is* a problem if you are using SSL to secure a link to your own computer for root access, for example, because then it is important that you are you. In that case you do need the server verify the client. But that's not the same as shopping...

If anyone thinks I'm wrong I would love to know!


Re:So when *should* it change? (1)

bellings (137948) | about 14 years ago | (#552546)

I don't think any of these should change the key, unless you have a really lazy administrator. The private key is generally set up to be readable only by root. Presumably, the root user can copy it to a new machine at will.

Re:man in the middle is hard (1)

bellings (137948) | about 14 years ago | (#552547)

because windoze boxen are inheritently insecure.

You're a stupid fucking troll, aren't you?

Re:Ok, i'll bite.. (2)

Pflipp (130638) | about 14 years ago | (#552548)

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...

Re:Pity... But: (2)

PigleT (28894) | about 14 years ago | (#552549)

"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? "

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.
.|` Clouds cross the black moonlight,

Re:This does not mean SSL is insecure for shopping (1)

AlanStokes (42890) | about 14 years ago | (#552550)

Consider connecting to Amazon (say). You verify the certificate and give your credit card number.

There's the rub. Do you really verify the certificate? Does your browser warn you if there are problems? Would you notice if the certificate was for a slightly differently spelled domain? Do you check if the certificate is on a revocation list?

Any user who doesn't always check these things very carefully is vulnerable to being spoofed by a fake server.

Only the first time... (1)

call -151 (230520) | about 14 years ago | (#552551)

One thing that is important about the man-in-the-middle attack is that usually the only time there is the request for the certificate is the first time you connect to the machine. The interloping machine has no means of knowing, in general, whether or not you already have a valid certificate, so when you go to connect and get the "is this certificate ok" message, if it is not the first time you are connecting to that machine you will know something is up and can try to figure out what is going on or get some help. The method of exchanging certificates is a vulnerability, but you need to start trust someone/something to get going and it doesn't seem like this vulnerability is that profound to a knowledgeable user. Sorry about the earlier empty post.

Ehmz, no. (3)

Lion-O (81320) | about 14 years ago | (#552552)

Thus Alice thinks she is talking directly to Bob in a secure manner, when in fact Charlie is in the middle intercepting the communications, able to monitor them and also to modify the content.

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?

Re:...wanna tell us something we DON'T know, Kurt? (4)

bellings (137948) | about 14 years ago | (#552553)

This is a good thing and SSH's handling of the situation is more secure than a central signing authority.

black is white. stop is go. SSH's handling of the situation is most certainly not more secure than a central signing authority.

he'd rather that we trust some other person with our security.

Look, the article was a tripey piece of crap, but it certainly never said that. The simple, basic fact that the article gave was this -- if you don't verify who you're talking to, then you haven't verified who you're talking to. Somehow, this dumbass managed to make an entire article out of that. And I read it, and got the ad impressions, and everything. I feel dirty.

For anyone who hasn't taken the time to read the article yet, or ever learn basic security stuff, let me boil it down: In every single system known to man or mathematics, to identify an entity X, you must trust something to say "method Y is an accurate method to identify X". Unfortunately, the default way to get get that identification method in SSH and SSL is fundementally flawed. If entity W has no way to identify X, but wants to talk to X for the very first time, W simply asks X "what is a question that only you can answer correctly, and by answering proves that you are X?" That leads to a false sense of security at best, because entity Z can step in front of X, and provide a false answer to the "how can I identify you?" question. Voila! 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.

Most two year olds could come up with a half dozen solutions for this problem. Certificate Authorities (where, essentially, someone pays a third party to certify that the identification question is a valid one) are certainly one partial solution. Manually transmitting the identification question (usually in the form of public keys) on secure medium is another. Ignoring the problem, because its inconvenient to deal with, is another solution.

As many people have pointed out already, ignoring the problem is often the "good enough" thing to do anyhow, since intercepting SSH or SSL communications is still several orders of magnitude more difficult than other attack vectors. But saying a Certificate Authority is bad because you can be lulled into a false sense of security is kind of like saying "you should only do electrical work on your house with the power switched on, since switching the power off lulls you into a false sense of security." You're certainly still vulnerable to attacks to the Certificate Authority, in exactly the same way you can still be electrocuted even if you think the fuse box is off. But there are certainly many situations where the CA's are the least inexpensive and effective method to mitigate the most risk.

A couple of Questions...And answers. (1)

farrellj (563) | about 14 years ago | (#552554)

First, do schemes like OPIE and S/Key also suffer from this? (I just found the Answer...YES)

Is SSH2 any better? (Yes, SSH2 is less vulnurable to Man in the Middle attacks...but it is just a matter of time before it, too is made vulnerable.)


Re:So when *should* it change? (1)

Alik (81811) | about 14 years ago | (#552555)

So sshd has to run as root? Isn't that a big ol' hole waiting for the next kiddie with a sploit?

Possible with almost any protocol (1)

sporty (27564) | about 14 years ago | (#552556)

If you are the man in the middle near one of the two ends, its always possible to sniff all connections for the pertinent one (or multiple if you split the communications) and when enough data is passed through, to cut off one end.

This is why a combination of cryptography and stegonography is needed. And even then, it is not 100%.

Just being cap'n obvious...


Re:...wanna tell us something we DON'T know, Kurt? (1)

mugwumpjism (200010) | about 14 years ago | (#552557)

black is white. stop is go. SSH's handling of the situation is most certainly not more secure than a central signing authority.

You are right - it is a matter of opinion. I based my statement on the fact that any system that involves Alice, Bob and Trent automatically has one more place to attack than a system just involving Alice and Bob. Hence, because SSH does not support the model involving Trent (or more to the point, Trent is the system administrator or user), if Trent's real name turns out to be Mallory it's less of a problem. (Alice and Bob are the two people trying to communicate, Trent is a trusted arbitrator, and Mallory is a malicious user)

On the other hand, if Alice and Bob don't know how to ensure that their communications aren't being snooped (ie, they don't know to pick up the phone and verbally check, or swap keys, or securely exchange SSH keys), and the system they are using doesn't present suitable warnings and instructions, then yes - the certificate authority is more secure. But IMHO this is a flawed "bullshit security" model that happens to be what Certificate Authoritys' business models are based on.

For anyone who hasn't taken the time to read the article yet, or ever learn basic security stuff, let me boil it down: In every single system known to man or mathematics, to identify an entity X, you must trust something to say "method Y is an accurate method to identify X".

Don't be so hostile. How do you know I'm not an encryption expert?

The point I was making was that it's better to get those identification methods straight from the horse's mouth than trust some agency that might be corrupt. And I explained why there are financial incentives for them to be selectively corrupt; the "purchase-key" attack.

IMO, the only way that works is the web of trust model [rubin.ch] , designed for PGP, but the concepts apply equally to SSH keys or anything else really.

Why do you think Carl Ellison and Bruce Schneier warn of the risks of PKI? [securify.com]

To me, the CA's are selling people the right to cast aside the problem of teaching and learning secure key exchange, whilst reaping in the profits. They are capitalising on "the path of least resistance" - either learn some basic security concepts, and go to great lengths to ensure your keys are exchanged properly or pay them $5 a year for their "snake oil" certificates of security that cost them next to nothing to produce.

Re:man in the middle is hard (1)

Delphis (11548) | about 14 years ago | (#552558)

Following in the same thread as the other two replies above me, I fail to see why using windows ssh clients is INHERENTLY more insecure than using a linux one. Yes, problems may arise if trojan binaries are run .. that danger is also possible if you use Linux as well thought.

Someone with a mind to security would NOT run such unknown programs, I know I don't. I use SSH to talk to different Linux machines on the company network (ethernet, but unencrypted passwords are still BAD to bandy around) and also to my own Linux machine outside of it (for obvious reasons). I don't run Telnet or FTP services on any of the machines I administrate either, because they encourage luser tendencies.

So, how did you burn yourself on a windows box to be so bitter about it?


Re:This isn't as bad as it looks (1)

Zocalo (252965) | about 14 years ago | (#552559)

Actually, since dsniff works under Linux that is going to take out a chunk of kiddies straight away. Then there is the fact that (horrors!) it doesn't have a GUI which is going to claim another chunk. Of course, those that are still in the game are more likely to be those who know how to do something with the tools they have been given... Fortunately the documentation for dsniff is not exactly the "1...2...3...exploit!" guide that most kiddies seem to require to get anywhere.

As always, if you know about it, then you can do something about it, and using it is still better than not using it. Just don't believe that it must be a secure connection. Anyway, dsniff has its moments; watching your boss surfing a pr0n site from the HR Director's office for example... :->

Re:Let them have it. (1)

darkith (183433) | about 14 years ago | (#552560)

Didn't read the article?
The article doesn't have anything to do with cracking SSL/SSH encryption, but discusses the classic man-in-the-middle attack.

Re:Kurt up to his usual tactics (1)

crimsun (4771) | about 14 years ago | (#552567)

Actually Kurt is actually quite on target here. He's _not_ being overly paranoid; after all, most of us are "system administrators" and need to be more overtly cautious. The X-Files has it right: "Trust no one."

With that I advocate OpenSSH [openssh.com] , the development of which Kurt takes an active part in (read the openssh-unix-dev@mindrot.org mailing list!).

Insurance (3)

oolon (43347) | about 14 years ago | (#552568)

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!


Re:what about VPN? (2)

slim (1652) | about 14 years ago | (#552569)

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.

Re:This isn't as bad as it looks (1)

darkith (183433) | about 14 years ago | (#552570)

I disagree...a surprising number of the honey-pot articles I've read contain references to the crackers using Unix/Linux.
While command line tools aren't favored by the BackOrfice/GUI crowd, there's also the opportunity for somebody to create a fairly automated script to exploit any well known vulnerabilities...(eg. ADM's named/bind exploits).

The article is a bit OT in pointing these out as specific SSL/SSH vulnerabilities...man-in-the-middle attacks can be done with just about any protocol. It really just points out that encryption is no holy-grail.

credit cards insecure to begin with (1)

Mondo54 (48155) | about 14 years ago | (#552571)

Shopper John wants to make a purchase at the Acme store. He gives his credit card to clerk Mike, who's handles the transaction with the credit company. In the meantime, he makes note of the number and expiration date. The flaw isn't merely digital...it's also in the way transactions usually too intimately involve more people than it should.

So what? (1)

the_tsi (19767) | about 14 years ago | (#552572)

We've known since the beginning that SSH was maleable. Most people know not to use it for high security -- it's just there to keep the casual observer from grabbing passwords/keys. It's there to slow down someone who really wants to get to you, not stop them.


...More Powerful than Otto Preminger...

Re:This isn't as bad as it looks (3)

linuxelf (123067) | about 14 years ago | (#552573)

Well, this isn't actuall as bad as you might think. The attacker has to be in a pretty specific point, somewhere between you and your target. Some script kiddie sitting at home with his road runner account will still need to hack into an ISP that's routing your packets in order to intercept. And, that warning that SSH gives saying that they key changed should never be ignored. If you get that, drop the connection.

Quite crappy article (2)

Ektanoor (9949) | about 14 years ago | (#552574)

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...

Let them have it. (1)

Anonymous Coward | about 14 years ago | (#552575)

Listen, if they can decrypt one of my keys to get a secure transaction, then let them have my credit card number. That is all I have to say. Not like I cannot get the money back or anything like that. I still feel that nothing is 100% secure, but I can say that SSl is nothing to fool around with. Especially if you are building it straight from source and you are your own authority. Crack it?? Maybe, but I will leave that up to some 14 year old in Germany. VPNs are ok and they have their own leaks as well. There are more hacks for VPNs than there are for SSL/SSH1

Re:man in the middle is hard (1)

Zocalo (252965) | about 14 years ago | (#552576)

There are two ways of making this "man in the middle" very easy if you have the right access.

Firstly, as mentioned in the article, you can subvert DNS at the initiating end of the chain so that the initiator of the SSH actually talks to the hacker's PC instead of the target; since the hacker is proxying the connection the remote end doesn't matter. Subverting DNS? As easy as adding a line to the hosts file, although access to BIND's files is obviously better.

Secondly, if you have access to the router (see The Default Logins DB [nerdnet.com] ), you can redirect traffic through your workstation transparently. There is a nice article on this in the current issue of Phrack [infonexus.com] for Cisco (and presumably compatible) routers. Everyone trusts a router, remember?

Not trivial, maybe, but it's definately possible to do this in the wild with the right tools if you are determined enough. Remember; most hacks are internal, and most serious hacks are leveraged to increasingly higher levels of priviledge from the original exploit.

Re:So when *should* it change? (1)

RelliK (4466) | about 14 years ago | (#552577)

The host's private key *may* change if you upgrade the OS, wiping out the existing installation first, and don't bother to back up the private key. This is a sign of laziness and/or cluelessness on the part of the sysadmin. In general, the host's private key never changes, so this article is actually scarier than the reality.

...and here's the rest (1)

mugwumpjism (200010) | about 14 years ago | (#552578)

Most two year olds could come up with a half dozen solutions for this problem.

Fine, someone go fetch me a two year old child.

Certificate Authorities [...] are certainly one partial solution.

Yeah... because, heck - who needs a whole solution to rest the security of their business on?

But saying a Certificate Authority is bad because you can be lulled into a false sense of security is kind of like saying "you should only do electrical work on your house with the power switched on, since switching the power off lulls you into a false sense of security." You're certainly still vulnerable to attacks to the Certificate Authority, in exactly the same way you can still be electrocuted even if you think the fuse box is off.

I don't relate to your analogy - I think "don't trust the power cables to be safe just because they are switched off" is more like it, but it is still rubbish.

How about, trusting a certificate authority to certify keys is like trusting a Government to decide what is right and wrong rather than using the old "respect and love your neighbour" approach that has worked in the past. Most people are happy (or at least, full and content), and the Government makes a lot of money, but the people are not free.

No, I've got one that's much better - "it's like trusting a secretary of another company with sealing the envelopes of important letters"

Re:man in the middle is hard (1)

QuantumG (50515) | about 14 years ago | (#552579)

how can I say this nicely.. there are open bugs in windoze that will never be fixed and never be reported because the only people who know about them are using them for their own personal gain. I'm not saying that the windoze SSH client is inherently more insecure than the linux one (after all, you can get ssh source and compile it on win32.. oh but wait, there is the fact that virtually no-one does any testing on win32 and as such there could be holes that are windoze specific that no-one has found, but I'm sure you use a proprietory ssh client anyways), what I'm telling you is that windoze machines are inherently more insecure. I am telling you in no uncertain terms that if you run a windoze box you are not even closed to secure.

As for security minded people not running trojans.. it's a part of email culture. My friends don't think so I'm not going to think either. And it's only this one time.

Old news, new script kiddie tool (1)

rveety (223650) | about 14 years ago | (#552580)

Hasn't anyone here read applied cryptography? The man-in-the-middle attack has been known about for years. This is not a "new" attack as reported in the article. This is however the first I've seen a ready to use implementation of the attack.

Re:Users are often the source of the problem (2)

QuantumG (50515) | about 14 years ago | (#552581)

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.

Locks are to keep honest people honest (3)

dasunt (249686) | about 14 years ago | (#552582)

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.

Re:Pity... But: (3)

PigleT (28894) | about 14 years ago | (#552583)

"In the end nothing is 100% secure... "

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.
.|` Clouds cross the black moonlight,

Re:Pity... But: (2)

PigleT (28894) | about 14 years ago | (#552586)

And I forgot to carry on ranting... ;)

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.
.|` Clouds cross the black moonlight,

a little work around (1)

pixel fairy (898) | about 14 years ago | (#552588)

one thing i do for that not compleltly paranoid(who are not on a publicly accessable network at all) is copy the hosts public key onto a floppy that the users can carry around. (and hope does not break. id love to find burnable credit card sized cd-roms)

there can be other variations of this trick, like a web site to go to (on a different host) etc. that would at least make it much harder to spoof successfully.

Re:man in the middle is hard (1)

Vanders (110092) | about 14 years ago | (#552594)

I'm behind a firewall on a VPN, please explain to me how this causes my Windows SSH client to be any less secure against this form of attack than any other? No? I didn't think you could.

I fail to see how.... (1)

TobyWong (168498) | about 14 years ago | (#552595)

...dsniff qualifies as "script kiddie" material. It's a collection of tools that require a reasonable amount of understanding of network protocols in order to use effectively.

Users are often the source of the problem (2)

FreeUser (11483) | about 14 years ago | (#552596)

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.

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 /etc/inetd.conf, then either reboot or kill -1 [pid] where [pid] is the process id of the inetd daemon).

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

Re:man in the middle is hard (1)

RelliK (4466) | about 14 years ago | (#552597)

Following in the same thread as the other two replies above me, I fail to see why using windows ssh clients is INHERENTLY more insecure than using a linux one. Yes, problems may arise if trojan binaries are run .. that danger is also possible if you use Linux as well thought.

He didn't mean windows ssh clients, but the OS itself. (Wrong word choice, but that's the idea he was trying to convey, and I agree with that btw). Windows is inherently insecure, and the ssh client can only be as secure as the OS it runs on. OTOH, Linux has a quite good security model. Things like Melissa/ILOVEYOU are simply impossible on Linux.

'known hosts' (1)

TA (14109) | about 14 years ago | (#552598)

Sigh. You just have to be careful the first time you connect your two sites with SSH. After that the other host already has the public key, and if a third party then tries to intercept and replace it then ssh detects it and cries foul. TA

Ironicly... (1)

skware (78429) | about 14 years ago | (#552599)

The ad baner at the top of the page is for VeriSign:
"Secure your site with 128 bit SSL Encryption"

Re:man in the middle is hard (1)

QuantumG (50515) | about 14 years ago | (#552600)

You've mentioned how to get the victim to talk to you, that's the first step and there's a variety of ways (like for example, just using TCP highjacking) but the hard part is when you start to do that transaction. You have to take that code, decrypt it, re-encrypt it, send it on it's way. It's a lot of code, and if it has bugs it can spell disaster. But frankly, it's a non-issue if ssh is doing it's job. If when the message comes up "the remote server key has been changed, SOMEONE COULD BE MONITORING YOU RIGHT NOW" any admin worth his salt will say "I didn't change the server key, hey Tony! Did you change the server key?" and eventually just step over to the machine in question and login to the console. If it's a remote machine they'll probably pick up the phone and give someone a call. There's some sort of secondary chanell they can go through to identify what is happening.

A Hybrid approach (3)

FreeUser (11483) | about 14 years ago | (#552601)

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.

Signed SSH keys??? (1)

Orgasmatron (8103) | about 14 years ago | (#552602)

I just can't see how having signed keys for SSH would help anyone. Unlike SSL, you don't just connect to an arbitrary host with SSH. Someone set up an account for you, and sent you a password. Didn't they also send you the fingerprint? If they didn't, then security isn't that important to them.

I know quite a few people that don't bother to lock their cars. They don't care about security. Are cars broken because they don't care?

just mitm (5)

QuMa (19440) | about 14 years ago | (#552603)

It's just a man in the middle attack, hardly worth the electrons it's published with. Anyways, it claims man in the middle is fundamentel to public key is not true. The interlock protocol by rivest and shamir is quite effective against this sort of thing... The following description is quoted from Applied Cryptography by Bruce Schneier, second edition (page 49):

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:
  1. Alice sends bob her public key.
  2. Bob sends alice his public key.
  3. Alice encryptions her message using bob's public key. She sends half of the encrypted message to bob.
  4. Bob encrypts his message using alice's public key. He sends half of the encrypted message to alice.
  5. Alice sends the other half of her encrypted message to bob.
  6. 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.
  7. 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.

Re:...wanna tell us something we DON'T know, Kurt? (2)

bellings (137948) | about 14 years ago | (#552604)

I apologize for my tone. And I also apologize for my conclusion... I'm reading a lot of posts on here saying "SSL is secure because it uses a CA, and SSH is not secure because it does not use a CA." Apparently, the exact function of a CA isn't generally well known; if the attitude of posters on slashdot is any indication, there are quite a few people who believe CA's provide some type of "magic" security.

I agree that the way CA's are generally used today, where often the only existing CA (VeriSign) is alone used in some kind of binary "trust/not trust" is almost insane. And for most of the traffic SSH is used for, methods of exchange are usually possible that are orders of magnitude more secure than trusting Verisign.

But for one of the most common types of encrypted traffic -- transmitting mostly non-sensitive information to e-commerce sites -- I think CA's are a fairly reasonable solution. If someone decides to steal my credit card numbers, Verisign is not the weak link. Getting on the phone to call a (potentially unreliable or corrupt) representitive of amazon.com to verify their server id is not likely to measurably improve the security of the transaction, and is almost certain not prevent me from losing anything of value (since my credit card numbers aren't worth that much to me anyhow -- I'd lose some time, but not money, if they were stolen, but I'd probably lose more time if I called every e-commerce site to verify the server id before placing an order). As long as people understand what the CA's are capable of doing, and what they're not capable of doing, I have no problem with them. It does seem that many people are confused about their capabilities, though.

dsniff 2.3 against SRP: anyone tested? (2)

neurokhan (256555) | about 14 years ago | (#552605)

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!

My configuration is pretty secure (1)

Kevinv (21462) | about 14 years ago | (#552606)

I only use protocol 2 & do not allow password authentication.

I must have the users public key installed in their authorized_keys2 file BEFORE they are even allowed. Currently they have to mail it to me on a floppy for me to add it.

However it would still be vulnerable to a man in the middle attack (which is what the paper is about) until i figure out to keep OpenSSH from sending the public key to any client that tries to connect. Instead I want to send them a floppy with the public key on it and use it instead.

Oh and under OpenSSH client it creates a fingerprint of the destinations public key under the first connection, so this attack only works the first time a user connects to the machine. Otherwise the fingerprints won't match.


Recommendations? (1)

p3d0 (42270) | about 14 years ago | (#552607)

It sounds like it's just that first connection which could be secretly insecure. Subsequent connections announce that they are insecure by warning that the key has changed.

So what should we sshd users do? Sounds like the following would be prudent:

  1. When you have trusted (eg. physical) access to your host machine, put its public key on a floppy and take it with you.
  2. Add that key to the client machine's known_hosts file yourself, thereby skipping that first insecure connection.
  3. Also save a copy of the private key somewhere. Then if you reinstall ssh, you don't have to change keys.
  4. Never make a connection if the key has changed.
Sounds somewhat labour intensive. Can any of this be automated? If you have several hosts, can you safely use the same key pair for all of them?
Patrick Doyle

Re:what about VPN? (2)

enterfornone (7400) | about 14 years ago | (#552608)

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.

Re:Pity... But: (2)

Kierthos (225954) | about 14 years ago | (#552609)


"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.


dsniff URL (5)

phaze3000 (204500) | about 14 years ago | (#552611)

For those that want to check out dsniff itself, the URL is:

http://www.monkey.org/~dugsong/dsniff/ [monkey.org]

Clever stuff...


Re:what about VPN? (2)

Ngwenya (147097) | about 14 years ago | (#552612)

But even if you have certificates signed by a third party, that's not the end of the story.

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)

So when *should* it change? (4)

Alik (81811) | about 14 years ago | (#552613)

As pointed out in the article, you can't really defeat stuff like this through user education, because Users Are Dumb. Seems to me that you *can* do the sort of risk-reduction that Schneier's always talking about. Therefore, o wise Slashdot users (I'm pretty sure there's one of you somewhere...), when is it reasonable to see a host key change? I can think of:
  1. Installation of new sshd
  2. Upgrade of OS (new software installed)
  3. Serious mucking with hardware configuration (not sure why --- I guess the keygen code uses some parameters as a seed)

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.)

Re:man in the middle is hard (1)

Delphis (11548) | about 14 years ago | (#552618)

Yes, I guess the fact the QuantumG's ORIGINAL post (#31) was talking about the SSH clients themselves was why I was responding to the remarks made about windows ssh clients.

I *do* agree that windows machines are not as easy to secure as their Linux counterparts. Linux is the OS of choice for me and I keep all my important information on Linux. I administer a number of Linux machines as I believe they make better servers for efficiency, security and stability than windows machines.

This topic though talks about vulnerabilities of SSH/SSL, and while it may be that programs running under windows MAY be more susceptible to attack and possibly even be suspect themselves, the actual USE OF SSH/SSL (in terms of encrypting network traffic) is not really any different between OS's - windows is no more vulnerable than Linux in that respect I think. Client programs (of ANY kind) being secure is a slightly different problem - it's certainly related! - but it's a different problem.


Re:...wanna tell us something we DON'T know, Kurt? (2)

Azog (20907) | about 14 years ago | (#552621)

hear, hear.

If you use Open SSH and always check your key fingerprints, this is not an issue. Whenever I set up SSH on a new machine I copy the key fingerprint into my Handspring Visor. Then I can check it when I connect remotely. That eliminates the man-in-the-middle attack. This is not that hard to do, the SSH documentation talks about these things.

I prefer this to trusting a certificate authority (and probably having to PAY a certificate authority. Ugh.)

I do occasionally worry about using Putty SSH to connect from windows machines - somebody who broke into the Windows box could grab my password like that, but hey, you have to draw the line of paranoia somewhere. And CA's don't help at all for that problem anyway.

Torrey Hoffman (Azog)

Last F.Y.I. (1)

xp0rnstar (199803) | about 14 years ago | (#552622)

Under some circumstances, an intruder who is able to observe an SSL-encrypted session, and subsequently interrogate the server involved in the session, may be able to recover the session key used in that session, and then recover the encrypted data from that session.

The vulnerability can only be exploited if the intruder is able to make repeated session-establishment attempts to the same vulnerable web server which was involved in the original session. In addition, the server must return error messages that distinguish between several modes of failure. Although the number of session-establishment requests is large, it is significantly more efficient than a brute-force attack against the session key. Note that, although web servers comprise the majority of vulnerable servers, other PKCS#1-enabled servers may be vulnerable.

Note that the server's public and private key are not at risk from this vulnerability, and that an intruder is only able to recover data from a single session per attack. Compromising a single session does not give an intruder any additional ability to compromise subsequent sessions. Further, as mentioned above, this vulnerability does not affect all PKCS#1-enabled products.

Snipped from CERT advisory CA-98.07.PKCS

Here is an OpenSSL issue
OpenSSL bypassing [securify.com]

Last but not least there is ssldump [rtfm.com] , an SSLv3/TLS network protocol analyzer which identifies TCP connections on the chosen network interface and attempts to interpret them as SSLv3/TLS traffic. When it identifies SSLv3/TLS traffic, it decodes the records and displays them in a textual form to stdout. If provided with the appropriate keying material, it will also decrypt the connections and display the application data traffic.

Someone said they'd never heard of issues with SSL made me want to get the info on this so apologies for making a redundant post if it seems this way. This does not include issues with Mozilla, Netscape and IE and SSL since it would've taken a lot more space... ./shrugs

home sweet home [antioffline.com]

Re:This isn't as bad as it looks (1)

Zocalo (252965) | about 14 years ago | (#552624)

True, the more enlightened and capable kiddies will probably have a dual boot capability, and if you use any UNIX-a-like at all then you are not going to be mortally afraid of command lines. Where your typical kiddie is going to back of this kind of thing though is the fact that it involves quite a bit of work, and there are a *lot* of softer targets out there. On the otherhand, if it's encrypted it might be more worthwhile...

As to specifically fingering SSL/SSH in this instance; yes this is not just a SSL/SSH specific problem, and it has been technically possible to do this before. It's just not been so comparatively trivial; I've been playing with the new dsniff to eavesdrop on our LAN for a few hours now and it works very well... two credit cards numbers already!

That's the scary part of course. Either these users have disabled all security options in their browsers or are ignoring the messages that they are getting. Question is, do I change their order to a bunch of sex toys to prove the point of their stupidity? The solution as ever is education and more education, with the big piece of clue-by-four if neccesary.

Encrypted key exchange (3)

XNormal (8617) | about 14 years ago | (#552626)

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.

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 /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.


In Summary: Man in the middle attacks are tough (1)

ChaosDiscord (4913) | about 14 years ago | (#552628)

In Summary: Man in the middle attacks are a tough problem, but solvable so long as the end user pays attention.

No one seriously concerned about security should be surprised. (If you are suprised, perhaps your serious concern should lead you to do a bit of research.)

I was a bit dismayed to find the error, (Regarding man in the middle attacks on SSH) "If this is the first time you are connecting to a host and you do not have the server's public key locally, you will be none the wiser." Actually, the first time you connect to a host, SSH 1 generously mentions "Host key not found from the list of known hosts. Are you sure you want to continue connecting (yes/no)?" (You can disable this behavior, but that's a Bad Idea (tm).) If you're really concerned, you can get the server's public key through a secure channel.

Re:I don't get it (1)

Carl Drougge (222479) | about 14 years ago | (#552629)

But anyone can get a server certificate. Sure, it won't have to same user-info as that in the server, but how many users check that?

Man-in-the-middle is not completely unavoidable (3)

ddstreet (49825) | about 14 years ago | (#552630)

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.

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 /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.

man in the middle is hard (3)

QuantumG (50515) | about 14 years ago | (#552631)

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.

Authenticated (2)

xp0rnstar (199803) | about 14 years ago | (#552632)

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 [securify.com] .

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 [antioffline.com]

Re:So when *should* it change? (1)

QuantumG (50515) | about 14 years ago | (#552633)

isn't SSH2 non-free?

I don't get it (1)

cryptic (48987) | about 14 years ago | (#552634)

What is the problem with SSL?

The client (web-browser) has the public key of the CA (certificate authority), so it can verify the server's identity. It can then use the public key of the server to send a random number to the server, and ONLY somebody knowing the server's private key, will know this number. This establishes a shared secret between the server and the client, and should prevent the man-in-the-middle attack that is described in the article.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?