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.
Dividing auth. and encr. into different parts makes sense. I assume you want to set the s2s policy to required which makes sense. So it would be nice if one could specity an exception list for some (old) servers.
The sooner you provide a patch one can review and comment it.
The Server2Server and Session part is really complex and and my point of view we don’t have any (unit-)tests there. There are easier Opensource projects to contribute to
Also there is some stuff for Apache Mina (Package ‘org.jivesoftware.openfire.nio’) - Maybe we could delete it? It is hard enough to provide a patch for the used part of S2S-connections. The Mina-Part seems to be a proof of concept (maybe really good) but it is not finished?
Maybe we could switch to Maven (http://issues.igniterealtime.org/browse/OF-546) and merge to Github. Then it would be easier for me to bring in some pull-requests that you could review and merge seperatly.
If you need help switching to maven just ask! I’ve moved several big projects to maven with success.
In short: When we remove Apache Mina implementation I could start with implementation/patch. But I’m unable to implement and test it for the Mina-Part without any introduction. Maybe we could ask Gaston Dombiak about the working state?
The problem is not, that nobody knows how to migrate to Maven. In fact there’s already a branch for it, which looks well, but old (2012).
The problem is rather, that progress is very slow and that nobody (i.e. the lead or some other experienced OF developer) is really pushing it forward. Unfortunately, Guus isn’t really responsive, I’ve asked him to comment about several open issues (a few weeks ago), which require his decision, but no response. Consequently nothing can move.
As you said, there are easier projects to contribute to. Contributors like you or me can only contribute small patches, but we can’t just drop Java 5/6, or Mina or Ant (in favor of Maven), because it’s hard to evaluate the impact. Nor can we move to github or bitbucket or other location.
I would be glad to become a openfire contributor. I think i’m not the most active contributor in the project but I’ll contribute several times a month. I like security and asynchronous connection handling. Also I like testing, java build management and clean-code. If I could choose I want support you by moving the project to github and migrate to maven or gradle. Then I would push unit- and component testing. Later on I would upgrade Apache Mina and rewrite the whole S2S-Code.
For me it seems that the project builds upon one lead. I think that’s good structure for companies where the developers have to follow the product manager/product owner. For open source projects there should be a team of 4-10 person work as a core-team.
They are responsible for the project and collaborate with each other. If there is a decision to fell there must be a democratic vote. I think such structure protects the project to get stuck.
In short words: You’re right. To be a contributor is no ticket to get big decissions done. But the project needs decissions (Github, Maven, Java, DependencyInjection) to be maintainable. For example: I couldn’t integrate DI alone but with DI classes are easier to test.
(I don’t want do discharge somebody from the throne but I wan’t to keep a discussion about the project structure and how I could help the project without getting unmotivated by long decisions).
Great! As you have noted, we are sort of stuck in the mud at the moment with getting much of anything done. CSH has been actively pushing stuff, but big changes are not happening. I have attempted to contact Guus to see what his availability is going forward to start moving the project forward again.
I am hoping that the github migration gets those 4-10 people interested in actively developing openfire and we can push forward again!
To get you commiting access, it would be good to see some patches you have lined up, just to make sure you have reasonable programming skills We don’t have a formal process to get developers commit access, I just want to get some more folks engaged and running.
