xsprite@bigfoot.com writes:
ssh: mitm, key stroke analysis (which seems to have been "discovered" lately but i thought it was obvious to anyone sitting down with tcpdump and an ethernet with ssh...)
Can someone clue me in on how MITM attack would work here? Am I right in thinking it's only when the user types their password into the remote machine?
The problem with certificate based approaches is that in order to be
What alternatives are there to certificates?
I'm probably just hard-of-thinking this morning.
-----Original Message----- From: alug-admin@stu.uea.ac.uk [mailto:alug-admin@stu.uea.ac.uk]On Behalf Of MJ Ray
I'm probably just hard-of-thinking this morning.
That's because you were up late nattering to me on IRC. :)
/me needs more sleep
Cheers, BJ
on Fri, Aug 24, 2001 at 11:54:57AM +0100, MJ Ray scribbled:
Can someone clue me in on how MITM attack would work here? Am I right in thinking it's only when the user types their password into the remote machine?
A key exchange is something like this: Alice retrieves Bob's key from Bob or some central authority. It is not cached locally. Alice generates a random key, and encrypts it with Bob's public key. Bob decrypts the random key (used as a session key for some symmetric cipher like Blowfish, because encrypting everything with public key algorithms is too expensive.) Bob and Alice now have a shared secret that no one else should have. Alice could also sign this data with her own key. Bob would then obtain Alice's key from her, or some central authority. This creates a connection like this:
However, if these key retrievals (Alice getting Bob's key and Bob getting Alice's key) can be intercepted and modified, then some evil person, say Mallory, can interject their own keys and obtain the random key and so can decrypt all traffic. Creating a man in the middle.
ssh gives warnings about keys already cached that have changed. Many people seem to ignore this.
The problem with certificate based approaches is that in order to be
What alternatives are there to certificates?
Very little. Most things depend on a trusted third party. Which is how webbrowsers authenticate sites. This can lead to a single point of failure, since if a root signing key is compromised, so are all the other keys signed with it. For password stuff, SRP http://srp.stanford.edu looks good, because it's based on zero knowledge proof.