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

[Shumon Huque]

Peter Saint-Andre wrote:

> 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'm sorry for joining this thread so late. I just started using
Adium recently  ..

One problem with demanding that the certificate be checked against
the domain-identifier portion of the JID is that in the general
case the domain name in question may be be associated with many 
other services besides jabber, running on different machines, 
operated by different people with differing levels of security.
And for security reasons, you don't want to share an SSL/TLS
certificate between those services.

For example, in our deployment we are using a domain identifier
of "upenn.edu", but the actual hostname of the jabber server
is "jabber.upenn.edu":

  _xmpp-client._tcp.upenn.edu. IN    SRV     5 0 5222 jabber.upenn.edu.

There may be another service we are hosting at "upenn.edu":

  _blah._tcp.upenn.edu. IN SRV 5 0 9999 blahserver.upenn.edu.

As far as I know, in today's world, SSL/TLS certificates are issued 
to hosts rather than specific services running on hosts (typically 
the f.q.d.n specified in the subject DN or the dNSName of the 
subjectAltName extension). So if we are required to use the "upenn.edu" 
name, for the above example, we can't issue different certificates for 
the different services _xmpp-client and _blah running at that name. One 
service owner can impersonate the other service, and compromising one 
service leads to the ability to compromise the other.

*(If anyone knows of a way to issue x.509 certs to specific services
 running on hosts, and if those constraints are actually honored
 by client software, I'd be happy to be informed about that.)

So, our jabber server's certificate is tied to "jabber.upenn.edu"
and not "upenn.edu", so as to differentiate it and compartmentalize
it's security from other services running at the upenn.edu name.

On the other hand, I think one objection to using certificates tied 
to the target of the DNS SRV record is that DNS is not secure (where 
is DNSSEC when you need it!? :-). A DNS spoofing attack could victimize 
a client by causing it to connect to a rogue server with a valid 
SSL/TLS certificate. This is potentially a big issue for sites doing 
plaintext passwords over SSL. For sites using cryptographic authentication 
(eg. SASL/GSSAPI/Kerberos5 etc) this is a less credible objection since
it mainly results in denial of service rather than the compromise of 
user credentials.

Perhaps the best compromise is:

  1. If the client software explicitly specifies the server hostname
     to connect to, use that hostname in the certificate check.
  2. If not, use the domain identifier portion of the JID.

That way, we could use option (1) and avoid certificate check
warnings, and satisfy our security concerns.

Any thoughts?
---
Shumon Huque				3401 Walnut Street, Suite 221A,
Network Engineering			Philadelphia, PA 19104-6228, USA.
Information Systems & Computing		(215)898-2477, (215)898-9348 (Fax)
University of Pennsylvania / MAGPI.	E-mail: shuque -at- isc.upenn.edu