[Operators] Post-google TLS on s2s connections
Olle E. Johansson
oej at edvina.net
Thu May 23 15:38:59 UTC 2013
23 maj 2013 kl. 17:06 skrev Jonas Wielicki <xmpp-operators at sotecware.net>:
> Hi all,
> It's been discussend and I'm keen to find out about authenticated and
> encrypted s2s.
> So I wonder what, if any, the current “standards” or suggestions on this
> one are. I'm a fan of CACert, and I'd like to stick for that. How's the
> reputation of CACert in the XMPP community? I believe I read somewhere
> that hardly anyone really does validation of the s2s-TLS-connection if
> one is used at all?
> To boil it down: What would I need as a server operator to have the
> optimal setup for s2s TLS?
> If there are no standards yet here (although I guess there are some,
> based on the behaviour of current implementations), I think we shall
> discuss this, with the major blocker “Google Federation” out of the way.
In SIP we have a standard for s2s connection reuse, that basically says
that without a client auth we need two tls connections. Before I send to
you I need to know which domains you are responsible for. If there is
a connection between us already that you set up, I have no idea on
the domains you are responsible for unless I required a client cert, thus
I can not reuse that TLS connections for requests the other way. If I
required a client cert, I know which domains you are responsible for
and can reuse the connection.
In SIP, there's no clear distinction between s2s and c2s like we have
in XMPP. A SIP server doesn't really know if the connection it is
another server or a client. Luckily that problem doesn't exist in XMPP so
being able to request a client cert is more simple.
Now, with old SSL/TLS the server requiring a client cert had to say
"I only accept client certs from these CA's". With TLS 1.x something
this was removed, which opens up a lot of new possibilities for
self-signed certs verified by other means, like with DANE
or the HTTP/PKI verification that is being worked on.
Unfortunately it's hard to require people to update their OpenSSL
or gnuTLS stack to get this, which means that there has to be
a small set of CAs used for client certs for this to work in a
federation, which stinks...
Just my 4 öre :-)
More information about the Operators