[Standards] Checking hostname in XMPP server when using TLS

Simon McVittie simon.mcvittie at collabora.co.uk
Wed Nov 3 13:06:32 UTC 2010


On Wed, 03 Nov 2010 at 08:42:02 -0400, zhong ming wu wrote:
> You made good points. But there are cases where user can get the server that
> host xmpp service not necessarily from DNS; they choose not to publish it
> for whatever reason. Imagine an organization wanting to use xmpp service
> using example.org domain and have it hosted at xmpp.provider.com and they
> made the user enters the hostname in the client; pidgin and alike have the
> option for a reason.

Arguably it would be reasonable to accept either example.org or
xmpp.provider.com here, but only accepting the domain from the JID
(example.org) is consistent with the SRV-record case, and fixes the flaw
you point out below.

> Someone (possibly an unauthorized adim from example.org who can get
> example.org certificate) could take over DNS of provider.com and set up
> xmpp.provider.com and intercept the xmpp communications of example.org

If you're trusting example.org to handle your XMPP traffic, there's nothing
you can do to defend against example.org's sysadmin wanting to intercept
your communication, except revoking the certificates and getting a
better sysadmin :-)

If you do trust example.org, this sounds like a reason to *not* accept a
certificate purporting to be xmpp.provider.com in this case.

> Or in the old way www.cnn.com points to multiple ips and the browser
> randomly choose one; https thus merely checks that www.cnn.com and the
> server it connects matches.

The server presents a certificate with CN=www.cnn.com, the browser will reject
any certificate that doesn't have that name. Once again, the certificate has
to match the service that the user wanted to connect to.

(Notably, the browser wouldn't accept a certificate whose CN was one of the
IP addresses that www.cnn.com happens to point to today.)

> I think SMTP might be a slightly better example although with that TLS is
> not supposed to be mandatory. MTA looks up MX record and connects to the mx
> server and can/is supposed to verify that the mx server presents the
> certificate with matching mx hostname which is not necessarily the same
> email domain that MTA is delivering.
> MX record is not supplied by the sending user but MTA looks it up.

SMTP is unusual in that there's no expectation that the connection will be
secured at all, for historical reasons. The mechanism you describe is wrong
from a maximum-security point of view, but SMTP is normally not even
encrypted, so it's (slightly) better than nothing...

If email was invented now, and had mandatory TLS, MTAs would refuse to deliver
mail for (say) simon.mcvittie at collabora.co.uk unless the destination
mailserver could present a certificate indicating that it is, or is
authorized to act on behalf of, collabora.co.uk. Getting there
from here is basically impossible for email due to the number of existing
deployments it'd break, but at least we can avoid this design flaw for XMPP...

    Simon



More information about the Standards mailing list