Re: "The End of SSL and SSH?"

[Crispin Cowan <crispin () WIREX COM>]

Kurt Seifried wrote:

> It is also incredibly difficult for users to ascertain whether the key is legit or not. I've had some people suggest 
> that all the SSH
> keys be PGP signed and put on floppy and given to users (that one made me laugh). Most users will happily accept SSL 
> certs that have
> expired, point to the wrong site or are self signed (all of which could be a man in the middle attack or a lazy 
> admin).

What Kurt is describing is the "initial key placement" problem, and it is endemic to all cryptographic protocols.  No 
matter what you
do, if you want to authenticate some remote party with a cryptographic secret, you must find some way to deliver the 
secret to the
other party securely, or you end up subject to the man-in-the-middle attack.  Your crypto system is not a viable 
option, because by
definition the keys that make it work are not in place yet.  You can think of it as a requirement for a secure 
"introduction", in the
Victorian sense.

SSL, SSH, and PGP each took a different approach to addressing, if not solving, the initial key placement problem, and 
each has its own
strengths & weaknesses:

   * SSL:  a big CA (Certificate Authorith) will sign everyone's certificate so that they can all recognize each other 
as having
     CA-signed certificates.  You are who Verisign says you are.
   * SSH:  punts the whole problem, and makes the users responsible for initial key placement.  Brilliant & lame at the 
same time, this
     has allowed SSH to spread rapidly, because it is much easier to install than most other secure remote access/VPN 
solutions.  To be
     really secure, you can sneakernet (floppy disk) your initial key onto all the nodes you want.  You can also punt, 
and use insecure
     means to place the initial keys: SSH warns you that you're subject to a man-in-the-middle attack when you do that. 
 CAVEAT:  I
     don't think this is as vulnerable as Kurt says.  IP Spoofing is possible at any given time, but is costly to 
maintain.  The
     attacker would have to know just WHEN I am going to trust IP destination addresses/DNS to place an authentication 
key to be able
     to carry off a man-in-the-middle attack.
   * PGP:  the "web of trust" introduction method.  By providing users with a semi-automatic tool for managing the 
transitive closure
     of everyone you've been "securely" introduced to (i.e. met at a USENIX conference :-) PGP leverages the "6 degrees 
of separation"
     effect to *hopefully* get you introduced to most of the people you need to.

> I used to religously sign email's with PGP until I realized that no-one probably checked, how did I know this? I 
> started modifying
> the email after signing so that it wouldn't verify, no-one ever complained.

That's a separate issue.  I don't think PGP even has a plurality of secure mail client users, let alone a majority.  I 
further doubt
that most mail users even use authenticated mail systems.  And my Netscape mail client regularly tells me that S/MIME 
certs on mailing
list traffic are bad, likely because mailing list processing has corrupted the message so that the cert no longer 
matches.


> SSH and SSL are in my opinion poor implementations of security protocols, they also lack a lot of things such as 
> repudiation/etc. To
> believe they are the best we can do makes me very sad. I suspect in 5 years we'll talk about ssh/ssl like we talk 
> about telnet right
> now.

They may be bad protocols (or good; I'm not a crypto protocol guy) but not for the reason you're presenting.  The issue 
you bring up is
endemic to all crypto protocols.

Crispin

--
Crispin Cowan, Ph.D.
Chief Research Scientist, WireX Communications, Inc. http://wirex.com
Free Hardened Linux Distribution:                    http://immunix.org