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

[Peter Saint-Andre]

Andreas Monitzer wrote:
> On Jan 09, 2008, at 21:32, Chris Forsythe wrote:
> 
>> The majority of users (those who reported in) use gtalk, so we really
>> do need a nonsucky solution for them or we're going to continually
>> see bug reports on this.
> 
> The way I fixed #8787 is this:
> * When the user enters a JID but no hostname, an SRV lookup is done  
> and Adium connects to the host provided by the SRV result, but the  
> certificate is still checked against the host-part of the JID.

Hmm, I sense confusion. :)

A JabberID always includes a hostname (technically in XMPP terminology, 
a "domain identifier").

So if a user attempts to log in to a server, the user must have made an 
assumption about the domain identifier associated with their JID (e.g., 
the user has configured its client to connect to an account at a 
specific server that is identifier as a specific domain identifier).

So let's say my JabberID is "stpeter at gmail.com".

In this situation, "stpeter at gmail.com" is my JabberID and "gmail.com" is 
the domain identifier of the service with which I have initiated 
communications.

An SRV lookup for _xmpp-client._tcp.gmail.com may yield talk.google.com 
and when I try to connect to that I may in fact end up connecting to a 
connection manager like talk66.google.com because talk.google.com has 
some load balancer in front of it. If the certificate presented by the 
service says that the domain identifier is "gmail.com" then all is well. 
But if the certificate says the service is "talk.google.com" or 
"talk66.google.com" then we have a problem and we should prompt the user 
to accept that certificate, because there is a mismatch between what the 
service asserts and what the user provided (e.g., in the XMPP stream 
header), whether or not the user explicitly typed "gmail.com" at the 
exact time when they tried to connect (it's enough for "gmail.com" to be 
in my configuration or whatever).

> * When the user enters a JID and a hostname, Adium connects to that  
> hostname (using the A record only), and checks the certificate against  
> the hostname provided by the user, ignoring the JID.

When I look at the DNS records for gmail.com and talk.google.com, I can 
understand why you do that.

That is:

dig SRV _xmpp-client._tcp.gmail.com

vs.

dig SRV _xmpp-client._tcp.talk.google.com

> This is how I understood the RFC.

I think that *may* be a misunderstanding. We did not intend for 
"hostname" to have some special meaning in that section about 
certificate checking.

> The gtalk-users aren't using the XMPP service, but the gtalk service.  

Google Talk is an XMPP service. At least for these purposes (they use 
some non-standard extensions, but they advertise standard XMPP SRV 
records and such).

> We can force the hostname to be talk.google.com for that kind of  
> server (it's probably already done that way). If we use this for  
> Google for domains, too (this has to be verified! There were some  
> issues with that approach IIRC), there shouldn't be a problem with  
> gtalk at least.

Aha, so basically you'll do what (I think) iChat does: provide a special 
configuration for Gmail that says "please connect to talk.google.com 
even though my JID has gmail.com in it". Correct?

That seems to be acceptable to most people.

> On Jan 09, 2008, at 19:28, Peter Saint-Andre wrote:
> 
>> 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
> 
> Apple's trust sheet only allows two options (with a non-functional  
> checkbox for "always allow this certificate" [1]). Right now, only a  
> and b are implemented. I'm thinking of moving this to a and c.

Doing what is mentioned above (let the user select talk.google.com as 
the way to connect for their gmail.com or googlemail.com account) seems 
like it would obviate the need for even hitting that dialogue.

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/b6af9e41/attachment.bin>