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

[Peter Saint-Andre]

Shumon Huque wrote:
> 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.

But what is the user's JID? Is it deke at jabber.upenn.edu or is it
deke at upenn.edu? As far as I can see, your service is running on
jabber.upenn.edu:

$ telnet jabber.upenn.edu 5269
Trying 128.91.2.172...
Connected to jabber.upenn.edu.
Escape character is '^]'.

So you have a cert for that service. The fact that an SRV record
redirects upenn.edu to jabber.upenn.edu is immaterial as far as the
certificates are concerned.

But perhaps I misunderstand your concern.

> *(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.

Right.

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

I think that's what we had agreed to earlier in the thread. The specs
don't say that yet, though.

> Any thoughts?

Thanks for the feedback. :)

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/20080213/52e500e6/attachment.bin>