[Operators] requiring channel encryption

Peter Saint-Andre stpeter at stpeter.im
Wed Apr 30 11:02:53 CDT 2008


Brian Cully wrote:
> 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 connections,
>> 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
>> both)?
> 
>     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
> for it.

The jabber.org admin team makes decisions only for the jabber.org
service, not the network as a whole. Even if we require c2s at our
service, other services are under no compulsion to do so.

>     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. 

Is it trivial? Do the servers you connect to via ssh use certs that are
issued by a CA? Probably not -- but your ssh app will warn you if the
cert changes.

> Getting free certs can work, but can also not, depending on
> verification process. 

We do give away free (Class 1) certs at https://www.xmpp.net/

> 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, 

Can't she create a self-signed cert?

> but if we're going to go the encryption/trust
> route, it should be relatively secure.

Definitions of "secure" vary. What's yours? :)

>     Perhaps TLS is just the wrong answer for building trust networks on
> the Internet, and we should try to think of something fundamentally
> different.

Perhaps. I don't think that TLS is a magic solution to building trust,
but it can't hurt. Plus if we can advertise that we have s2s encryption
across most of the public network, that will help build trust from the
outside.

>> 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 (even
>> 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.

I think that for now we would accept TLS+dialback at jabber.org, and
eventually work to upgrade that to CA-issued certs. One step at a time.

>     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
> "real" ones.
> 
>     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.

We already issue certs -- see xmpp.net :)

>     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.

Yes, that is a big problem, and one reason why Google Talk doesn't do TLS.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/operators/attachments/20080430/d4969be6/attachment-0001.bin 


More information about the Operators mailing list