How is HTTPS certificate validation handled when connecting to a BOSH server discovered via TXT (XEP-0156)?
If a user is connecting as "[email protected]", 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 [email protected], 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
