[Standards] Checking hostname in XMPP server when using TLS

zhong ming wu mr.z.m.wu at gmail.com
Wed Nov 3 12:42:02 UTC 2010


On Wed, Nov 3, 2010 at 7:02 AM, Simon McVittie <
simon.mcvittie at collabora.co.uk> wrote:
> On Tue, 02 Nov 2010 at 18:11:18 -0400, zhong ming wu wrote:
>> Moreover assuming DNS is safe (big assumption in the past & some will
>> say now) should client not do DNS look up and then use server cert to
>> verify authenticity of it
>
> DNS can't be assumed to be safe; anything we're told via a SRV lookup is
> suspect. The thing we're trying to verify is:
>
> * the user told us to connect as joe at example.com, therefore they wanted to
>  talk to the example.com server
> * we got a connection to a server claiming to serve example.com
> * is it really authorized to act on behalf of example.com?
>
> If there's a SRV record telling us we should actually connect to
> jabber.services.example.net (or whatever), accepting a certificate for
> jabber.services.example.net would be unsafe, because that's not what the
> user asked for.

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. In that case you may still consider your point of
giving priority to user entered input as still valid but I don't.

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

>> TLS implementation of HTTP/SMTP/IMAP/POP do not work like XMPP in this
regard
>
> HTTPS doesn't do SRV lookups, but when you use a CNAME it behaves just
like
> XMPP. If I connect to https://www.google.com/ I get this:
>
>    smcv at reptile% dig www.google.com
>    ...
>    ;; QUESTION SECTION:
>    ;www.google.com.                    IN      A
>    ...
>    ;; ANSWER SECTION:
>    www.google.com.             348     IN      CNAME   www.l.google.com.
>    www.l.google.com.   156     IN      A       209.85.227.103
>    ... (and more geolocated addresses for www.l.google.com)
>
> and when I connect to 209.85.227.103 (or whatever), it presents a
certificate
> for www.google.com (not for www.l.google.com or 209.85.227.103).
>
>    S
>

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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20101103/a95aa473/attachment.html>


More information about the Standards mailing list