[SOLVED] OH2 & IHC and Java 1.8

Hi all,

I have decided to build a new OH2 host and got CentOS8 with latest java 1.8.

Somehow neither old IHC1 nor new IHC bindings do not like to connect to IHC contoller (HW version 6.2 and latest FW 2.8.4). It can’t agree on ciphers and denies to connect.

I - as I said - have got latest FW installed, also played a whole day with java.security file to enabe/disable/remove all possible combinations of ciphers however it still print every second this message:

2020-01-11 20:48:36.224 [DEBUG] [ding.ihc.internal.handler.IhcHandler] - Connecting to IHC / ELKO LS controller [hostname='10.x.y.z', username='xxx'].
2020-01-11 20:48:36.225 [DEBUG] [ab.binding.ihc.internal.ws.IhcClient] - Opening connection
2020-01-11 20:48:36.225 [DEBUG] [c.internal.ws.http.IhcConnectionPool] - Initialize SSL context
2020-01-11 20:48:36.225 [DEBUG] [ws.services.IhcAuthenticationService] - Authenticate
2020-01-11 20:48:36.225 [TRACE] [.ihc.internal.ws.http.IhcHttpsClient] - Send query (url=https://10.1.1.21/ws/AuthenticationService, connectionPool=371634976, clientId=1075504935 requestId=0, timeout=5000, headers=[content-type: text/xml]): <?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
 <soapenv:Body>
  <authenticate1 xmlns="utcs">
   <password>yyy</password>
   <username>xxx</username>
   <application>treeview</application>
  </authenticate1>
 </soapenv:Body>
</soapenv:Envelope>
2020-01-11 20:48:36.227 [TRACE] [.ihc.internal.ws.http.IhcHttpsClient] - Exception occured (connectionPool=371634976, clientId=1075504935 requestId=0, in PT0.001S): No appropriate protocol (protocol is disabled or cipher suites are inappropriate)
2020-01-11 20:48:36.227 [DEBUG] [ding.ihc.internal.handler.IhcHandler] - Can't open connection to controller javax.net.ssl.SSLHandshakeException: No appropriate protocol (protocol is disabled or cipher suites are inappropriate)
2020-01-11 20:48:37.227 [DEBUG] [ab.binding.ihc.internal.ws.IhcClient] - Closing connection
2020-01-11 20:48:37.228 [DEBUG] [ab.binding.ihc.internal.ws.IhcClient] - Connection closed

It might be something very simple and I really appreciate your help guys ! @pauli_anttila

IHC / ELKO controllers supports only TLSv1 and RSA cipher suites based on SHA1 message authentication (not sure about latest FW versions). SHA1 is nowadays marked as weak, so maybe that’s disabled on your system.

You could use e.g. WireShark to see more details about the TLS handshake and/or add “-Djavax.net.debug=all” option to enable Java debugs.

Enabled debugging. It says Ignoring disabled protocol: TLSv1 but I can’t enable it :frowning:

Also - neither nmap not other SSL tools can list any of chiphers enabled on controler… Very strange…

Jan 13 10:47:44 openhab2 karaf[25900]: trigger seeding of SecureRandom
Jan 13 10:47:44 openhab2 karaf[25900]: done seeding SecureRandom
Jan 13 10:47:44 openhab2 karaf[25900]: Allow unsafe renegotiation: false
Jan 13 10:47:44 openhab2 karaf[25900]: Allow legacy hello messages: true
Jan 13 10:47:44 openhab2 karaf[25900]: Is initial handshake: true
Jan 13 10:47:44 openhab2 karaf[25900]: Is secure renegotiation: false
Jan 13 10:47:44 openhab2 karaf[25900]: Ignoring disabled protocol: TLSv1
Jan 13 10:47:44 openhab2 karaf[25900]: OH-thingHandler-1, handling exception: javax.net.ssl.SSLHandshakeException: No appropriate protocol (protocol is disabled or cipher suites are inappropriate)
Jan 13 10:47:45 openhab2 karaf[25900]: OH-thingHandler-1, SEND TLSv1.2 ALERT:  fatal, description = handshake_failure
Jan 13 10:47:45 openhab2 karaf[25900]: OH-thingHandler-1, WRITE: TLSv1.2 Alert, length = 2
Jan 13 10:47:45 openhab2 karaf[25900]: [Raw write]: length = 7
Jan 13 10:47:45 openhab2 karaf[25900]: 0000: 15 03 03 00 02 02 28                               ......(
Jan 13 10:47:45 openhab2 karaf[25900]: OH-thingHandler-1, called closeSocket()

Any ideas ?

Check JRE/lib/security/java.security file and there jdk.tls.disabledAlgorithms variable

yep … been there … now it’s empty at all :

# grep  jdk.tls.disabledAlgorithms /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.201.b09-2.el8.x86_64/jre/lib/security/java.security
jdk.tls.disabledAlgorithms=
#jdk.tls.disabledAlgorithms=RC4, DES, MD5withRSA, DH keySize < 1024, \
# certificates such as jdk.tls.disabledAlgorithms or

java -version 
openjdk version "1.8.0_201"
OpenJDK Runtime Environment (build 1.8.0_201-b09)
OpenJDK 64-Bit Server VM (build 25.201-b09, mixed mode)

same error :frowning:

JRE/lib/security/java.security file comment says following

Note: This property is currently used by Oracle’s JSSE implementation.
It is not guaranteed to be examined and used by other implementations.

Example:
jdk.tls.disabledAlgorithms=MD5, SSLv3, DSA, RSA keySize < 2048

So maybe this is not used by the openJDK and there is alternative solution. Hopefully Google knows.

OMG!!!

I have managed to fix the problem but it took me 2.5 days of various discoveries :slight_smile: Now I know a lot about ciphers and java security options :smiley:

Anyway - for those who might hit same problem:
CentOS (as well as any other atlest Red Hat distributive) has system wide security settings(/etc/crypto-policies/back-ends/java.config) where OS disables some ciphers on a system level.

So - aparently - one of recent crypto-policies rpm mention TLSv1 and TLSv1.1 as pasr ot jdk.tls.disabledAlgorithms. Then if java.security file contains security.useSystemPropertiesFile=true then this OS setting will be added to the list of disabled ciphers.

So - fo now - remove TLSv1, TLSv1.1 from /etc/crypto-policies/back-ends/java.config and restart openhab

1 Like

Maybe you could add (create PR) note to ihc binding readme file as this problem most probably will impact to other users in the future as well (TLSv1 will be disabled by default on many systems in the future).

Hi Dimka,

So I just ran into the same problem with IHC binding after upgrading. I, however, don’t have this (/etc/crypto-policies/back-ends/java.config) directory. I am running a standard openhabian setup on a raspberry. You wouldn’t happen to know where that file resides do you?

Thanks for your work on this! :slight_smile:

Cheers,

Peter

For anyone else stumbling into this.
/opt/jdk/zulu11.48.21-ca-jdk11.0.11-linux_aarch32hf/conf/security/java.security
is the directory that applies for openhabian configuration.
Now it works!! :slight_smile: