On 9/25/05, Matt Tucker <[EMAIL PROTECTED]> wrote: > 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 >
Hmm. I didn't read the specs or jeps fully yet but mainaining a jabber server. I agree with Matt that it's a bummer how jids are constructed. But my suggestion would be to make it as consistant as possible for the user. As a user I know that a jid is "[EMAIL PROTECTED]". And from this view I can browse for services on the server "server.net". My suggestion would be to list services like "server.net/service". This would be a resource for the server. A muc-room would be "server.net/muc/room" and a user using this mucroom would have the jid "[EMAIL PROTECTED]/muc/room" or just "[EMAIL PROTECTED]/room". Just an idea. -- -- Johannes
