On Fri, Feb 07, 2003 at 12:23:15PM -0500, Leland T. Snyder wrote: > Let's say I have a service that you log into using SSL. > Since the public key and private keys are the same and the handshake is the > same (i.e. you know the first packets are for login/password) even thoe as a > sniffer of the packets I can't read them.
This is incorrect. The SSL handshake involves computing shared values from random sources of information. So the handshake will look different with every SSL connection. By the time that the application's data (login/passwd) is sent, the two sides have negotiated a new shared key for the connection, and are using new random initialization vectors, to ensure that dictionary attacks and reply attacks cannot take place. Where SSL and Kerberos make the most sense is when you'd like the traffic of the session to be private to the two endpoints. Kerberos does a good job of providing authentication, but does nothing for secrecy of the established connection. SSL can actually do both authentication and secrecy, but is lacking the centralized framework of Kerberos. Different tools, different purposes, and they may or may not combine well. But you won't need SSL for the reason you mentioned. :) -- Join the fight against terrorism by giving up your liberties today!
msg00568/pgp00000.pgp
Description: PGP signature
