AlexaLazy - Sicherheitsübeelegungen

Begonnen von Sidey, 12 Januar 2019, 10:58:27

Vorheriges Thema - Nächstes Thema

gvzdus

Guten Morgen,

es gab einen Programmierfehler, weswegen ich Accounts löschen musste. Hintergrund sind die Esjay-Probleme.
Inzwischen ist ein Patch auf dem SSH-Proxy eingespielt und die Accounts gelöscht.

Mal die Enduser-Kurzfassung: <UserIDs> (Teil 1 des Reg.-Schlüssels) wurden doppelt vergeben.
Dadurch ist die Zuordnung nicht eindeutig, und es landeten Zugriffe von Amazon im ,,falschen
Kanal" beim falschen User, wo sie dann wegen falschem Bearer-Token erkannt wurden.

Das ist für den Betroffenen, der die Kommandos erhält, natürlich kein Problem - nicht umsonst
hatte ich ja meine User-ID im Security-Thread geschrieben und herzlich dazu eingeladen,
,,auf meinem Raspberry" vorbeizukommen. Allerdings hatte ich dazu eingeladen, und wollte
nicht anderen ebenfalls ungewollt Requests senden. Und problematisch daran ist, dass ja
nicht Test-Requests ankommen, sondern Requests eines anderen. Das Problem sehe ich
also darin, dass Alexa-Requests an den falschen geschickt wurden, der sie in seinem
Logfile ab Version 0.5.8 sehen konnte.

Deswegen habe ich alle Registrierungen, die mit
130E36-
131C16-
131CF4-
1336F8-
13B3D8-
141489-

beginnen, gelöscht.

Bevor ich ausführlich auf den Fehler eingehe und wir im Sicherheitsthread über die Konzeption
diskutieren können, kurz das Vorgehen zum Fixen:

Bei den Betroffenen sollte sich der SSH-Tunnel im Alexa-Device permanent neu starten.
Im Logfile müssten Meldungen wie ,,Your public key is not known, please register first"
erscheinen.

Vorgehen:

  • In FHEM-WEB im Alexa-Device ,,restart" auswählen.
  • Es wird ein neuer Reg.-Key generiert, mit einem jetzt verbesserten Verfahren
  • Skill bei Amazon trennen, und den neu generierten Reg.-Key (,,get alexa proxyKey") eingeben.

Wie ist das passiert?
Das Folgende setzt das Verständnis von des Abschnitts ,,Sicherheitskonzepte" aus dem Wiki
voraus.
Hier findet sich schon der problematische Satz:

Aus Deinem öffentlichen Schlüssel wiederum leitet der Server her: "Das ist definitiv wieder derjenige, der sich damals "registriert" hat". Und an dieser Stelle kann ich auch den ersten Teil des 3-teiligen Registrierungskeys erläutern: Die typischerweise 6-stellige Hex-Zahl am Anfang ist der Java-Hashcode Deines öffentlichen Schlüssel. Sie ist damit sozusagen Deine aus Deinem öffentlichen Schlüssel abgeleitete Benutzer-ID.

Da hätte ich beim Schreiben von ,,6-stellig" misstrauisch werden sollen. Integer sind nun mal 8-stellig. Der HashCode des PublicKey-Objektes ist aber richtig schlecht.
Das muss man nicht Java vorwerfen - der HashCode beim Programmieren hat eine andere Funktion als die Hashes in der Sicherheitstechnik. Teil 1 des Fixes besteht darin,
für neu generierte Reg-Keys eine bessere Hash-Funktion zu verwenden (konkret: https://docs.oracle.com/javase/7/docs/api/java/util/Arrays.html#hashCode(byte[])

Teil 2 des Fehlers ist ein falsches Handling bei Hash-Kollisionen, also wenn bei 2 Public-Keys der gleiche HashCode entsteht. Über den Fall hatte ich beim Programmieren nachgedacht, aber dann doch einen Fehler gemacht.
Wie es gedacht war: Die Registrierung sollte abgelehnt werden. Der 2. hat halt Pech. Ist ohnehin ein Fall, der ausgehend von 32 bit, beim 10.000ten Nutzer mit einer Wahrscheinlichkeit von ca. 1:430.000 auftritt, beim 100. Nutzer mit noch 2 Nullen mehr dran. Bis dahin muss dann was Besseres her.

Tatsächlich habe ich die Funktion bei ,,ssh ... status" (Wie es beim Neustart von alexa-fhem aufgerufen wird) sauber implementiert. Hier wurde auf HashCode / UserID *und* vollständigen PublicKey geprüft. Falsch hingegen ist es beim ,,register" gewesen: Hier wurde einfach der PublicKey gespeichert.

Was bedeutete das konkret?
Benutzer 1 und Benutzer 2 hatten den gleichen HashCode, aus Systemsicht die gleiche UID. Beim Neustart wurde demjenigen, der sich als vorletzter registriert hatte, angezeigt: ,,Du bist nicht registriert". Also wurde ein neuer Registrierungskey generiert, aber wieder auf Basis des gleichen PublicKeys, also mit der gleichen UID im ersten Teil. Damit machte sich dann der Vorletzte wieder zum ersten. Bei Amazon existierten nun zwei Beamer-Tokens: <gemeinsame-uid>-<bearertoken1> und <gemeinsame-uid>-<bearertoken2>. Aus Amazons Sicht natürlich kein Problem: Einfach zwei unterschiedliche Strings. Aus Sicht des SSH-Proxies durchaus ein Problem, weil er ja nun für 2 Nutzer auf die gemeinsame UID guckt, und die Anfragen an den Nutzer schickt, der sich zuletzt verbunden hat.

Wie ist es jetzt behoben?
Erstens durch eine Hashfunktion, die den ganzen 32-Bit-Raum ausnutzt. Simulationsläufe zeigen, dass typischerweise 1 Kollision auf 100.000 Nutzer auftritt.
Zweitens: Wird beim Registrieren eine Kollision erkannt, wird einfach die nächst höhere Nummer vergeben (sofern frei). Und bei jedem Aufbau der SSH-Verbindung, ob ,,-R", ,,register" oder ,,status", wird stets der vollständige PublicKey verifiziert. Die Nummer ist nach Konzeption ja kein großes Geheimnis, sondern muss nur eindeutig sein.

Wie weiter?
Erst einmal ist das Verfahren damit wieder so, wie es sich aus der Beschreibung liest, und mit einem sauberen Kollisionshandling. Über das Verfahren kann man aber trotzdem diskutieren. Mein Anspruch war nicht, dass die vergebene UID für sich ein Geheimnis ist. Ist wie beim Usernamen: Jeder weiß, mit welchem Usernamen ich mich hier im Forum anmelde, nur mein Passwort kennt keiner.

Noch eine Bitte: Lasst uns bitte die Konzeption HIER diskutieren, die ,,Benutzerführung" und Tomatenwürfe in einem der beiden ANDEREN Threads.

Natürlich möchte ich mich an dieser Stelle für den Programmier- und Hash-Anwendungsfehler bei den betroffenen Nutzern entschuldigen! Und bei Esjay für die professionelle Vorgehensweise (Hinweis, Zeit für's Beheben geben) bedanken!

Ablauf war übrigens:

  • Seit gestern, 22:12 Uhr, wurden neue Reg-Schlüssel mit dem guten Verfahren generiert
  • Um 10:40 Uhr habe ich alle o.a. Reg-Keys gelöscht, und den Server restartet, um die bestehenden Verbindungen zu trennen

Loredo

Things happen :-)


Ich kann einen Code Review anbieten (sofern André das nicht ohnehin schon getan hat), weiß aber nicht, wo ich den Quellcode finde.
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

gvzdus

Hat Andre nicht getan (gereviewt). Wir haben über die Architektur viel gesprochen, nicht über den konkreten Code.

Wie Du schon gesehen hast: Es basiert auf Apache Mina (was halbwegs dokumentiert ist), hier auf dem SSHD-Anteil (der quasi null dokumentiert ist).
Ich hab' länger gebraucht, um z.B. zu verstehen: "Wie zum Teufel kriegst Du in der SSH-Kommando-Shell raus, mit welchem PubKey oder von welcher IP der Nutzer kommt?".

Und zumindest mein Ansatz, die nötigen Maven-Komponenten runterzulassen, scheiterte. Weswegen das Ganze im Moment nicht wirklich Github-tauglich ist.

Und drittens ist "nicht aufgeräumt". Da waren historische Ansätze wie "hinterleg' beim "ssh ... register" Deine Email-Adresse" (oder den URL-Pfad, der aufgerufen werden soll). Und ein ursprünglich abweichendes Konzept: Der ssh-Tunnel sollte "blind vertrauen", das Bearer-Token auf dem Server verwaltet werden.

Und viertens kann es z.Zt. nur HTTP/1.0 ohne Keep-Alive, was mir auch peinlich ist.

Das sind die Gründe, den Code z.Zt. nicht "hochzuladen". Ich kann Dir gerne aber einen tarball per Privatnachricht zuschicken.

Loredo

Haha "Nicht aufgeräumt" reicht mir völlig als Begründung, sowas ist mir sympathisch  ;D





Im Grunde wollte ich nur etwas mehr vom Data Flow verstehen, insbesondere ja auch, weil man sich ja im Prinzip erstmal mit jedem beliebigen SSH Schlüssel mit dem Server verbinden kann (im Gegensatz zu einem regulären Server). Ich glaube den Teil der SSH Schlüssel Registrierung hätte ich eher klassisch über HTTP/S gemacht, ich verstehe aber natürlich, dass es so einfacher ist.
Auf dem Server hätte ich jetzt mindestens 2 unterschiedliche Services erwartet, die über Interprozess-Kommunikation o.ä. reden (1x für den Web Service, 1x für den SSH Service; Ein dritter Service wäre vielleicht optional noch da, wenn man die SSH Schlüssel Registrierung per Web gemacht hätte und diese von der Alexa Kommunikation separieren wollte). Micro-Services halt. Weiß auch nicht wieviel Performance das ganze schluckt bzw. wieviele gleichzeitige Nutzer auf einem Server laufen können (sollen).

Unter Umständen kommt dann später ja das Thema Skalierbarkeit, Load-Balancing, Userdatenbank-Sync etc. Aber natürlich braucht's das jetzt noch nicht. Keine Ahnung, wann der oder die Vereinsserver da aussteigen. :-)
Gut ist, dass wir wahrscheinlich eher weniger Benutzer außerhalb von Kerneuropa erwarten können. Sonst wäre das alles jetzt schon ein Thema, sofern man sich um eine gute Antwortzeit für Benutzer beispielsweise aus USA bemühen wollte.






Dann lass erstmal, die aktuelle Dynamik muss man ja nicht direkt unterbrechen. Wenn sich der Staub gelegt hast, mistet du mal etwas aus für eine v2 und dann kann man ja mal schauen die offene Punkte zu adressieren.


Lass dich nicht verwirren :-)




Gruß
Julian
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

gvzdus

Ooch, gerade zu dem Teil, der auf die Nase gefallen ist, nämlich dem entscheidenden "Nutzer identifiziert sich nur über seinen PublicKey, welche Requests schicke ich ihm?" wäre ein kritischer Zweitblick durchaus sinnvoll..
Ich habe da gestern insbesondere den Code so umgestrickt, dass es eben nur einen zentralen Codeblock gibt, wo PublicKey auf UID gemappt wird.

Nein, intern sind da keine Microservices, dass hieße ja Netzwerk und Filedescriptoren. Die Daten wandern "direkt" In-Memory vom Servlet in den SSH-NIO-Channel. Ein Nutzer kostet zwangsläufig einen FileDescriptor und etwas Memory, aber keinen Thread und relativ schlank Memory... Deswegen ist das schon so auf 10.000 Nutzer und mehr je Instanz ausgelegt.

gvzdus

Noch was: Das Alexa-Command-Servlet (Eintrittspunkt für die Aufrufe aus der Lambda-Funktion) ist nicht mehr offen. Es wird auf ein längeres Secret im Header geprüft. Ich könnte die "Komm auf meinen Server"-Challenge jetzt anders aufziehen, und meine UID und mein Bearer-Token disclosen. Mach' ich für Interessenten gerne, dann kommt es per PN. Ich stehe gerade wieder vor einem längeren Test-Zyklus.

gvzdus

Gute Nachricht:
https://securityheaders.com/?q=https%3A%2F%2Fva.fhem.de%2Fregister%2F&hide=on&followRedirects=on - die Header sind hübsch.

Schlechte Nachricht:
ZitatKurzer Hinweis: Ich habe gerade zweimal den SSH-Proxy restartet:
Um 14:54, um eine neue Version zu deployen, die u.a. auch ED25519 kann.
Um 15:04, um das wieder rauszunehmen: Denn diejenigen, die bereits einen ED25519-SSH-Key zufällig haben, haben das sofort begeistert genutzt - aber leider nun mit einem anderen (ED25519)-PublicKey. Und waren damit unregistrierte Neunutzer :-(

Hmmh. Auf Anhieb fallen mir da nur hässliche Lösungen ein, wie man ED25519 aktivieren kann, ohne Nutzer zu ärgern:
"Wenn RSA und ED25519-Key dann, nimm RSA!"? Hässlich, würde helfen.

Loredo

#22

HTTP Server Header: Coole Sache, Parker!  8)


Was SSH angeht:
Der SSH Server bekommt vom Client ja prinzipiell alle ihm zur Verfügung stehenden Client-Keys angeboten und sucht sich davon einen aus, sprich der Server könnte entweder umschwenken oder beide mit der selben internen UID verknüpfen. Und natürlich sollte dabei eine Präferenz vorhanden sein, zu Gunsten von Ed25519. Idealerweise werden (EC)DSA Keys, mit denen ein User ja auch kommen könnte, gar nicht erst akzeptiert.


Ich muss mal schauen, ob ich nicht einer der "Opfer" geworden bin - mein FHEM hat in der letzten Stunde tatsächlich öfter neu gestartet ^^
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

Loredo

Zitat von: gvzdus am 16 Januar 2019, 16:10:34
Deswegen ist das schon so auf 10.000 Nutzer und mehr je Instanz ausgelegt.


Dazu ist mir noch eingefallen, dass es ja nicht nur die Applikation gibt. Genauso müssten TCP Sessions für diese Anzahl von Benutzern permanent offen gehalten werden. Es sind also alle Geräte, die im Netzwerk-Fluss vorhanden sind, damit belastet. Vielleicht nicht ganz unwichtig für solche Dinge wie Firewalls etc (je nachdem, was da noch so dazwischen ist - egal ob Hardware oder Software).
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

gvzdus

Nee, das ist kniffeliger. Die Keys werden ja nicht parallel angeboten, sondern sequentiell. Übrigens bei meiner Default-Config in
der nicht optimalen Reihenfolge:

debug1: Will attempt key: /Users/gvz/.ssh/id_rsa RSA SHA256:9OeeeiW7J7w5sSXXXXXfrT9QSpaF5bezMkk
debug1: Will attempt key: /Users/gvz/.ssh/id_dsa
debug1: Will attempt key: /Users/gvz/.ssh/id_ecdsa
debug1: Will attempt key: /Users/gvz/.ssh/id_ed25519 ED25519 SHA256:G90eGD4W25IaXXXXXXX
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: keyboard-interactive,publickey
debug1: Next authentication method: publickey
debug1: Offering public key: /Users/gvz/.ssh/id_rsa RSA SHA256:9OeeeiW7J7w5sSbEXo+vzVivuoCfrT9QSpaF5bezMkk
debug1: Server accepts key: /Users/gvz/.ssh/id_rsa RSA SHA256:9OeeeiW7J7w5sSbEXo+vzVivuoCfrT9QSpaF5bezMkk
debug1: Authentication succeeded (publickey).


Heißt, ich sehe einen zweiten Key nur dann, wenn ich den ersten ablehne (ohne zu wissen, ob da noch ein zweiter Key wäre).
Das ändert also auf jeden Fall das Verhalten des Proxies.

Eine aufwändigere Methode ist, alexa-fhem so zu ändern, dass er beim Startup die Verfahren durchprobiert bei "ssh ... status", und wenn nur ein Schlüssel registriert ist, sich auf dessen Typ für den Tunnel festnagelt. Dann kann der Nutzer entscheiden, ob und wann er migriert.

Loredo

Ah stimmt, wenn du die erstmögliche Verbindung direkt annimmst, dann gibt es natürlich gar keinen Versuch den nächsten Key zu nehmen. Dann sehe ich keine Möglichkeit das rückwärts kompatibel für die bereits laufenden Installationen zu machen. Für zukünftige ist das ja gar kein Problem, denn du generierst dann im Client Modul ja ohnehin einen Ed25519 Key statt dem RSA (nehme ich an?), sofern es noch überhaupt gar keinen Schlüssel gibt.

Die Reihenfolge, in der die Keys ausprobiert werden, bestimmt der Client. Leider ist es noch immer so, dass per Default RSA Schlüssel bevorzugt werden, weshalb man seine lokale SSH Client Konfiguration so wie hier anpassen muss. Bestandsinstallationen können diese Methode natürlich auch nutzen, um RSA wieder zu priorisieren - einfach die Reihenfolge von der IdentityFile Einträge in der ~/.ssh/config ändern. Den Usern wäre aber zu empfehlen sich besser nochmal neu zu registrieren.

Natürlich könnte man den zu verwendenden Schlüssel auch in FEHM erst auswählen müssen, sofern es mehrere gibt. Dieser kann dann mittels -oIdentityFile= direkt mit übergeben werden. Nachteil ist aber natürlich, dass der User das nicht mehr zentral über die ~/.ssh/config Datei pflegen kann, sondern an mehreren Stellen. Ich vermute auch, dass man dafür die Kommunikation zwischen dem FHEM Alexa Modul und alexa-fhem entsprechend anpassen muss, wäre also sicher Aufwand.






Vor diesem Hintergrund habe ich mir bei der Hunderunde gerade die Frage gestellt:
1. Warum die Registrierung per SSH?
2. Warum überhaupt den Tunnel über SSH?

Vielleicht macht es Sinn zumindest für ein theoretisches Gedankenspiel noch einmal einen Schritt zurück zu machen.


1. SSH Client Schlüssel Registrierung per HTTP/S statt SSH selbst
Wie man ja nun sieht verursacht die Registrierung des Clients über den Tunnel, der später auch als Transporttunnel dienen soll, ein paar Henne-Ei Probleme. Die sind nicht unbeherrschbar, jedoch gibt es für die Alexa Kommunikation ja eh schon ein Webinterface und da stellt sich mir schon die Frage, warum ich den SSH Schlüssel nicht darüber registriere. Wahrscheinlich, weil der Endbenutzer-Logik nach dies vom FHEM Alexa Modul zu erledigen wäre und nicht vom alexa-fhem Backend Dienst. Jetzt, wo André und du die Karten zusammen auf den Tisch gelegt habt, wäre das ja eine Option. Man bräuchte also ähnlich wie auch bei der expliziten Auswahl des SSH Schlüssels eine Anpassung beider Teile.

2. Tunnel über HTTPS statt SSH
Mir ist nicht ganz klar, warum man für den Aufbau eines bidirektionalen Tunnels unbedingt SSH verwenden muss. Ich mag mich irren, aber mit der Art wie Websockets aufgebaut werden (UPGRADE) hat man hinterher auch eine offene TCP Session. Beim SSH Tunnel lässt du den SSH Client ja auch alle 90 Sekunden ein Hello schicken, das ginge doch auch über Websockets, um die Verbindung offen zu halten. Einen selbst generierten SSL Client Schlüssel kann der Benutzer genauso verwenden, der muss gar nicht mal unbedingt über eine Zertifikatsstelle ausgestellt sein. Den kannst du genauso auf dem Server "pinnen" und erlauben wie einen SSH Schlüssel auch, zumal lässt er sich auf FHEM Seite leichter generieren und auch speichern. Den kann sich alexa-fhem als Backend ja dann von FHEM abholen und verwenden und muss dann gar nichts mehr tun außer die Verbindung damit aufzubauen. Dass die Verbindung funktionieren wird, hat das FHEM Alexa Modul zuvor über eine Registrierung per HTTPS sichergestellt.

Es mag zunächst unkomplizierter sein, weil SSH einfach schon immer auf bidirektionale Kommunikation ausgelegt war. Allerdings ist SSH IMHO nie für die moderne Web Welt konzipiert worden (Anno 1995 bzw. 2006) und auch nicht dafür in einer Cloud Welt zu skalieren. Auch findet am SSH Protokoll keine wirkliche Entwicklung und Innovation mehr statt.

Ganz anders bei TLS: Mit TLS 1.3 stehen einige interessante Neuerungen schon in der Tür und mit TLS 1.2 bekommt man auch eine Chain-of-Trust über X509, die man so bei SSH eben nicht hat (wurde eingangs hier ja auch bemängelt). Ein explizites Pinning des Server Zertifikats wäre somit nicht mehr zwingend notwendig. Auch ist diese Methode über Proxies hinweg viel einfacher, wohingegen SSH über Socks ziemlich schmerzhaft ist und heutzutage eine echte Sonderlocke, wo alles auf HTTP (getunnelt) existiert.

Eine Verbindung über SSH fühlt sich einfach "alt" an und kommt mir bei einer über das Internet geteilten Cloud-ähnlichen Infrastruktur einfach falsch vor - zumindest wenn ich es mir aussuchen könnte.

3. Andere Trennung zwischen Backend und Frontend Dienst
Eigentlich wäre es am besten, wenn der Backend Dienst alle Informationen, die er für den Aufbau des Tunnels braucht, vom FHEM Alexa Modul geliefert bekäme und der Backend Dienst dann nur noch die Verbindung damit aufbaut. Die Erstellung und Registrierung eines Client Schlüssels sollte das Alexa Modul in FHEM direkt tun.
FHEM sollte hier der "Master" sein und alexa-fhem der "Sklave" (soll aber nicht abwertend klingen).






Wie gesagt, es soll nur einmal eine Anregung zum Nachdenken sein. Das bedeutet nicht alles von heute auf morgen über Board zu werfen und sicher sind meine Gedanken da auch unvollständig.
Aber vielleicht sieht man da, dass man den Aufwand die SSH Geschichte zu verbessern u.U. auch in einer anderen Richtung lenken könnte.

Mir ist bewusst, dass wir hier nicht von einer kommerziellen Enterprise Lösung sprechen. Nur die Möglichkeiten sollte man ja zumindest mal erörtert haben :-)
Immerhin habe ich den Ansatz auch so verstanden, dass neben dem Komfort keinen eigenen Skill mehr betreiben zu müssen auch die Sicherheit der FHEM Benutzer verbessert werden soll, indem sie keinen eigenen Port mehr nach innen öffnen müssen. Das wird zwar auch erreicht, aber die Sicherheit ist (für mich) an anderer Stelle dann zumindest nicht so gut, wie sie sein könnte. Und Benutzer haben leider auch bestimmte Erwartungen an einen "Cloud Dienst" (ich nenne ihn jetzt hier mal so), der ihnen Arbeit und Hirnschmalz abnimmt - egal ob er kostenfrei angeboten wird oder nicht.

Die tatsächlichen Aufwände kann ich natürlich rein aus der Theorie heraus nicht abschätzen - da kommt ihr dann ins Spiel.



Viele Grüße
Julian
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

gvzdus

Die Diskussion habe ich mit Andre intensiv geführt, und Andre ist durchaus dem WebSocket sehr zugeneigt. Ich werde später, ggf. in ein paar Tagen, darauf antworten, die "pro SSH"-Argumente aufführen.
Ich bin dem WebSocket gar nicht so abgeneigt ggü., insbesondere, seit ich weiß, dass es auch eine Socket.io-Implementierung für Apache-MINA+netty gibt.

Loredo

Wer geheim konspiriert, diskutiert dann eben zweimal [emoji51]
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

justme1968

lass dir mal von georg die vorteile der ssh version aufzählen.

das ganze ist leider komplizert

das problem ist...

- die ssh version ist fertig, die websocket version nicht :)
  jedenfalls nicht mit oauth und sicherheit. der reine tunnel ohne sicherheit gibt es auch
  mit websockets schon.


- ssh und websocket haben mehr oder weniger genau entgegengesetzte vor und nachteile

- bei ssh authentifizieren sich client und server automatisch, bei https erst mal nur der server

- clientzertifikate sind ein albtraum. erst recht self signed

- self signed https client zertifikate sind nicht wirklich sicher

- websocket wäre direkt. immer wartend. ohne extra pozess. eingebaut in alexa-fhem. ohne user,
  password, shell probleme.

- aber mit dem problem das man die komplette schlüsselverwaltung selber bauen muss.
  das wir beide enden der verbindung kontrollieren und kein 'echter' browser dran muss macht
  einerseits einfacher, andererseits fehlt aber auch die browser infrastruktur wie keystore & co.

- ein grossteil des aufwandes ist tatsächlich das initiale setup. das hat georg für ssh inzwischen
  so weit im griff. für open-ssl auf den clients ist das noch mal komplizierter und noch nicht da

- wir haben nicht das 'klassische' web modell mit einem server der sich gegenüber vielen clients
  ausweisen muss und die clients melden sich ganz altmodisch mit user und password an sondern
  wir haben viele clients die sich an einem server ausweisen müssen. ohne das der server persönliche
  daten speichert oder klassische accounts hat. da passt https nur bedingt.

zur arbeitsteilung: das ist nicht ganz so einfach. fhem soll zum einen am liebsten gar nichts davon mit bekommen wie die verbindung oder der tunnel konkret funktionierten. je nach skill gibt es davon ja eventuell auch mehrere (wie wir den proxy auch für custom/private skills verwenden können überlegen wir gerade) zum anderen ist per für solchen 'modernen' netzwerk geschichten nicht ideal. das geht mit node wirklich sehr sehr gut.

hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

gvzdus

Eigentlich wäre es ja fair, jetzt im Gegenzug ein Loblied auf Andres Websocken-Ansatz zu schreiben (die Autokorrektur lass ich mal machen, ist ja lustig).

Aber um das Pro von SSH noch abzuschließen:

  • Nach meiner betrieblichen Erfahrung macht SSH Probleme im Funktionieren, wenn das Systemalter Server-Client ca. 12 Jahre auseinander läuft (Server und Client). Bei SSL eher 4-6 Jahre.
  • Trotz der hohen Rückwärtskompatibilität und ohne SSH-Hardening runterzureden: Heartbleed, Logjam, CRIME, you name it: Alle bei SSL. Heisst nicht, dass es bei SSH nicht nur deswegen kein Thema war, weil z.B. die Angriffsvektoren mangels Webserver fehlen. Vielleicht filtere ich: Aber wo war auf dem Heise-Ticker die Meldung: "Jetzt SSH upgraden, oder schon morgen ist Dein Webserver im besten Fall nur "full of porn"?
  • Clientzertifikate bei SSL sind betrieblich / im Troubleshooten ein Horror. Zumindest unter Java, anderes kenne ich nicht. Weil jede hilfreiche Fehlermeldung fehlt, selbst für Google ist oft zu wenig Futter da.
  • Expiry des Cert und Trusted-CAs sind eher potentielle Fehlerquellen für Nutzer als Hilfe
  • Definitiv hat es Vorteile, wenn eine Applikation nicht erst ihren Tunnel-Sklaven anwirft, sondern selbst die Connectivity managed. Andererseits fände ich als Anwender wirklich sympathisch, auf der localhost-Schnittstelle klar und ohne Hintertüren mitschneiden zu können, was denn so von außen und diesem mysteriösen Vereinsserver so ins Haus kommt. Es hat eine enorme Transparenz, das jeder fortgeschrittene Anwender komplett aufzeichnen kann, was die Cloud so an ihn füttert und sendet.