SSH Server Authentication
Hi,
I am reading O'Rielly's "SSH the Secure Shell, 2ed", and want to
clarify something that I can't grasp from the book:
In section 3.4.2.5 "Server authentication and antispoofing: some gory
details" the authors mention that the server has to be authenticated.
This is done by having the server sign the challenge request. The
challenge request is produced by both, the client as well as the
server to prohibit man in the middle attack (MITM). As part of the
handshake, the server sends its public key to us, and we are assuming
that we can make sure it is the right one (from our internal database
of server:public key pairs).
Now, because we already have the public key of the server and already
know that it is the right one, what's the use of having the server
sign a challenge request with it's private key? I don't see the reason
for making sure that whoever is on the other end has the corresponding
private key. Since we use server's public key to encrypt all the
information we send to the server, MITM can't read or modify it, he
can just forward it to the correct server and forward the result back
to us. If we don't authenticate the server, the worst that MITM can do
is store the requests and then play them back to the server at a later
time, however since a symmetric session key is negotiated using
server's public key, these saved encrypted messages won't be of any
value for another session.
If anyone knows the internals of SSH protocol or knows why a server
has to be authenticated by signing a challenge, even if we already
have its public key, please reply, it would really clarify things for
me.
Thank you.
-Mike
Reply to: