back to article 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 …

  1. This post has been deleted by its author

    1. elaar

      You base your network purchasing on whether the bug release guys have perfect spelling/grammar?

      1. This post has been deleted by its author

        1. elaar

          The quality of their code seems to be pretty good compared to most, and reported bugs are fixed very quick. As much as we all dislike Cisco for their dominance and over-priced equipment, there is a very good reason why their products are so popular regardless of price.

          1. This post has been deleted by its author

  2. 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.

    1. Dan Paul

      Re: ssl/tls overly complex

      Thanks Mike,

      I appreciate an explanation like yours that goes into enough detail to be understandable while holding back on the unnecessarily technical baloney, user opinion and general BS we see from too many commentards.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2019