Connection Manager 3.6.0 and Openfire 3.6.0 Security

Openfire Openfire Support
1

I’m extending my architecture for my openfire setup, and I’m using the connection manager in conjunction with my server. I’m trying to make sure the whole network is secure, but I’m finding that connections through the connection manager are not listed as secure according to the server.

When I look at the list of users, I see the little golden pad lock for all those connecting diretly to the server, but for those going through the connection manager server, they’re not there. This leads me to believe these connections aren’t secured across TLS/SSL.

Upon further investigation, I thought I should poke into the keytool syntax on the connection manager server (maybe it needed the crt I thought). So I imported them according to the syntax, and now my keystore/trust store looks like this:

jabber:/opt/connection_manager/conf# keytool -list -keystore keystore
Enter keystore password:

Keystore type: JKS
Keystore provider: SUN

Your keystore contains 1 entry

servepath.com, 30 Sep, 2008, trustedCertEntry,
Certificate fingerprint (MD5): E3:C3:50:DA:5F:8B:CD:3A:2A:7E:E6:59:10:C0:2A:A4

jabber:/opt/connection_manager/conf# keytool -list -keystore truststore
Enter keystore password:

Keystore type: JKS
Keystore provider: SUN

Your keystore contains 1 entry

gd_intermediate, 30 Sep, 2008, trustedCertEntry,
Certificate fingerprint (MD5): D5:DF:85:B7:9A:52:87:D1:8C:D5:0F:90:23:2D:B5:34

Now… my keystore and truststore are both in /opt/connection_manager/conf so I don’t know if that’s right or not. I’m also noticing that all the other stuff isn’t in there… it just has entries for my two certs, my domain certificate and the intermediate authenticating certificate. Am I missing something or are the files wrong? Is there something extra that I have to do to to the manager.xml? do these files belong in …/resources/security/ instead?

Help appreciated.

2

Here’s the ssl section that I have in the /opt/connection_manager/conf/manager.xml:

true 5223 jks *************** resources/security/truststore ***************

I’ve corrected probably one problem - and that was not importing the correct key/intermediate in the right keystore/truststore…

jabber:/opt/connection_manager/resources/security# keytool -list -keystore keystore
Enter keystore password:

Keystore type: JKS
Keystore provider: SUN

Your keystore contains 1 entry

servepath.com, 30 Sep, 2008, trustedCertEntry,
Certificate fingerprint (MD5): E3:C3:50:DA:5F:8B:CD:3A:2A:7E:E6:59:10:C0:2A:A4

jabber:/opt/connection_manager/resources/security# keytool -list -keystore truststore
Enter keystore password:

Keystore type: JKS
Keystore provider: SUN

Your keystore contains 36 entries

verisignclass3g2ca, 26 Mar, 2004, trustedCertEntry,
Certificate fingerprint (MD5): A2:33:9B:4C:74:78:73:D4:6C:E7:C1:F3:8D:CB:5C:E9
entrustclientca, 9 Jan, 2003, trustedCertEntry,
Certificate fingerprint (MD5): 0C:41:2F:13:5B:A0:54:F5:96:66:2D:7E:CD:0E:03:F4
thawtepersonalbasicca, 13 Feb, 1999, trustedCertEntry,
Certificate fingerprint (MD5): E6:0B:D2:C9:CA:2D:88:DB:1A:71:0E:4B:78:EB:02:41
gd_intermediate, 30 Sep, 2008, trustedCertEntry,
Certificate fingerprint (MD5): D5:DF:85:B7:9A:52:87:D1:8C:D5:0F:90:23:2D:B5:34
verisignclass2g3ca, 26 Mar, 2004, trustedCertEntry,
Certificate fingerprint (MD5): F8:BE:C4:63:22:C9:A8:46:74:8B:B8:1D:1E:4A:2B:F6
thawtepersonalpremiumca, 13 Feb, 1999, trustedCertEntry,
Certificate fingerprint (MD5): 3A:B2:DE:22:9A:20:93:49:F9:ED:C8:D2:8A:E7:68:0D
valicertclass2ca, 12 Jan, 2005, trustedCertEntry,
Certificate fingerprint (MD5): A9:23:75:9B:BA:49:36:6E:31:C2:DB:F2:E7:66:BA:87
entrustsslca, 9 Jan, 2003, trustedCertEntry,
Certificate fingerprint (MD5): DF:F2:80:73:CC:F1:E6:61:73:FC:F5:42:E9:C5:7C:EE
equifaxsecureebusinessca2, 19 Jul, 2003, trustedCertEntry,
Certificate fingerprint (MD5): AA:BF:BF:64:97:DA:98:1D:6F:C6:08:3A:95:70:33:CA
equifaxsecureebusinessca1, 19 Jul, 2003, trustedCertEntry,
Certificate fingerprint (MD5): 64:9C:EF:2E:44:FC:C6:8F:52:07:D0:51:73:8F:CB:3D
verisignclass2g2ca, 26 Mar, 2004, trustedCertEntry,
Certificate fingerprint (MD5): 2D:BB:E5:25:D3:D1:65:82:3A:B7:0E:FA:E6:EB:E2:E1
thawtepremiumserverca, 13 Feb, 1999, trustedCertEntry,
Certificate fingerprint (MD5): 06:9F:69:79:16:66:90:02:1B:8C:8C:A2:C3:07:6F:3A
gtecybertrustca, 10 May, 2002, trustedCertEntry,
Certificate fingerprint (MD5): C4:D7:F0:B2:A3:C5:7D:61:67:F0:04:CD:43:D3:BA:58
entrustglobalclientca, 9 Jan, 2003, trustedCertEntry,
Certificate fingerprint (MD5): 9A:77:19:18:ED:96:CF:DF:1B:B7:0E:F5:8D:B9:88:2E
starfieldclass2ca, 12 Jan, 2005, trustedCertEntry,
Certificate fingerprint (MD5): 32:4A:4B:BB:C8:63:69:9B:BE:74:9A:C6:DD:1D:46:24
verisignclass1g3ca, 26 Mar, 2004, trustedCertEntry,
Certificate fingerprint (MD5): B1:47:BC:18:57:D1:18:A0:78:2D:EC:71:E8:2A:95:73
verisignclass3ca, 27 Oct, 2003, trustedCertEntry,
Certificate fingerprint (MD5): 10:FC:63:5D:F6:26:3E:0D:F3:25:BE:5F:79:CD:67:67
thawteserverca, 13 Feb, 1999, trustedCertEntry,
Certificate fingerprint (MD5): C5:70:C4:A2:ED:53:78:0C:C8:10:53:81:64:CB:D0:1D
entrustgsslca, 9 Jan, 2003, trustedCertEntry,
Certificate fingerprint (MD5): 9D:66:6A:CC:FF:D5:F5:43:B4:BF:8C:16:D1:2B:A8:99
geotrustglobalca, 19 Jul, 2003, trustedCertEntry,
Certificate fingerprint (MD5): F7:75:AB:29:FB:51:4E:B7:77:5E:FF:05:3C:99:8E:F5
verisignclass1g2ca, 26 Mar, 2004, trustedCertEntry,
Certificate fingerprint (MD5): DB:23:3D:F9:69:FA:4B:B9:95:80:44:73:5E:7D:41:83
equifaxsecureca, 19 Jul, 2003, trustedCertEntry,
Certificate fingerprint (MD5): 67:CB:9D:C0:13:24:8A:82:9B:B2:17:1E:D1:1B:EC:D4
baltimorecybertrustca, 10 May, 2002, trustedCertEntry,
Certificate fingerprint (MD5): AC:B6:94:A5:9C:17:E0:D7:91:52:9B:B1:97:06:A6:E4
verisignclass2ca, 27 Oct, 2003, trustedCertEntry,
Certificate fingerprint (MD5): B3:9C:25:B1:C3:2E:32:53:80:15:30:9D:4D:02:77:3E
entrust2048ca, 9 Jan, 2003, trustedCertEntry,
Certificate fingerprint (MD5): BA:21:EA:20:D6:DD:DB:8F:C1:57:8B:40:AD:A1:FC:FC
verisignserverca, 29 Jun, 1998, trustedCertEntry,
Certificate fingerprint (MD5): 74:7B:82:03:43:F0:00:9E:6B:B3:EC:47:BF:85:A5:93
cacertroot3, 6 Jan, 2006, trustedCertEntry,
Certificate fingerprint (MD5): 73:3F:35:54:1D:44:C9:E9:5A:4A:EF:51:AD:03:06:B6
cacertroot1, 6 Jan, 2006, trustedCertEntry,
Certificate fingerprint (MD5): A6:1B:37:5E:39:0D:9C:36:54:EE:BD:20:31:46:1F:6B
verisignclass1ca, 26 Mar, 2004, trustedCertEntry,
Certificate fingerprint (MD5): 97:60:E8:57:5F:D3:50:47:E5:43:0C:94:36:8A:B0:62
gtecybertrustglobalca, 10 May, 2002, trustedCertEntry,
Certificate fingerprint (MD5): CA:3D:D3:68:F1:03:5C:D0:32:FA:B8:2B:59:E8:5A:DB
baltimorecodesigningca, 10 May, 2002, trustedCertEntry,
Certificate fingerprint (MD5): 90:F5:28:49:56:D1:5D:2C:B0:53:D4:4B:EF:6F:90:22
thawtepersonalfreemailca, 13 Feb, 1999, trustedCertEntry,
Certificate fingerprint (MD5): 1E:74:C3:86:3C:0C:35:C5:3E:C2:7F:EF:3C:AA:3C:D9
gtecybertrust5ca, 10 May, 2002, trustedCertEntry,
Certificate fingerprint (MD5): 7D:6C:86:E4:FC:4D:D1:0B:00:BA:22:BB:4E:7C:6A:8E
verisignclass3g3ca, 26 Mar, 2004, trustedCertEntry,
Certificate fingerprint (MD5): CD:68:B6:A7:C7:C4:CE:75:E0:1D:4F:57:44:61:92:09
godaddyclass2ca, 12 Jan, 2005, trustedCertEntry,
Certificate fingerprint (MD5): 91:DE:06:25:AB:DA:FD:32:17:0C:BB:25:17:2A:84:67
equifaxsecureglobalebusinessca1, 19 Jul, 2003, trustedCertEntry,
Certificate fingerprint (MD5): 8F:5D:77:06:27:C4:98:3C:5B:93:78:E7:D7:7D:9B:CC

So, now that I have it here… I’m wondering why I cannot connect. The only clue I get is when I kill the process of the connection_manager, pidgin gives me a SSL Handshake Failed message, but I really don’t get much anything else to help me out. I get nothing on the XMPP console because I never successfully connect of course, so I don’t know where the disconnect may be… if its syntax or not.

3

So I enabled debugging, and here’s the stuff I got:

2008.09.30 04:57:06 IQ stanza of type RESULT was discarded:
2008.09.30 04:57:07
javax.net.ssl.SSLHandshakeException: SSL handshake failed.
at org.apache.mina.filter.SSLFilter.messageReceived(SSLFilter.java:416)
at org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived(Ab stractIoFilterChain.java:299)
at org.apache.mina.common.support.AbstractIoFilterChain.access$1100(AbstractIoFilt erChain.java:53)
at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageReceive d(AbstractIoFilterChain.java:648)
at org.apache.mina.filter.executor.ExecutorFilter.processEvent(ExecutorFilter.java :239)
at org.apache.mina.filter.executor.ExecutorFilter$ProcessEventsRunnable.run(Execut orFilter.java:283)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java: 885)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
at org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:51)
at java.lang.Thread.run(Thread.java:619)
Caused by: javax.net.ssl.SSLHandshakeException: no cipher suites in common
at com.sun.net.ssl.internal.ssl.Handshaker.checkThrown(Handshaker.java:938)
at com.sun.net.ssl.internal.ssl.SSLEngineImpl.checkTaskThrown(SSLEngineImpl.java:4 65)
at com.sun.net.ssl.internal.ssl.SSLEngineImpl.writeAppRecord(SSLEngineImpl.java:10 64)
at com.sun.net.ssl.internal.ssl.SSLEngineImpl.wrap(SSLEngineImpl.java:1036)
at javax.net.ssl.SSLEngine.wrap(SSLEngine.java:452)
at org.apache.mina.filter.support.SSLHandler.handshake(SSLHandler.java:515)
at org.apache.mina.filter.support.SSLHandler.messageReceived(SSLHandler.java:306)
at org.apache.mina.filter.SSLFilter.messageReceived(SSLFilter.java:392)
… 9 more
Caused by: javax.net.ssl.SSLHandshakeException: no cipher suites in common
at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:174)
at com.sun.net.ssl.internal.ssl.SSLEngineImpl.fatal(SSLEngineImpl.java:1366)
at com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Handshaker.java:189)
at com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Handshaker.java:177)
at com.sun.net.ssl.internal.ssl.ServerHandshaker.chooseCipherSuite(ServerHandshake r.java:638)
at com.sun.net.ssl.internal.ssl.ServerHandshaker.clientHello(ServerHandshaker.java :425)
at com.sun.net.ssl.internal.ssl.ServerHandshaker.processMessage(ServerHandshaker.j ava:139)
at com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Handshaker.java:516)
at com.sun.net.ssl.internal.ssl.Handshaker$1.run(Handshaker.java:458)
at java.security.AccessController.doPrivileged(Native Method)
at com.sun.net.ssl.internal.ssl.Handshaker$DelegatedTask.run(Handshaker.java:875)
at org.apache.mina.filter.support.SSLHandler.doTasks(SSLHandler.java:686)
at org.apache.mina.filter.support.SSLHandler.handshake(SSLHandler.java:486)
… 11 more
2008.09.30 04:57:20 IQ stanza of type RESULT was discarded:

This was after doing some working with keytool for both truststore and keystore.

I flushed both the intermediate certificate that I had and the certificate I first imported. I then converted my certificate and key to DER formats from PEM. I downloaded ImportKey.java and ImportKey.class and proceeded to import the cert/key combination from /opt/openfire/resources/security/ directory. The message showed success, so I thought I was good, checked the keystore and noticed no certs, so I imported the DER format of the cert (keytool -import -keystore keystore -alias servepath.com -file servepath.com.crt.der). Fired up my connection manager and I show a connection to my primary server, but again my client cannot connect to the connection manager server. I’m hoping what I’m missing is stupidly obvious, but I am juggling too many things and arrived at this dead end.

Maybe i need to int vacation(struct myself);

4

Hey Brian,

Are you trying to secure the connection between the CMs and Openfire? First off, I would ask why is it that you need to use CMs on top of Openfire? Since a single Openfire instance scaled from 5K to 250K we stopped recommending using CMs for “regular” scalability needs. We are now recommending CMs if your servers are under really heavy load so using CMs is a way to reduce the CPU and I/O burden. Having said that the second question is why use TLS between CMs and Openfire? If both machines are under a protected network then you might want to reconsider using TLS since using TLS is an expensive feature. IOW, if you still need to use CMs and you need secured connections between them then make sure to provide RSA and DSA certs (that should take care of the cipher issues).

Regards,

– Gato

5

The CMs take care of the lack of clustering availability with an architectural need for local and remote team members. Effectively they’re doing nothing other than providing a local system to my remote vendors to connect to which extends the current jabber domain to them via the CM. I also wanted the client to have the ability to talk to one another locally through their local CM, instead of every time talking to the guy across the hall from him the packet traffic traveling around the world.

Basically, we have the local system which will function as the primary server and auth up to our AD infrastructure. The CMs will be placed in three remote sites for use by our vendors. I want connectivity between all clients and the AD server to be secured full and through. I don’t want any insecure connections, and my understanding from the SSL documentation was that its possible.

The trouble is… how?

The documentation is very vague on how this happens, or what are the requrements. Certificates are auth’d by one method, and that’s typically RSA. I have a wildcard certificate for our domain; so I 've tried importing that (in PEM format) directly to the keystore; and the intermediate certificate to the truststore. This doesn’t appear to work correctly as I’m getting handshake errors. Then I remembered from other documentation that I need to import the certificate and key in DER format, so I downloaded ImportKey.java and ImportKey.class, converted the key and cert, imported using the ImportKey method, and then specified the keystore; server wouldn’t run.

So I’m at a little bit of a loss as to why the SSL documentation isn’t adding up. I’m also getting frequent disconnects… “You have lost your connection to the server due to item-not-found” - ??? I can’t have frequent connects/disconnects.

6

Hey Brian,

I think that there could be a misunderstanding about how CMs work. Lets assume that you have an Openfire server running in the US, a CM running in Rome and another CM in Japan. Each CM will open a socket connection to Openfire. Lets now imagine that we have 2 users connected from Japan (J1 and J2) and 2 users from Rome (R1 and R2). If J1 sends a message to J2 then J1’s client will send the message to the CM at Japan. The CM will then forward the message to the Openfire server in the US and the Openfire server will then send a message to the CM in Japan so that it can forward the message to J2. As you can imagine a conversation between J1 and R1 would imply this flow: J1 --> CM (Japan) --> Openfire --> CM (Rome) --> R1.

Having said that, I think that what you need in order to have local network traffic between local users is to run different Openfire installations in each place. And then rely on server-2-server (using TLS) to secure communication between servers/countries/places. BTW, CMs are not a way to workaround clustering. If the Openfire server goes down then the entire XMPP service will be down.

Regards,

– Gato

7

Shouldn’t communication between local CMs remain within that CM instead of going all the way back to the US?

i.e. vendor1 in bangalore can communicate with other members of that team, connected to that local CM with all traffic staying inside that CM?

And yes, I know the major server cannot go down - unfortunately Oracle Coherence charges about $20k to license the now dead clustering.jar plugin (what a rip)… I think we’ll have to work in-house to develop our own clustering java solution to achieve redundancy and domain expansion across multiple openfire installations.

8

Hey Brian,

CMs were created for dealing with all the burden of IO network activity and at the same time be 100% dumb. They are just proxies that will forward traffic between clients and XMPP servers. They do not have any of the logic that lives on the server. For instance, if you have a PacketInterceptor that is preventing some people from communicating (aka ethical walls) then your CM will skip that and let people just talk. Auditing, logging, permission, etc. are many other things that would get lost with that architecture. Having said that, you are welcome to add a short-circuit to the CM and make it optional.

You are not the first one interested in clustering and willing to implement it. In fact, some community members went ahead and implemented a proof of concept using an open source clustering solution and it worked fine with Openfire. I would recommend joining all the effort from many community members and move on. I’m open to answer questions or make recommendations in this initiative.

Regards,

– Gato

9

So there’s still a connection level problem between my CM and the server, below are logs:

debug.log
2008.10.16 01:26:08 CM - Trying to connect to server at jabber2.servepath.com:5262
2008.10.16 01:26:09 CM - Plain connection to server at jabber2.servepath.com:5262 successful
2008.10.16 01:26:11 OS - Sent handshake to host: servepath.com id: e7f616dc
2008.10.16 01:26:11 OS - Handshake was SUCCESSFUL with host: servepath.com id: e7f616dc
2008.10.16 01:26:22 IQ stanza of type RESULT was discarded:
2008.10.16 01:27:35 Error delivering packet
org.jivesoftware.multiplexer.net.SocketConnection@134f69a socket: Socket[addr=jabber2.servepath.com/69.59.136.177,port=5262,localport=56361]
java.net.SocketException: Broken pipe
at java.net.SocketOutputStream.socketWrite0(Native Method)
at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)
at java.net.SocketOutputStream.write(SocketOutputStream.java:136)
at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:202)
at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:272)
at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:276)
at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:122)
at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:212)
at java.io.BufferedWriter.flush(BufferedWriter.java:236)
at org.jivesoftware.multiplexer.net.SocketConnection.deliver(SocketConnection.java :529)
at org.jivesoftware.multiplexer.ConnectionWorkerThread.deliver(ConnectionWorkerThr ead.java:497)
at org.jivesoftware.multiplexer.task.RouteTask.run(RouteTask.java:33)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java: 885)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
at java.lang.Thread.run(Thread.java:619)
at org.jivesoftware.multiplexer.ConnectionWorkerThread.run(ConnectionWorkerThread. java:457)
2008.10.16 01:27:37 CM - Trying to connect to server at jabber2.servepath.com:5262
2008.10.16 01:27:37 CM - Plain connection to server at jabber2.servepath.com:5262 successful
2008.10.16 01:27:38 OS - Sent handshake to host: servepath.com id: 4fd65c45
2008.10.16 01:27:38 OS - Handshake was SUCCESSFUL with host: servepath.com id: 4fd65c45
2008.10.16 01:27:40 IQ stanza of type ERRROR was discarded:
2008.10.16 01:27:54 IQ stanza of type RESULT was discarded:
2008.10.16 01:28:01 Error delivering packet
org.jivesoftware.multiplexer.net.SocketConnection@6d0040 socket: Socket[addr=jabber2.servepath.com/69.59.136.177,port=5262,localport=52461]
java.net.SocketException: Broken pipe
at java.net.SocketOutputStream.socketWrite0(Native Method)
at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)
at java.net.SocketOutputStream.write(SocketOutputStream.java:136)
at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:202)
at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:272)
at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:276)
at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:122)
at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:212)
at java.io.BufferedWriter.flush(BufferedWriter.java:236)
at org.jivesoftware.multiplexer.net.SocketConnection.deliver(SocketConnection.java :529)
at org.jivesoftware.multiplexer.ConnectionWorkerThread.deliver(ConnectionWorkerThr ead.java:497)
at org.jivesoftware.multiplexer.task.RouteTask.run(RouteTask.java:33)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java: 885)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
at java.lang.Thread.run(Thread.java:619)
at org.jivesoftware.multiplexer.ConnectionWorkerThread.run(ConnectionWorkerThread. java:457)
2008.10.16 01:28:01 CM - Trying to connect to server at jabber2.servepath.com:5262
2008.10.16 01:28:01 CM - Plain connection to server at jabber2.servepath.com:5262 successful
2008.10.16 01:28:02 OS - Sent handshake to host: servepath.com id: e894724a
2008.10.16 01:28:02 OS - Handshake was SUCCESSFUL with host: servepath.com id: e894724a
2008.10.16 01:28:03 IQ stanza of type ERRROR was discarded:
2008.10.16 01:28:18 IQ stanza of type RESULT was discarded:
2008.10.16 01:32:41 Error delivering raw text
org.jivesoftware.multiplexer.net.SocketConnection@1722456 socket: Socket[addr=jabber2.servepath.com/69.59.136.177,port=5262,localport=52462]
java.net.SocketException: Broken pipe
at java.net.SocketOutputStream.socketWrite0(Native Method)
at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)
at java.net.SocketOutputStream.write(SocketOutputStream.java:136)
at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:202)
at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:272)
at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:276)
at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:122)
at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:212)
at java.io.BufferedWriter.flush(BufferedWriter.java:236)
at org.jivesoftware.multiplexer.net.SocketConnection.deliverRawText(SocketConnecti on.java:570)
at org.jivesoftware.multiplexer.ServerSurrogate$1.run(ServerSurrogate.java:97)

My users are complaining that they’re getting disconnected frequently after a short time with a message from Spark of ‘item not found’ and here’s the matching line:

error
2008.10.16 01:39:11 IQ stanza of type ERRROR was discarded:

what would be causing this problem?

I’m also wondering why they cannot connect via SSL encryption on port 5223 as specified by info.log:

info.log
2008.10.16 01:26:12 Started plain (unencrypted) socket on port: 5222
2008.10.16 01:26:13 Started SSL (encrypted) socket on port: 5223
2008.10.16 01:26:13 Connection Manager 3.6.0 [16 Oct, 2008 1:26:13 AM]

error.log
Error while negotiating TLS
java.lang.IllegalArgumentException: Unknown filter name:org.apache.mina.common.ExecutorThreadModel
at org.apache.mina.common.support.AbstractIoFilterChain.checkOldName(AbstractIoFil terChain.java:212)
at org.apache.mina.common.support.AbstractIoFilterChain.addAfter(AbstractIoFilterC hain.java:132)
at org.jivesoftware.multiplexer.net.NIOConnection.startTLS(NIOConnection.java:335)
at org.jivesoftware.multiplexer.net.StanzaHandler.negotiateTLS(StanzaHandler.java: 259)
at org.jivesoftware.multiplexer.net.StanzaHandler.process(StanzaHandler.java:149)
at org.jivesoftware.multiplexer.net.ConnectionHandler.messageReceived(ConnectionHa ndler.java:129)
at org.apache.mina.common.support.AbstractIoFilterChain$TailFilter.messageReceived (AbstractIoFilterChain.java:570)
at org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived(Ab stractIoFilterChain.java:299)
at org.apache.mina.common.support.AbstractIoFilterChain.access$1100(AbstractIoFilt erChain.java:53)
at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageReceive d(AbstractIoFilterChain.java:648)
at org.apache.mina.filter.codec.support.SimpleProtocolDecoderOutput.flush(SimplePr otocolDecoderOutput.java:58)
at org.apache.mina.filter.codec.ProtocolCodecFilter.messageReceived(ProtocolCodecF ilter.java:185)
at org.apache.mina.common.support.AbstractIoFilterChain.callNextMessageReceived(Ab stractIoFilterChain.java:299)
at org.apache.mina.common.support.AbstractIoFilterChain.access$1100(AbstractIoFilt erChain.java:53)
at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageReceive d(AbstractIoFilterChain.java:648)
at org.apache.mina.filter.executor.ExecutorFilter.processEvent(ExecutorFilter.java :239)
at org.apache.mina.filter.executor.ExecutorFilter$ProcessEventsRunnable.run(Execut orFilter.java:283)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java: 885)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
at java.lang.Thread.run(Thread.java:619)

2008.10.16 01:41:02 IQ stanza of type RESULT was discarded:
2008.10.16 01:41:02 IQ stanza of type RESULT was discarded:

Why can’t it negotiate TLS? are the keystore/truststores required? I had problems getting these setup properly with our SSL certs before.

10

Hi Brian,

I wonder why you want to use the old SSL methods for clients.

You may want to use TLS / port 5222 and the same certificates and settings as Openfire uses. JM-791 is a known issue, so a “lock” will not be displayed in the Openfire console.

There’s also JM-835 - it may cause that the sequence of messages is not kept, especially if messages are sent very fast (offline messages or entering a MUC).

I did not look at the source code, but I think that the CM connection to Openfire port 5262 is TLS encrypted - otherwise the jive.xmpp.server.certificate section wouldl make little sense in the conf file of the CM.

LG

11

Thanks.

Through wireshark I did see that the connection was encrypted from the client to the CM, and couldn’t read anything. I just would feel better if they made sure the security traveled the whole length.

Due to my paranoid nature this wasn’t going to fly; everyone now connects directly to our infrastructure and we’ve done away with local CMs in offices. Thank you for the JM’s, I have something to watch.

12

I went after CM for the exact same reason, not for clustering, but to provide acces points in multiple locations that fit in with our security model, and without directly exposing our primary Openfire server.

I also was able to get SSL working with relative ease from client -> CM, and in my case SSL also did not work from CM -> OF. Perhaps there are settings on the Openfire side to enable this, but a few “openssl s_client” calls revealed that the listener on OF accepted neither SSL nor TLS. CM is really handy, it would be nice if the SSL was fixed.

I should add that while my CM is rejecting non-TLS connections on 5222, there is no obvious way to explicitly disable non-SSL connections

Brian: just in case you revisit this issue… I stuck with CM, but I just ran it through stunnel to the OF server. It’s another moving part, but it works well and now we’re crypto end-to-end…

-Mike

13

nice move on the stunnel, but for international connectivity to infrastructure that isn’t as sound as the united states, I don’t want to have repeated monitoring to keep from being woken up every 4 hours on my sunday nights =)

It would be nice if they fully fixed the CM SSL/TLS functions and more explicitly defined the functions and settings; but I’m a user and I’m not going to gripe. I am, however, going to explore a work-around to the $40k for the enterprise clustering plugin.

14

For the “item-not-found” thing, I just made a patch and posted to http://community.igniterealtime.org/thread/42142

Wish this be help you.