search

w3c / wot-security

a repo exclusively for security to better manage issues and security considerations for WoT
https://w3c.github.io/wot-security/
18 stars 22 forks source link

Review security architecture of OpenHAB #187

Open mmccool opened 3 years ago

mmccool commented 3 years ago

see in general if this is consistent with WoT https://www.openhab.org/

mmccool commented 3 years ago

@OliverPfaff to review, trying to answer questions raised in the "template" defined in this issue: https://github.com/w3c/wot-security/issues/191

OliverPfaff commented 3 years ago

abc

OliverPfaff commented 3 years ago

With respect to security, the openHab documentation appears to be scattered and fuzzy in parts. The parts with a more clear description appear to suffer from a low level of elaboration. This creates the impression that security is no major prio in openHab development.

Here is my reading:

  1. "Thing-to-Thing"-security in openHab: openHab uses the term "channel" to denote actual operational exchanges within the system. I did not find information about "channel" security and guess that openHab anticipates a default deployment where unprotected plaintext exchanges happen between things within a dedicated/segregated local network. I.e. security between things seems to remain unelaborated (beyond making that a concern of the network that is being utilized). However this appears to be implicit i.e. the Thing-to-Thing security aspect of openHab security appears to be not elaborated at all (its probably fair to descope this aspect but a descopting of this should be explicit)

  2. "User-to-openHab system"-security: is elaborated in https://www.openhab.org/docs/installation/security.html and distinguishes resp. supports:

    • Commandine console: this means can (shall) use SSH. In contrast to HTTP-over-TLS for "user-to-openHab system"-security, the SSH flavor supports client resp. user authentication (hence gets around the wrap it again with virtual private networking techniques)
    • HTTP: this means must use TLS (subject to an embedded Web server [Jetty]). But the employed TLS security model is pretty naive and seems to utilize bad practices such as self-signed EE certs (for the embedded Web server) for TLS server authentication. It does not support TLS client authentication as well as client or user authentication on the HTTP layer (layer 7a) or inside HTTP payload (layer 7b). For that reason another protecttion layer is needed to protect the HTTP-over-TLS responder. That is suggested to be done using virtual private network techniques
mmccool commented 3 years ago

Content moved to https://github.com/w3c/wot-security/blob/master/background/hubs.md, further work should be against that file. Will leave open and review next week, in case @OliverPfaff has any further input.