Hi,
due the current NSA discussion I investigate around S2S-encryption and how openfire handles it. I'm the administrator of some small openfire-servers and I saw an issue: If I set the S2S-TLS configuration to required the incoming connection of gmail.com still listed unencrypted in the server2server overview.
I looked into the code and when I'm correct there are some assumptions of the past (pre XMPP 1.0): If a server uses dialback it is never encrypted - and vice versa: If server-dialback is enabled it also enables unencrypted communication. I think that's wrong. We've to split 'encryption' and 'authorization of the connection' in different parts!
I would provide a patch for incoming Server2Server connections but I've figured out how the setting is stored in the property table:
- xmpp.server.tls.enabled
- xmpp.server.dialback.enabled
If #1 is disabled => Connection.TLSPolicy.disabled
If #1 is enabled => Connection.TLSPolicy.optional or required
If #2 is disabled => Connection.TLSPolicy.required
(Look into LocalIncomingServerSession#createSession(..) - there is a tlsPolicy variable based on that server configuration ..)
We need a property to specify the TLS handling directly and independent of authentication (Server-Dialback/SAML). There is no problem to introduce such property value like 'xmpp.server.tls.policy' like the existing 'xmpp.client.tls.policy'. But I want to hear your feedback about that.
Just to note: XEP-0288 supports my theory. Look to the second example, it creates a tls connection and authorize it with dialback. (http://xmpp.org/extensions/xep-0288.html) Based on this I'm looking forward to a (second) new property for outgoing S2S: If something is wrong in the remote-servers certificate-chain we could fallback to server-dialback and validate the domain. At the current point we're able to close the encrypted connection and retry it unencrypted or we still ignore such errors and 'believe' the remote servers SASL.
I'm glad to hear your opinion.
Best regards,
Sven