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

[Kevin Smith <[e-mail]>]

On Wed, Mar 16, 2011 at 9:40 AM, Stef Walter <[e-mail]> wrote:
> 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.

This is mixing two ideas - yes, GTalk has many many hosted domains and
isn't presenting 'valid' certificates for them. However, in none of
these cases should the user be specifying a hard-coded hostname - that
just implies that their DNS setup is broken.

Virtual hosting - common
Manually specifying connection hosts - rare.

/K