[Operators] requiring channel encryption
bcully at gmail.com
Tue Apr 29 19:52:39 CDT 2008
On 29-Apr-2008, at 16:50, Peter Saint-Andre wrote:
> The jabber.org admin team has been discussing the option of requiring
> STARTTLS (or legacy SSL on port 5223) for client-to-server
> and STARTTLS for server-to-server connections. I'm wondering:
> 1. Are any other XMPP services doing this right now (for c2s or s2s or
I think mandating TLS for c2s is a mistake. At the edges of the
network, it should really be up to the local operators and their
conditions. There are /lots/ of networks that have absolutely no need
s2s is a different animal. If you allow self-signed certs, I'm sure
compliance wouldn't be much of a problem. It's useful to encrypt, but
without authentication, I'm not sure if it's all that much of a net-
win. Man-in-the-middle becomes trivial, so you'd really only stop the
bottom rung. Getting free certs can work, but can also not, depending
on verification process. I'm really not sure what the correct solution
is here. I don't want to out the gal putting up ejabberd on a server
in her basement from the process, but if we're going to go the
encryption/trust route, it should be relatively secure.
Perhaps TLS is just the wrong answer for building trust networks on
the Internet, and we should try to think of something fundamentally
> 3. What is your guess as to the percentage of XMPP services that won't
> be able to connect to jabber.org for s2s when we make this change
> if we accept self-signed certificates)? ;-)
A small percentage if you accept self-signed. To segue back to a
previous thread, I think it would be useful to put up a test server
which accepts self-signed, and have jabber.org only accept verified
roots. It's just not that hard to get a cert for no (or almost no)
cost. When you're ready to put it up in front of the public, it's the
least you can do.
This way, you get the best of both worlds. While you're testing you
can just whip up some certs. When you're ready to go live you get some
Naturally, jabber.org might not have the funding for such a service.
If no one else out there can donate their time and hardware (I can't),
perhaps we can put a small fund together for maintenance? I can,
however, provide the initial development (gratis), as I'm sure many
others could as well.
The only problems I see are what to do with XMPP hosting providers.
If you want to host a large number of domains, requiring TLS on s2s
can get really unwieldy. DNS issues make trusting SRV records
problematic as well. So, again, no better solution.
More information about the Operators