Problem og løsning ifm. specifik fejlbesked om ugyldig protokol i openHAB ved forbindelse til IHC Controller

[EjvindHald]

Hej

Hvis man forsøger med en ny installation af openHAB primo maj 2021 eller senere, kan man ved integration til IHC Controlleren opleve denne fejlbesked "Protocol is disabled or cipher suites are inappropriate". 

Det skyldes, at IHC Controlleren benytter en ældre standard til kryptering af al kommunikation. Standarden hedder TLSv1.0, og den bliver supporteret stadig færre steder, fordi sikkerhedsniveauet er lavt. I stedet skal man i dag benytte TLSv1.2 eller TLSv1.3, men den understøtter IHC Controlleren ikke. Jeg ved ikke, om det kommer.

I de nyeste Java setup er TLSv1.0 i flere distributioner som default nu ikke en gyldig protokol, og det er årsag til, at man oplever den viste fejlbesked. Løsningsmuligheder på dette problem kan læses her og her.

 

[Astronaut]

14 hours ago, EjvindHald said:

Det skyldes, at IHC Controlleren benytter en ældre standard til kryptering af al kommunikation. Standarden hedder TLSv1.0, og den bliver supporteret stadig færre steder, fordi sikkerhedsniveauet er lavt. I stedet skal man i dag benytte TLSv1.2 eller TLSv1.3, men den understøtter IHC Controlleren ikke. Jeg ved ikke, om det kommer.

Problemet vil kun blive værre med tiden. På et tidspunkt vil LK holde op med at lave nye versioner af IHC controlleren og holde op med at lave software opdateringer. Til den tid vil IHC controlleren progressivt blive mere og mere usikker. Jeg har et ønske om at min IHC controller kører de næste 15 år. Jeg har også et ønske om en begrænset integration mellem min IHC verden og resten af verden. Det hænger ikke sammen med en situation hvor LK ikke opdaterer softwaren i controlleren længere. Allerede i dag gyser jeg ved tanken om at folk sætter IHC controlleren direkte på internettet.

Mine tanker går på om man kunne bygge en IHC Proxy. Dvs. en stump kode der fx. kunne køre på en Raspberry Pi og som for omverden lignede en IHC Controller men sendte alle requests videre til en bagvedliggende IHC controller. På den måde ville controlleren sidde på et netværk hvor den kun kunne snakke med proxyen og hvor proxyen var den eneste der kunne snakke med controlleren.

[Lars Jacobsen]

2 timer siden, Astronaut skrev:

Problemet vil kun blive værre med tiden. På et tidspunkt vil LK holde op med at lave nye versioner af IHC controlleren og holde op med at lave software opdateringer. Til den tid vil IHC controlleren progressivt blive mere og mere usikker. Jeg har et ønske om at min IHC controller kører de næste 15 år. Jeg har også et ønske om en begrænset integration mellem min IHC verden og resten af verden. Det hænger ikke sammen med en situation hvor LK ikke opdaterer softwaren i controlleren længere. Allerede i dag gyser jeg ved tanken om at folk sætter IHC controlleren direkte på internettet.

Mine tanker går på om man kunne bygge en IHC Proxy. Dvs. en stump kode der fx. kunne køre på en Raspberry Pi og som for omverden lignede en IHC Controller men sendte alle requests videre til en bagvedliggende IHC controller. På den måde ville controlleren sidde på et netværk hvor den kun kunne snakke med proxyen og hvor proxyen var den eneste der kunne snakke med controlleren.

Altså en IHC-Captain 

[Astronaut]

15 hours ago, Lars Jacobsen said:

Altså en IHC-Captain

Nej ... jeg vil have en proxy der udstiller controllerens API. Sådan at Home Assistant, OpenHAB, Kaptajnen, LK's IHC App, måske endda IHC Visual opfatter proxyen som en IHC Controller. Kun vi ved at den sender alting videre til en rigtig controller bagved og får den rigtige controller til at lave arbejdet. Proxyens primære opgave er at være opdateret på Java fronten sådan at vi ikke sætter outdatet software på eget net (eller internettet).

En sekundær opgave en proxy ville løse ville være at beskytte IHC Controlleren mod for mange connections. Jeg har set min egen Visual 3 controller stejle da jeg på et tidspunkt kørte med alle ovenstående connections + en ekstra HA connection. Til sidst måtte jeg genstarte controlleren.

[Mikkel Skovgaard]

23 timer siden, Astronaut skrev:

Nej ... jeg vil have en proxy der udstiller controllerens API. Sådan at Home Assistant, OpenHAB, Kaptajnen, LK's IHC App, måske endda IHC Visual opfatter proxyen som en IHC Controller. Kun vi ved at den sender alting videre til en rigtig controller bagved og får den rigtige controller til at lave arbejdet. Proxyens primære opgave er at være opdateret på Java fronten sådan at vi ikke sætter outdatet software på eget net (eller internettet).

En sekundær opgave en proxy ville løse ville være at beskytte IHC Controlleren mod for mange connections. Jeg har set min egen Visual 3 controller stejle da jeg på et tidspunkt kørte med alle ovenstående connections + en ekstra HA connection. Til sidst måtte jeg genstarte controlleren.

Det er relativt nemt at lave ja

[HFW]

På 7.6.2021 at 22:28 , EjvindHald skrev:

Hej

Hvis man forsøger med en ny installation af openHAB primo maj 2021 eller senere, kan man ved integration til IHC Controlleren opleve denne fejlbesked "Protocol is disabled or cipher suites are inappropriate". 

Det skyldes, at IHC Controlleren benytter en ældre standard til kryptering af al kommunikation. Standarden hedder TLSv1.0, og den bliver supporteret stadig færre steder, fordi sikkerhedsniveauet er lavt. I stedet skal man i dag benytte TLSv1.2 eller TLSv1.3, men den understøtter IHC Controlleren ikke. Jeg ved ikke, om det kommer.

I de nyeste Java setup er TLSv1.0 i flere distributioner som default nu ikke en gyldig protokol, og det er årsag til, at man oplever den viste fejlbesked. Løsningsmuligheder på dette problem kan læses her og her.

 

Hej Ejvind jeg syntes det er lidt svært at finde ud af at løse dette problem er det noget i kan sende lidt billeder på hvordan vi løser dette?

[EjvindHald]

I din installation er der en fil, som hedder java.security, og den regulerer al sikkerhedsopsætning i Java. Denne fil er i forskellige foldere afhængig af, om din installation er Windows, Linux, Docker eller noget helt andet. Oplys gerne din type af installation.

I denne fil java.security er der en setting, som hedder 

jdk.tls.disabledAlgorithms=

efterfulgt af mange protokolnavne, som er ugyldige. Hvis TLSv1 er nævnt blandt de ugyldige, skal den fjernes. 

I øvrigt har LK oplyst til mig, at de forventer en opgradering af firmware til HW7 inden årets udgang. I denne firmware vil der være support for TLSv1.2, og @Pauli Anttila har allerede indarbejdet det i binding til OH version 3.1.

[HFW]

På 3.7.2021 at 11:23 , EjvindHald skrev:

I din installation er der en fil, som hedder java.security, og den regulerer al sikkerhedsopsætning i Java. Denne fil er i forskellige foldere afhængig af, om din installation er Windows, Linux, Docker eller noget helt andet. Oplys gerne din type af installation.

I denne fil java.security er der en setting, som hedder 

jdk.tls.disabledAlgorithms=

efterfulgt af mange protokolnavne, som er ugyldige. Hvis TLSv1 er nævnt blandt de ugyldige, skal den fjernes. 

I øvrigt har LK oplyst til mig, at de forventer en opgradering af firmware til HW7 inden årets udgang. I denne firmware vil der være support for TLSv1.2, og @Pauli Anttila har allerede indarbejdet det i binding til OH version 3.1.

hej 

 

jeg køre openhab 3 på en raspberry pi 4 8gb

[EjvindHald]

Jeg kører ikke selv på en raspberry pi, så nedenstående guide er best effort.

1. Hent og installer Putty på https://www.putty.org/
2. Lav en SSH forbindelse til din raspberry pi og login på boksen
3. Prøv denne Linux kommando til at finde folderen med java.security: find / -name java.security
4. Vælg denne folder med cd. Fx. cd /usr/lib/jvm/zulu11-ca-amd64/conf/security
5. Åben en editor og ret filen. Fx. vi java.security
6. Genstart raspberry pi

[bozidar]

hvad har jeg gjort forkert. Min fejler stadig .har fjernet TLSv1

[EjvindHald]

Lav altid en komplet genstart efter disse ændringer for at være sikker på, at de er slået igennem.

Ellers må jeg henvise til openhab forummet, herunder ovenstående links i mit første indlæg. I visse typer installationer skal man åbenbart ændre mere end ét sted, men det er ikke noget, som jeg kender særlig godt.