[ejabberd] XMPP per-host certs

Jesse Thompson jesse.thompson at doit.wisc.edu
Mon Feb 11 18:53:29 MSK 2008

Peter Saint-Andre wrote:
> Brian Cully wrote:
>> On 8-Feb-2008, at 17:43, Peter Saint-Andre wrote:
>>> Some clients (iChat etc.) let you specify that the hostname handling a
>>> gmail.com or googlemail.com (etc.) JID is "talk.google.com". Then when
>>> you're presented with a certificate for talk.google.com, the client
>>> considers that to be acceptable. I'll be modifying the  
>>> specifications to
>>> make it clear that this approach is one allowable authentication flow.
>> 	I assume this is true for SRV record lookup as well? 
> As you might imagine, the IETF security mafia considers the results of
> SRV lookups to be less than fully reliable, at least in the absence of
> DNSSEC. Naturally, end users can be unreliable too (who convinced them
> to input "talk.google.com" as acceptable for gmail.com?).

My opinion is that if the DKIM authors aren't that worried about DNS
poisoning, then it probably isn't a big concern for XMPP.  If DNS
poisoning becomes a problem, then SRV record forging will be the least
of our problems, and DNSSEC will become a major priority.

The IETF security's approach is akin to telling you to wear a bullet
proof vest whenever you leave your house.  Yes, it will make you more
secure, but it's not really necessary.

>> I'd be curious  
>> about experience w/ Psi, Adium, and iChat, if anyone happens to know.
> Different clients handle certificates in different ways. Harmonizing the
> user experience across clients sounds like a good goal for 2008 and beyond.

If this problem is to be resolved purely on the client side, then I
think iChat and Adium have implemented the correct approach to the problem.

Some clients (Psi) force the user to disable all SSL warnings, which
makes things less secure.  I think that this is the worst approach to
the problem.

Other clients (Pidgin, Gajim, Meebo) ignore hostname mismatches, and I
can't tell what other certificate errors they also ignore.  Obviously,
they've sacrificed some security for usability.

It would be the most desirable user experience if the client would never
have to prompt the user if it doesn't have to.  It would be nice if the
specifications defined the conditions which a client could trust a
mismatched domain certificate without prompting the user.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3340 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.jabber.ru/pipermail/ejabberd/attachments/20080211/9661493f/attachment.bin 

More information about the ejabberd mailing list