Hey all, We take security issues very seriously and appreciate the feedback. However, some of the reactions in this thread are simply unreasonable. Why do so many JSF discussions wax into flame wars? :)
So, I'd like to take a step back and try to step through the issues. First, unless there's an evil XMPP server, you'll never run into problems. Servers are required to reject stream connections for domains that they don't control. So, if "example.blah.com" isn't controlled by the XMPP server "blah.com", than an s2s connection for that subdomain will be rejected. Now, let's consider the case of an evil XMPP server. If somebody has managed to subvert your DNS tree, you're pretty much already screwed. Why wouldn't they just take over DNS of your normal server address? Even those of you that use dyndns and other such services where you don't control the full tree are in the same boat. Let's take the example: someuser.dyndns.org Assume your server is down so some Jive Messenger instance tries to make the connection to dyndns.org. If an evil XMPP server truly lives at that address, how could you possibly trust that your dynamic DNS entry is also valid? Can anyone come up with a real example of this DNS attack being a greater vulnerability than standard dialback? If you don't trust your DNS tree, I would argue that the security of dialback is already compromised. So, dialback itself. I think it provides good security for most users. However, dialback + TLS doesn't seem to be implemented by any servers yet. We're going to create an implementation for Jive Messenger because we think it offers a great mix of security and ease of use. The most common secure s2s mechanism we've found so far is dialback + SASL external. For security, it's pretty much critical that the certificate presented through SASL external be signed by a CA. We're just completing our TLS + SASL external implementation now and will likely support all the major CA's by default. Based on many threads on this mailing list I'd also like to support certs signed by CACert.org by default. Anyway, assuming that servers are using TLS + SASL external, even a DNS attack wouldn't compromise the security of the Jive Messenger algorithm -- they would also need to subvert the CA cert signing process. > I disagree that this is a minor security hole. The fact that > my JM server can potentially contact two completely different > servers for the same JID is a very bad thing. Jabber ID's are > designed to be unique, and they should be. This uniqueness is > provided by using domain names to help partition off the > namespace. What you are essentially doing is flattening this > namespace by changing your implementation. > > ie, when my server contacts [EMAIL PROTECTED], it > should NEVER, EVER, try to send that message to > [EMAIL PROTECTED] instead. This seems very bad to me. Umm, I think you misunderstand. Actually what happens is that the JM instance will connect to jabber.org but attempt to send the packet to [EMAIL PROTECTED] JID uniqueness is never violated. >From David Waite: > It is that servers which implement the XMPP standard and which don't add > this DNS hack will not be able to contact all the services someone may if > they are also running under Jive. We still tell users to make the DNS entries for compatibility with other servers. But, a good example of when users might not bother to make the DNS entries when using JM is when they want to connect multiple XMPP servers together but only inside their org (east-coast.example.com, west-coast.example.com, etc). Regards, Matt
