/psa
-------- Original Message -------- Date: Wed, 09 Jan 2008 11:28:54 -0700 From: Peter Saint-Andre <[EMAIL PROTECTED]> To: Adium Dev <[EMAIL PROTECTED]> Subject: [Adium-devl] Ticket #8787 (XMPP cert checking) 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/
_______________________________________________ Adium-devl mailing list [EMAIL PROTECTED] http://adiumx.com/mailman/listinfo/adium-devl_adiumx.com
smime.p7s
Description: S/MIME Cryptographic Signature
