(merging threads) On Thu, May 19, 2011 at 7:38 PM, Winfried Tilanus <[email protected]> wrote: > Using CORS doesn't really change my argument: The browser can't request > the TXT records from the DNS. With or without CORS the XHR will be > directed to the url provided to it. It can either be provided by the > script running in the browser or by the user. So the problem you > describe does not occur when using browser based BOSH clients.
Web clients use a server-side helper to look up TXT records. I think this requirement is well-understood. > Probably I am missing the point here, but I don't see how any BOSH > client has any means to check who it authenticates to: When using BOSH > you connect with HTTPS (hopefully not HTTP) to the proxying web server > or directly to the connection manager. The connection manager sets up > its own, hopefully encrypted, connection to, again hopefully, the right > XMPP server. So when using BOSH, you put a hell lot of trust in the > connection manager: everything after the first hop is out of your > control. That's exactly the problem: since you place trust in the connection manager, you have to be sure that you're using the *right one*. If server discovery is secure (due to using DNSSEC or any other secure mechanism), then you know that you're using the correct connection manager. If the discovery is insecure, then you might be pointed at a hostile server. Part of service discovery is the XMPP server continuing the chain of trust, telling you which BOSH server it vouches for. If the discovery mechanism is insecure, the chain of trust is broken. Using a discovered BOSH server is no more a "leap of faith" than anything else built on the notion of chain-of-trust--the entire Internet, essentially. > In the case of a fat client identifying the BOSH uri by looking up the > DNS TXT records, there is only one TLS certificate going to be checked > by the client: that of the url the TXT record pointed to. If that TXT > record is compromised and points to https://evil.com/bind, and evil.com > can present a valid TLS certificate, then there is no way the client can > detect the evilness of evil.com. The only way out is making sure we can > trust that TXT record by using DNSSEC. Sure there's a way out of it: use a discovery mechanism that doesn't depend on DNS, as I gave one example of. > Why on earth would you want to connect using BOSH when you can connect > directly? You use a server-side helper to do the discovery, exactly as you already have to do with TXT lookups in web clients. > Well, that argument more or less prevents *any* hosted XMPP solution. If > the hosting party doesn't want to carry certificates for all domains > they host, then no secure connections are possible, with or without BOSH. Not at all. With the mechanism I just explained, the BOSH server only needs its own TLS certificate. Users of the server (people who own their own domains pointing at it) only need to run a "stub" XMPP server capable of TLS and the above discovery mechanism. Not to say that's ideal, of course--lots of people own domains and can set up DNS records but can't run an XMPP "stub" server, and it's more complex to implement. I didn't say it was a great solution--it just demonstrates that it's possible. I wonder if it'd be possible to stick a TLS certificate chain and a signature in TXT records, next to _xmppconnect. This would allow signing discovery records, without adding new trust dependencies (it uses the same certificate you already have), without depending on DNSSEC, and it'd be fully backwards-compatible. Will have to do some research... -- Glenn Maynard
