Problem with openjdk version "11.0.8"

Hallo,
I wanted to report a strange issue faced installing mendelson_opensource_as2_1.1b57 on CENTOS 8.
I first installed openjdk 11 via yum command. This resulted in the installation of openjdk version "11.0.8 2020-07-14 LTS".
After that, the setup of Mendelson goes fine, but the client GUI does not start. A window appears saying "Connecting to localhost/127...." and stays like that forever.
I can telnet to port 1235 locally and from remote without issues, but the JAVA client seems unable to connect.

I therefore installed an earlier version of openjdk ("11.0.1" 2018-10-16) and with that I could launch mendelson without issues.
I don't know if someone has a better idea of what could be the cause, but hopefully this workaround can help other people for now.

Forum
AS2

Comments

Profile picture for user service

fromano,

the client-server connection of the mendelson_opensource_as2_1.1b57 tries to perform a TLSv1 handshake. This is no longer permitted under CentOS. We changed the handshake to TLSv1.2 in the commercial version already. Perhaps there is a setting in CentOS to allow TLSv1?

Regards

Thank you for the reply, however the issue does not seem to be related to CENTOS in particular, but with its (current) default java 11 version.
When I switched from using openJDK version "11.0.8 2020-07-14 LTS" to openJDK version "11.0.1 2018-10-16", the Mendelson client started working.

To make it work I only changed the path of the java command in the .sh file to point to the older version, so everything else was exactly the same.
I also checked that both Java versions had jce unlimited strength enabled (in any case I think with latest versions of Java that comes by default)

Profile picture for user service

fromano,

please have a look at

{JRE_HOME}/lib/security/java.security

You should always find the line
jdk.tls.disabledAlgorithms=SSLv3

..but is there also an entry like
jdk.tls.disabledAlgorithms=TLSv1
?

Regards

In reply to by service

Hi,
There is no such file in either of the JDKs I installed (both the one working and the one not working):

ll ~/jdk-11.0.1/lib/security/
-rw-rw-r--. 1 1253 Oct 17 21:43 blacklisted.certs
-rw-rw-r--. 1 102883 Oct 17 21:43 cacerts
-rw-rw-r--. 1 8815 Oct 17 21:43 default.policy
-rw-rw-r--. 1 234959 Oct 17 21:43 public_suffix_list.dat

ll /usr/lib/jvm/java-11-openjdk-11.0.8.10-0.el8_2.x86_64/lib/security/
-rw-r--r--. 1 root root 1253 Jul 16 16:54 blacklisted.certs
lrwxrwxrwx. 1 root root 21 Jul 16 17:06 cacerts -> /etc/pki/java/cacerts
-rw-r--r--. 1 root root 9401 Jul 16 16:54 default.policy
-rw-r--r--. 1 root root 233897 Jul 16 16:54 public_suffix_list.dat

That file seems located in {JRE_HOME}/conf/security
If I grep for "jdk.tls.disabledAlgorithm", I obtain the following, which seems the same for both versions:

grep -ir jdk.tls.disabledAlgorithm ~/jdk-11.0.1
Binary file ~/jdk-11.0.1/lib/modules matches
~/jdk-11.0.1/conf/security/java.security:# jdk.tls.disabledAlgorithms=MD5, SSLv3, DSA, RSA keySize < 2048
~/jdk-11.0.1/conf/security/java.security:jdk.tls.disabledAlgorithms=SSLv3, RC4, DES, MD5withRSA, DH keySize < 1024, \
~/jdk-11.0.1/conf/security/java.security:# jdk.tls.disabledAlgorithms property or the

grep -ir jdk.tls.disabledAlgorithm /usr/lib/jvm/java-11-openjdk-11.0.8.10-0.el8_2.x86_64/
Binary file /usr/lib/jvm/java-11-openjdk-11.0.8.10-0.el8_2.x86_64/lib/modules matches
grep -ir jdk.tls.disabledAlgorithm /usr/lib/jvm/java-11-openjdk-11.0.8.10-0.el8_2.x86_64/conf/security/java.security
# jdk.tls.disabledAlgorithms=MD5, SSLv3, DSA, RSA keySize < 2048
jdk.tls.disabledAlgorithms=SSLv3, RC4, DES, MD5withRSA, DH keySize < 1024, \
# jdk.tls.disabledAlgorithms property or the
# certificates such as jdk.tls.disabledAlgorithms or

In reply to by service

CLIENT-LOGOFF EVENT

What I just noticed is that with the 'wrong' java version, the following event is recorded:

21-41-57-249_info_user_client-logoff_18191146748410019793.event

[Event description]
TimestampDescription=Oct 26, 2020, 9:41:57 PM
SeverityDescription=Info
OriginDescription=User
CategoryDescription=Client operation
TypeDescription=Client logoff
ProcessOriginHost=xxxxx
User=
Timestamp=1603744917243
Severity=1
Origin=2
Type=1303
EventId=15757c48-e7cd-45c9-ace5-11985adc800d

[Summary]
Client logoff [null]

[Details]
Client ip: localhost/127.0.0.1:37104
Client process id: null
Details: Exception caught in client-server interface: Improper close state: Status = OK HandshakeStatus = NEED_WRAP
bytesConsumed = 0 bytesProduced = 7 sequenceNumber = 0

whereas with the 'correct' java version, I get this:

21-42-46-812_info_user_client-login-success_7650899640708422240.event

[Event description]
TimestampDescription=Oct 26, 2020, 9:42:46 PM
SeverityDescription=Info
OriginDescription=User
CategoryDescription=Client operation
TypeDescription=Client login (success)
ProcessOriginHost=xxxxx
User=
Timestamp=1603744966811
Severity=1
Origin=2
Type=1301
EventId=e05df9ea-2401-4d08-a00f-67b1502cb6c2

[Summary]
Client login success [admin]

[Details]
Client ip: localhost/127.0.0.1:37144
Client process id: 13775@xxxxx
Client OS: Linux
Details: Authentication successful, user [admin] logged in

These are the 2 sessions (good and bad) taken from wireshark. It seems in the bad one the client does not get to send a "Client Hello".
Hope it helps. For me in any case it is working with the old java version, But if you want more info for your own use, I'll be glad to help.

File attachments

On a Ubuntu 20.04.5 LTS system with openjdk 11.0.17 installed I had the problem described.

I changed /etc/java-11-openjdk/security/java.security from the original line

jdk.tls.disabledAlgorithms=SSLv3, TLSv1, TLSv1.1, RC4, DES, MD5withRSA, \
DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL, \
include jdk.disabled.namedCurves

to:

jdk.tls.disabledAlgorithms=SSLv3, RC4, DES, MD5withRSA, \
DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL, \
include jdk.disabled.namedCurves

i.e. removed (or re-enabled TLSv1 and TLSv1.1).

After this change the X11 GUI worked again.