Cisco Jabbers in the clear due to STARTTLS bug

ssl/tls overly complex

it is generally conceeded that "complexity is the enemy of security"

if you look at SSL/TLS you can see the start sequence is overly complex. let's review:

what you have, when the client first contacts the server:

the client has an x.509 certificate that it thinks is correct for the server;

the server holds the corresponding private key but DOES NOT have a Public Key for the Client;

if you examine this situation you'll see that initially:

the client can send a secure message to the server bu the server cannot send a secure message to the client . this is because the server does not hold a public key for the client -- and this is normal

as a result: on initial contact: the server must send an encrypted HELLO message to the client. the client can verify that this is in fact from the desired server becuse it holds the x.509 certificate for that server. or at least this is supposed to be the case . we proceed on the basis that the validity of the x.509 certificate is questionalble and that that issue must be resolved in order to proceed with secure communication

once the client has validated the server's HELLO message then the CLIENT must generate the session key. this is done using the server's x.509 certificate as the _ key encryption key _ ( "KEK" ) .

once the server receives the session key the dialog can proceed with messages encrypted using the session key .

as things stand now the client has no way of knowing which x.509 certificates are valid. these are broadcast like newspapers and fraud has already been discovered on several occasions . this is the REAL problem with SSL/TLS

to fix it the client needs a KEK device that can be used to countersign -- and thus to validate -- x.509 certificates . only important x.509 need to be validated and the client will need sources with which such verification can be effected . this is the REAL issue with SSL/TLS.