They were designed for the old version of Openfire that did not use Java NIO. Openfire can scale up to 4000 users out of the box and up to 200,000 if cache is configued properly
I am not sure I understand why you need a proxy in front of your Openfire server. What exactly are you protecting it from? A denial of service attack (DOS)?
Are you not allowing federation with other domains like google.com and other organisations??
XMPP servers are not like web servers. No internet user should use your server without authentication over an encrypted TLS connection. If the authentication fails or the connection becomes idle later on, Openfire will automatically disconnect the TCP connection.
We want to protect our Openfire server from intrusion or sniffing.
Federation are not allowed.
Users will use Spark or Pandion for instance.
In fact, we have an application plateform accessible through the web for our users. And we want to include a collaboration server (openfire).
The plateform is extremly secured and i have no choice but to use a proxy. Users will reach the proxy in the DMZ and it will make the connection with Openfire server in the internal.
Like i said before, i used Wireshark to take a look at the traffic. And i could see all messages. And we don’t want that. Is there any solution to encrypt messages ?
You have not answered the question of why you are treating a persistent XMPP connection like multiple HTTP requests/responses, but it does not matter
According to the source code, if your client requests for a secure session, then the connection manager passes the request back to Openfire. It is not limiting or restricting security. It queries Openfire for the security policy to use. If it is optional, then the client must request for TLS.
I suggest you force TLS for all connections in Openfire itself.