Re: [xmpp] Clarification of TLS Identity checking in draft-ietf-xmpp-3920bis

[Stef Walter <[e-mail]>]

Hmmm, thunderbird hid this thread inside of an unrelated one :/

On 03/15/2011 03:41 AM, Peter Saint-Andre wrote:
> So yes, it is true that in some circumstances a user might configure his
> IM client with two things:
> 
> 1. The domain name of the application service, which is the domainpart
> of his JID, such as [e-mail] => montague.lit; this is the
> "source domain".
> 
> 2. A "hardcoded" hostname that he has explicitly assocated with the
> domainpart of your JID, such as apps.shakespeare.lit; this is the
> "target domain".
> 
> However, for the purposes of checking the identity of the application
> service when connecting via TLS, Romeo's client would check to see that
> the service presents a certificate that says it is "montague.lit"
> (unless he overrides the checks or explicitly approve of connecting to
> "apps.shakesepeare.lit").
> 
> Please understand that 99% of users will never see such a configuration
> option and that they don't know anything about apps.shakespeare.lit or
> some special hostname that they're connecting to -- all that they know
> is that they're trying to connect to montague.lit (if they even know
> this, because lots of people just think that they're trying to connect
> to "Shakespeare" or even "that IM thing" -- if you doubt it, I recommend
> that you run your own public IM service, because it can be quite
> enlightening).

Sadly this isn't a corner case. It's the case with widely deployed XMPP
systems such as Google talk, which uses virtual hosting extensively as
part of google apps. And it seems that many XMPP clients take a
"hardcoded" or configured hostname into account when verifying the
certificate.

The Google Talk certificate does not contain the domainpart of the JID
at all, and contains the "hardcoded" hostname instead. In this setup
there are tens of thousands of different XMPP domains all using the same
certificate.

This may seem strange, broken or annoying but represents a massive
deployment. So it turns out that far more users than you might expect
will see such a configuration option, and will see these certificate
warnings.

>From a security perspective the hardcoded or configured hostname is user
input and can be used in identity checks. So client app developers have
two options:

 * Throwing up a "cop out" certificate dialog and tossing the entire
   security decision in the lap of the user.

 * Using all the user's input (not just the JID) to generate reference
   identifiers to use to verify the certificate.

If these were corner cases, and 99% of users would never run into this,
then I'd tend to agree with you, but this is a widely deployed
configuration on virtually hosted XMPP servers.

Cheers,

Stef