more SSH MITM

[James A. Donald]

    --
James A. Donald:
> > > > Think about what would happen if you tried a man in the 
> > > > middle attack on an SSH server.

Eric Murray:
> By checking the key against the IP address of the server.  
> This is easily spoofed.  The links I included in my last post 
> pointed to a tool to do just that (plus MITM the ssh 
> protocol).

Not it is not.

> But even worse, there is no way to ensure that the key the 
> client has is really the server's key in the first place. The 
> client gets that key the first time it connects....the user 
> is shown a fingerprint of the key and asked to type 'yes' if 
> the user thinks that it's the server's key.

For this to happen, the attacker must solicit the the victim to 
log on to a site he has never logged onto before, or redirect 
him to logon to a site he has never logged onto before.  In 
this situation, the SSH uncertified public keys work far better 
than Verisign's certified keys -- for example the spam email 
urging us to log on to "e-golb.com" or "e-go1d.com" would fail 
if https used ssh style public keys, because the user would get 
a "new site" dialog, tipping him off that something was up, and 
that he should check what is going on.

Thus under this attack, ssh uncertified keys work far better 
than https certified keys.

> What the user is supposed to do here is to have obtained the 
> key or its fingerprint in a secure fashion outside the ssh 
> protocol.  But very few people do.  They just type 'yes' and 
> accept it.  Hence my original statement.

Far safer to do that than to rely on https certified keys, as 
lots of people discovered who logged into "e-go1d.com" or 
"BankOpAmerica.com"


> This makes a MITM attack easy, the attacker simply needs to 
> have his attack in place when the victim expects the server 
> to have a new key.

The victim never expects the server to have a new key, and in 
the unlikely event he did expect it the out of band mechanism 
notifying him of the new key is under the sites control, not 
the attackers.

All these attacks that you confidently declare are supposedly 
so easy on ssh also work against https, and work a great deal 
better.


    --digsig
         James A. Donald
     6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG
     yAguzlpuklHQyVv9VSbkoIWDQYXm/25Gqmt7qnEG
     4IYMTLFaNCAaKYXvO9t7lJdAG8LlfXr2/TYbrx58W