[Adium-devl] Ticket #8787 (XMPP cert checking)

[Peter Saint-Andre]

I started to write about this at Trac but it was too long to paste as a 
comment on the ticket:

http://trac.adiumx.com/ticket/8787

So, regarding Ticket #8787 ("Jabber SSL certificate incorrectly checked 
against server name"), I think the proper behavior is:

1. Check the certificate against the domain name portion of the account 
as configured by the user rather than against the hostname as resolved 
by DNS, e.g., example.com rather than xmpp.example.com, or (in the case 
people care most about) gmail.com rather than talk.google.com.

2. If the server presents a certificate for a hostname other than the 
account domain, prompt the user to do one of the following:

    a. cancel the connection
    b. accept the certificate for this session, then connect
    c. accept the certificate permanently, then connect

You've no doubt seen the same behavior in your favorite browser. If the 
user chooses (c), then cache the decision and don't prompt them again.

I don't think it's good to make a special case of Google Talk in this 
regard, because other services might behave in this way too (e.g., if 
they run a huge service with lots of XMPP connection managers).

For all the gory spec details about this, see the updated information in 
Section 6.3.3 of draft-saintandre-rfc3920bis:

    2.  If the receiving entity presents a certificate during TLS
        negotiation, the initiating entity MUST validate the certificate
        in order to determine if the TLS negotiation shall succeed (see
        Section 15.2 regarding certificate validation procedures).
        Specifically, the certificate MUST be checked against the
        hostname as provided by the initiating entity (e.g., a user), not
        the hostname as resolved via the Domain Name System; e.g., if the
        user specifies a hostname of "example.net" but a [DNS-SRV] lookup
        returns "xmpp.example.net", the certificate MUST be checked as
        "example.net".  See Section 6.4 for information about the
        representation of XMPP addresses in certificates.

And Section 15.2:

    When an XMPP peer communicates with another peer securely, it MUST
    validate the peer's certificate.  There are three possible cases:

    Case #1:  The peer contains an End Entity certificate that appears to
       be certified by a chain of certificates terminating in a trust
       anchor (as described in Section 6.1 of [X509]).
    Case #2:  The peer certificate is certified by a Certificate
       Authority not known to the validating peer.
    Case #3:  The peer certificate is self-signed.

    In Case #1, the validating peer MUST do one of two things:
    1.  Verify the peer certificate according to the rules of [X509].
        The certificate SHOULD then be checked against the expected
        identity of the peer following the rules described in [HTTP-TLS],
        except that if present an [ASN.1] Object Identifier of "id-on-
        xmppAddr" (represented as a UTF8String in an otherName entity
        inside the subjectAltName) MUST be used as the identity.  If one
        of these checks fails, user-oriented clients MUST either notify
        the user (clients MAY give the user the opportunity to continue
        with the connection anyway) or terminate the connection with a
        bad certificate error.  Automated clients SHOULD terminate the
        connection (with a bad certificate error) and log the error to an
        appropriate audit log.  Automated clients MAY provide a
        configuration setting that disables this check, but MUST provide
        a setting that enables it.
    2.  The peer SHOULD show the certificate to a user for approval,
        including the entire certificate chain.  The peer MUST cache the
        certificate (or some non-forgeable representation such as a
        hash).  In future connections, the peer MUST verify that the same
        certificate was presented and MUST notify the user if it has
        changed.

    In Case #2 and Case #3, implementations SHOULD act as in Rule #2 for
    Case #1.

I apologize for all the specification language, the IETF makes me write 
it that way. :)

However, now that I read those sections from the spec, I see that this 
case is not covered by Section 15.2, since it is really:

    The peer presents an End Entity certificate that appears to
    be certified by a chain of certificates terminating in a trust
    anchor, but the presented hostname does not match the hostname
    as provided by the initiating entity.

Or somesuch.

I'll clarify this in the next version of rfc3920bis.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://adium.im/pipermail/devel_adium.im/attachments/20080109/3cda00e7/attachment.bin>