Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Secure-Shell
[Top] [All Lists]

Re: Need some education: Man-in-the-Middle Attacks

Subject: Re: Need some education: Man-in-the-Middle Attacks
Date: Fri, 1 Sep 2006 08:53:43 +0400
Steve,
On the first connection, it doesn't help and SSH is vulnerable to the
MITM attack.  The link above mentions this, but doesn't really draw
your attention to it.  ;-)

It is the holy truth. That is the reason for distributing the public
keys of servers to the clients via some off-line methods.

<slight offtopic>
and that is the problem that was tried to be solved by X.509
certificates: the trusted entity (CA) signs the public key and it
is up to the client to verify the signature. Surely this just
offloads the problem to the CA public key distribution to clients.
But it is easier to propagate one CA public key than all public
keys signed by that CA. But this scheme is not much applicable
to SSH.
</slight offtopic>

However, SSH stores the host key in the "known_hosts" file so it
doesn't need to ask for it on subsequent connection attempts.  The SSH
protocol has a mechanism whereby the client sends something (its
"challenge") encrypted with the public key for that server.  The
server decrypts it and sends an appropriate "response" back to the
client.  This lets the client know for certain that the server is the
same one as recorded in known_hosts.  The MITM can't decrypt the
challenge so it doesn't know how to respond.

I've simplified this quite a bit, but I hope this is enough to answer
your question without getting too confusing.  ;-)

Please, read the RFC 4253 and do not oversimplify the things: there is
no challenges in establishing the initial shared secret in SSH transport
layer.
-- 
Eygene

<Prev in Thread] Current Thread [Next in Thread>