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) [email protected] 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
