Connection manager to Openfire server SSL connection fails: Unsupported record version Unknown 47.115

Ramshadvp1 · February 12, 2019, 11:23am

While trying to connect to Openfire server directly, no issues are noticed, but while trying to connect to OFS through connection manager when SSL is enabled, we are unable to connect.
We enabled debug mode,and during which

***ServerHelloDone
client-4, WRITE: TLSv1.2 Handshake, length = 880
client-6, fatal error: 80: problem unwrapping net record
javax.net.ssl.SSLException: Unsupported record version Unknown-47.115
%% Invalidated:  [Session-58, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256]
client-6, SEND TLSv1.2 ALERT:  fatal, description = internal_error
client-6, WRITE: TLSv1.2 Alert, length = 2
client-6, called closeInbound()
client-6, fatal: engine already closed.  Rethrowing javax.net.ssl.SSLException: Inbound closed before receiving peer's close_notify: possible truncation attack?

After the error, no more connections are noticed and the system fails without any more logical errors.
Note: Only TLS algortihms are enabled in system. The sasl mechanism in server configured properly.

In the logs, following error messages are noticed:

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(AbstractIoFilterChain.java:299)
	at org.apache.mina.common.support.AbstractIoFilterChain.access$1100(AbstractIoFilterChain.java:53)
	at org.apache.mina.common.support.AbstractIoFilterChain$EntryImpl$1.messageReceived(AbstractIoFilterChain.java:648)
	at org.apache.mina.filter.executor.ExecutorFilter.processEvent(ExecutorFilter.java:239)
	at org.apache.mina.filter.executor.ExecutorFilter$ProcessEventsRunnable.run(ExecutorFilter.java:283)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:51)
	at java.lang.Thread.run(Thread.java:745)
Caused by: javax.net.ssl.SSLException: Unsupported record version Unknown-47.115
	at sun.security.ssl.InputRecord.checkRecordVersion(InputRecord.java:552)
	at sun.security.ssl.EngineInputRecord.bytesInCompletePacket(EngineInputRecord.java:113)
	at sun.security.ssl.SSLEngineImpl.readNetRecord(SSLEngineImpl.java:868)
	at sun.security.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:781)
	at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:624)
	at org.apache.mina.filter.support.SSLHandler.unwrap0(SSLHandler.java:658)
	at org.apache.mina.filter.support.SSLHandler.unwrapHandshake(SSLHandler.java:614)
	at org.apache.mina.filter.support.SSLHandler.handshake(SSLHandler.java:493)
	at org.apache.mina.filter.support.SSLHandler.messageReceived(SSLHandler.java:306)
	at org.apache.mina.filter.SSLFilter.messageReceived(SSLFilter.java:392)
	... 9 more

We tried to check the checkRecordVersion(InputRecord.java:552) method and we found that the ssl version check is being done. Still we were unable to find the nature of the issue.

Any hints on how to solve the issue?

ma1uta · February 12, 2019, 1:56pm

Could you please write version of the java which you use?

Ramshadvp1 · February 13, 2019, 6:01am

I have used JDK 1.8.0.201 as recommended.

Adding the console logs when trying to connect Connection Manager from an XMPP client ( which only enable TLS 1.1 & TLS 1.2)

trigger seeding of SecureRandom
done seeding SecureRandom
Using SSLEngineImpl.
Allow unsafe renegotiation: false
Allow legacy hello messages: true
Is initial handshake: true
Is secure renegotiation: false
Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 for TLSv1
Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 for TLSv1
Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256 for TLSv1
Ignoring unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 for TLSv1
Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 for TLSv1
Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 for TLSv1
Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 for TLSv1
Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 for TLSv1.1
Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 for TLSv1.1
Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256 for TLSv1.1
Ignoring unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 for TLSv1.1
Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 for TLSv1.1
Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 for TLSv1.1
Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 for TLSv1.1
%% No cached client session
update handshake state: client_hello[1]
upcoming handshake states: server_hello[2]
*** ClientHello, TLSv1.2
RandomCookie: GMT: 1549919361 bytes = { 106, 243, 188, 246, 180, 107, 136, 40, 52, 6, 88, 169, 254, 56, 181, 38, 184, 155, 14, 33, 201, 151, 59, 69, 146, 0, 228, 243 }
Session ID: {}
Cipher Suites: [TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, TLS_RSA_WITH_AES_256_CBC_SHA256, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384, TLS_DHE_RSA_WITH_AES_256_CBC_SHA256, TLS_DHE_DSS_WITH_AES_256_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_DSS_WITH_AES_256_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_DSS_WITH_AES_128_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384, TLS_DHE_RSA_WITH_AES_256_GCM_SHA384, TLS_DHE_DSS_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_DSS_WITH_AES_128_GCM_SHA256]
Compression Methods: { 0 }
Extension elliptic_curves, curve names: {secp256r1, secp384r1, secp521r1, sect283k1, sect283r1, sect409k1, sect409r1, sect571k1, sect571r1, secp256k1}
Extension ec_point_formats, formats: [uncompressed]
Extension signature_algorithms, signature_algorithms: SHA512withECDSA, SHA512withRSA, SHA384withECDSA, SHA384withRSA, SHA256withECDSA, SHA256withRSA, SHA256withDSA, SHA1withECDSA, SHA1withRSA, SHA1withDSA
Extension extended_master_secret
Extension renegotiation_info, renegotiated_connection:

client-5, WRITE: TLSv1.2 Handshake, length = 196
client-6, called closeInbound()
client-6, fatal error: 80: Inbound closed before receiving peer’s close_notify: possible truncation attack?
javax.net.ssl.SSLException: Inbound closed before receiving peer’s close_notify: possible truncation attack?
client-6, SEND TLSv1.2 ALERT: fatal, description = internal_error
client-6, WRITE: TLSv1.2 Alert, length = 2
client-6, called closeOutbound()
client-6, closeOutboundInternal()
Connection Worker - 1, WRITE: TLSv1.2 Application Data, length = 182

wroot · February 13, 2019, 7:01am

@ma1uta is new here, so probably doesn’t know that author is probably talking about https://www.igniterealtime.org/projects/openfire/connection_manager.jsp which is 10 years old already, most probably has lots of incompatibilities with current Openfire version, lots of security holes and should probably be retired and removed from the site.

Ramshadvp1 · February 13, 2019, 9:05am

@wroot : Probably my concern was to make it work with Connection Manager(despite of its age).
Any advise from talented resources from this community would be really appreciated!

Ramshadvp1 · February 15, 2019, 5:40am

Any luck for the solutions ?
I am basically looking to work ‘Connection Manager’ with Openfire 3.9.1 with TLS 1.2 environment xmpp clients ?

guus · February 15, 2019, 9:45am

The Connection Manager source code is currently not maintained. To bring this project back in a workable state, a considerable amount of work needs to be performed.

I strongly discourage you to make use of the Connection Manager. It has not had any updates in years, nor has it been tested. It is likely lagging behind in bug and security fixes.

Ramshadvp1 · February 15, 2019, 10:03am

Thank you @guus for the response .
Could you please advise any alternative application in java which can replace Connection Manager , to establish connection with openfire.

guus · February 15, 2019, 10:23am

What type of connection are you looking for? What is the purpose of doing so?

The Connection Manager application can be used to aggregate many client connections, and send that to the ‘core’ Openfire server. An alternative approach to that would be to have a full cluster of Openfire servers, using the hazelcast plugin.

Another approach would be to use the Smack client library, with which many client connections can be established. It’s somewhat of a different approach (as you’d be creating many client sessions), but as Smack is also written in Java, it might be of use to you.

Ramshadvp1 · February 15, 2019, 10:43am

As per the security concern of our major client, they have not allowed to communicate Openfire servers directly for our vendors/contractors.
I am looking for replacing a ‘delegate proxy’ already established on our production environment with Connection manager(CM).
I have used CM because it were meant to restrict or secure redirection to Openfire server port only right.
The configuration (manager.xml ) on CM would be deciding which port must be used to establish connection with openfire server.

guus · February 15, 2019, 10:51am

The argument to have a connection manager for security purposes is flawed. False, even. From a security perspective, using a Connection Manager in the state that it is in today, is a lot worse than using a XMPP client connection.

Note that Openfire can be configured to require TLS encryption for client connections. Alternatively, a BOSH or websocket connection can be used, which offers encryption types similar to that of regular web traffic.

Other solutions can be found in using XMPP federation between both endpoints (use two different Openfire-based XMPP domains, and allow traffic to be exchanged server-to-server), or to put in place a proper proxy, like Metre.

Ramshadvp1 · February 15, 2019, 11:30am

Yup!.

Let me uwrap it now.
We have 200+ physical locations having a single physical machine, which would be acting as a delegate proxy server ( in our case its CM). Each location have few contractors(not more than 5), they are allowed to use this CM server particularly for the location (other locations are not reachable for them).
200+ CM established connection with one Openfire server .
Not expecting 200 Openfire servers integrated with the main Openfire server.

This situation must be handled wisely , can you advise your thoughts on it.

guus · February 15, 2019, 11:58am

I’d all let them use client connections directly to the Openfire server. Alternatively, try to use Metre as a replacement for the Connection Manager. If you worry not about provisioning, you could give each physical location its own Openfire server and run their own XMPP domain, and let users communicate between each-other using federation.