You base your network purchasing on whether the bug release guys have perfect spelling/grammar?
Cisco Jabbers in the clear due to STARTTLS bug
'Twas the night before Christmas, when sysadmins probably weren't watching their advisory feeds, that Cisco announced a vulnerability in its Jabber for Windows. The advisory suggests users of Jabber for Windows 10.6.x through to 11.1.x upgrade, because those versions are vulnerable to a STARTTLS man-in-the-middle downgrade …
COMMENTS
-
This post has been deleted by its author
-
-
This post has been deleted by its author
-
-
This post has been deleted by its author
-
-
-
-
-
Monday 4th January 2016 13:45 GMT mike acker
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.