[Standards] HTTPS certificate verification when discovering XBOSH via TXT

[Glenn Maynard]

How is HTTPS certificate validation handled when connecting to a BOSH
server discovered via TXT (XEP-0156)?

If a user is connecting as "u...@jabber.org", the client can discover
the location of the BOSH server by looking up the appropriate TXT
record.  However, the DNS response isn't trusted, and may point to a
hostile server.  If the _xmpp-client-xbosh response for jabber.org
points at "https://evil.org/bind";, clients will connect to the hostile
site and merely verify that the certificate matches the hostile site;
there's no verification that evil.org is actually a legitimate BOSH
server for jabber.org.  If the user has configured his client to
reject unsecured connections, this will be defeated.

SRV discovery for XMPP deals with this case.  It only uses the SRV
entry to discover the IP address, and the actual connection proceeds
according to the original host.  If the user is connecting as
u...@jabber.org, and _xmpp-server._tcp.jabber.org points to evil.org,
the CN will be verified against "jabber.org" rather than "evil.org",
and fail.

That isn't specified for XBOSH, however, and it wouldn't work: BOSH is
meant to support least-common-denominator clients, and most simple
clients (eg. XHR) have no mechanism to override the IP address when
connecting to an HTTPS URL, in order to verify a certificate using a
hostname other than the one in the URL.  If the DNS record isn't
trusted, clients should probably always warn if the service hostname
doesn't match the JID, which would effectively restrict discovered
BOSH services to the same domain as the JID, which would be
unfortunate.

This problem will go away in the distant future when DNSSEC is more
readily available, but lacking that, is there anything that deals with
this, or at least specifies what's supposed to happen?  (XEP-0156
makes no mention this in Security Considerations, nor of DNSSEC.)

-- 
Glenn Maynard

Re: [Standards] Redirects in BOSH

[Evgeniy Khramtsov]

26.02.2011 00:26, Matthew A. Miller wrote:

On Feb 25, 2011, at 08:14 , Joe Hildebrand wrote:
   


If the redirect comes from a trusted source (e.g. over HTTPS with a verified
certificate) then this can work ok, although we've decided that the BOSH
see-other-uri error is easier to control through XMLHTTPRequest,
particularly when doing CORS.

Be careful that you don't blindly accept redirects, however, or you are
trivial to man-in-the-middle attack.
 

If the redirect is via HTTP 3xx+cookie, then CORS already has a solution via 
Access-Control-* headers.  However, the XMLHttpRequest objects in browsers 
don't always let you know this happened.  Maintaining the redirect then becomes 
the responsibility of the browser, which may not be desirable for BOSH (I don't 
think it's desirable, anyway (-: ).

If done via the "see-other-uri" BOSH error condition, then this is definitely a 
concern.  On the plus side, the BOSH software (whether browser-based or stand-alone) 
knows a redirect is happening in this case, so you have a better opportunity to protect 
yourself at the application-level.
   


So what is the decision? What approach should we choose?

--
Regards,
Evgeniy Khramtsov, ProcessOne.
xmpp:x...@jabber.ru.