AlexaLazy - Sicherheitsübeelegungen

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

Vorheriges Thema - Nächstes Thema

gvzdus

    Migration RSA -> ED25519
    Folgenden Plan habe ich:
    • Die nächste Version von alexa-fhem soll "sticky" auf RSA sein (per -i ~/.ssh/id_rsa - Option)
    • Gibt es eine hinreichende Verbreitung von dieser Version oder folgenden bei den Menschen, die ED25519-Keys haben und bevorzugt anbieten (anders als die Default-Config), kann ich ED25519 gefahrlos am Server wiedereinschalten
    • Dazu wird ab der nächsten Version von alexa-fhem die Versionsnummer an den Server gemeldet

    Die eigentliche Migration - natürlich automatisch in alexa-fhem - stelle ich mir dann so vor:

    > ssh -i ~/.ssh/id_rsa .... join <secret>
    < Your registered public key is ready to add other public keys to uid EF8989
    > ssh -i ~/.ssh/id_ed25519 join <secret>
    < Your unregistered public key was added to uid EF8989


    Grundidee: Wenn innerhalb von Zeit x von der gleichen IP das gleiche Secret kommt, wird PublicKey 2 als alias PublicKey 1 hinzugefügt.

    gvzdus

    Andre und ich überlegen eine Änderung von alexa-fhem:

    • Die Idee, SSH zu verwenden, geht auf mich zurück und bildet ja die Basis des gegenwärtigen Prozesses
    • Andre neigte ursprünglich eher einer Lösung über WebSockets zu. Letztlich haben wir uns für die SSH-Lösung entschieden, weil sie einfach fertig war
    • Eine Mittellösung wäre, die SSH-Implementierung unter nodejs (https://github.com/mscdex/ssh2) einzusetzen. So als "proof of concept" hat Andre das zum Laufen gebracht, wobei wir noch etwas Arbeit hineinstecken müssten

    Die Idee wollen wir hier einmal diskutieren. Im Prinzip würden wir dann mit ssh-keygen wie bisher einen Schlüssel erzeugen, aber nur temporär auf dem Dateisystem, um ihn dann in FHEM zu importieren. Das kontinuierlich laufende SSH-Hilfsprogramm wäre überflüssig, der SSH-Tunnel würde direkt aus alexa-fhem aufgebaut werden.

    Vorteile

    • Geschätzt 30-40% der Probleme sind Permission-Probleme: Gruppenbeschreibbares Homedir, nicht beschreibbares known-host-File, fremdlesbarer SSH-Key. Eigentlich sehr gut, dass SSH diese Mechanismen eingebaut hat - für ein Multiuser-Betriebssystem wichtig - aber der heimische Raspberry ist eher kein Multiuser-Host. Wir könnten diese Probleme vermutlich zum Verschwinden bringen
    • Mittlerweile ist die Verzahnung von alexa-fhem und seinem SSH-Subprozess eigentlich ziemlich stabil, aber eine Lösung mit einem statt zwei Prozessen ist hübscher
    • So ziemlich alles an Daten liegt dann an einer Stelle, in FHEM

    Nachteile

    • OpenSSH ist "rocketstable", und die Lösung läuft ja. Warum was Funktionierendes umkrempeln?
    • Ich habe die Transparenz hervorgehoben, dass im Prinzip jeder per tcpdump aufzeichnen kann, was von außen reinkommt. Mit dem integrierten Tunnel sähe man nur noch die verschlüsselten Pakete auf der Netzseite und muss dem Log trauen
    • Im Moment kann der Fachkundige durchaus "per Hand" mit Kommandos wie "ssh ... status" spielen. Mit in FHEM verstecktem Private/Public-Key wird das schwieriger

    Wie ist die Meinung des werten Publikums?

    justme1968

    vielleicht noch drei anmerkungen:

    ein weiterer vorteil wäre die möglichkeit im tunnel nicht mehr mit http requests arbeiten zu müssen sondern die stehende verbindung direkt vom proxy durchgehend zu alexa-fhem zu haben. nicht nur bis zum ssh client.

    ob und wie sich das auf die reaktionszeit auswirkt haben wir noch nicht getestet.

    ein nachteil wäre das man mit tcpdump nicht mehr die unverschlüsselten daten zwischen lokalem tunel ende und alexa-fhem beobachten kann. die daten landen ja dann direkt ohne umweg in alexa-fhem und werden erst dort entschlüsselt.
    hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

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

    rudolfkoenig

    Meine Meinung:
    - je weniger Komponenten/Prozesse, die man orchestrieren muss, umso besser.
    - wer alexa-fhem startet, der soll bitte dem Programmlog trauen, sonst Quellen lesen.
    - die SSH-Verzeichnisprobleme scheint ihr inzwischen im Griff zu haben, sonst koennte man im Installationsprozess "idiotensichere" Fehlermeldungen bei typischen Problemfaellen ausgeben
    - an einem messbaren Performance-Unterschied glaube ich nicht.
    - Vorteil sehe ich auf einem Windows Rechner, wo man kein ssh installieren muss.
    - nachteilig finde ich, dass eine Abhaengigkeit von einem weiteren, vermutlich eher selten benutzten node.js Modul eingefuegt wird.
    - das mit "nicht mehr mit http requests arbeiten zu müssen" habe ich nicht kapiert: Verbindung ist Verbindung, d.h. das koennte man auch mit SSH anders machen.

    Alles in allem: unentschlossen :)

    gvzdus

    Einen Punkt möchte ich ausführen:
    Mich quält ja jede vermeidbare Millisekunde, das ist mein Ethos :-)
    Z.Zt. werden beim Request 2 Pakete über den SSH-Tunnel geschickt:

    • Mach' den Tunnel auf! (TCP open)
    • Der Request selber
    Das führt zwischen Vereinsserver und lokalem Raspberry zu 2 Roundtrips (Ping-Laufzeiten) - typischerweise etwa 40-80 ms, die sich grundsätzlich halbieren ließen.

    Für dieses Optimierungspotential gibt es zwei Möglichkeiten:

    • Einerseits wird der lokale Listener in alexa-fhem schon jetzt mit einem Timeout von unendlich geöffnet. Heißt: Anders, als ein Webserver, der einem Browser, der keinen Request sendet, nach einigen Sekunden die Verbindung wieder zumachen würde, hält alexa-fhem eine geöffnete TCP-Verbindung ewig offen. Das habe ich bei Andre damals erbeten, um bei Muße im SSH-Proxy einzubauen: "Mache den TCP-Port schon mal "auf Verdacht für die Zukunft" auf." Das TCP-Open würde also gleich am Anfang kommen.
    • Wenn wir SSH in alexa-fhem integrieren, würden wir das gleich so machen. Und wir würden auch gar nicht mehr HTTP spielen, sondern nur noch JSON-Pakete über den SSH-Kanal schicken.

    Die größere Zeit geht allerdings z.Zt. m.E. beim Aufbau der SSL-Verbindung zwischen Lambda-Funktion und Vereinsserver verloren, eher ein dreistelliger Millisekundenzeitanteil - wegen der Laufzeit Irland <-> Deutschland (und wenn erst der Brexit kommt, wer weiß :-) ). Dazu habe ich mir mal Gedanken über eine verschlüsselte Kommunikation per UDP gemacht, aber das wird in keinem Fall so sauber und standardkonform wie "anständiges" TLS.

    drhirn

    Nur zum Verständnis: Was spricht dagegen, den WebSockets-Ansatz weiter zu verfolgen?

    Loredo

    #36
    Meine Überlegungen gehen in eine ähnliche Richtung wie die von Rudi.

    - weniger Komponenten sind gut, allerdings wird SSH auch für andere Dinge und Module deshalb nicht überflüssig. So viel lässt sich damit also auch nicht gewinnen.
    - ich sehe es durchaus als ein Security Plus an, dass man nicht mehr so einfach mittels tcpdump mitlauschen kann. Einen MITM Proxy muss man sich erstmal nachbauen, damit das geht. Ansonsten habe ich hier den selben Standpunkt wie Rudi: Wer misstraut, der kann die Quellen lesen (zumindest vom Client-Teil, aber der sollte ausreichen)
    - ich bin unsicher, wie gut die node.js Implementierung von SSH tatsächlich ist. Durch die wahrscheinlich eher geringe Verbreitung könnten Fehler dort nicht schnell genug behoben werden oder gar nicht erst auffallen; OpenSSH steht da unter besserer Beobachtung. Allerdings gilt auch für die Server Komponente die geringere Verbreitung schon. Dort kann man aber besser reagieren, weil eine zentral gemanagte Umgebung.
    - Unsere Windows User Base ist verschwindend gering. Im Grunde kann man das nur als Spielwiese zum ausprobieren sehen, IMHO müssen da nicht alle Funktionen gehen oder zumindest nicht als "plug and play". Wer zuhause heutzutage tatsächlich noch einen eigenen Windows (Home) Server laufen hat, dem ist auch zuzumuten eine Hyper-V VM zu installieren.
    - dass über den SSH Tunnel nochmals per TCP/HTTP gesprochen wird, hatte ich bisher gar nicht so klar bedacht, ergibt aber Sinn bei der aktuellen Architektur. Für mich ist das "gehüpft wie gesprungen", solange die einzelnen Tunnel und Sessions innerhalb des Servers tatsächlich voneinander getrennt sind. Da fehlt mir aktuell die Vorstellungskraft wie die genau im Server zusammenlaufen und die Daten verteilt werden. Vom Gefühl her würde ich sagen, dass aufgrund des tatsächlich terminierten Ports theoretisch der eine Tunnel auch leichter auf einen anderen Tunnel bzw. alexa-fhem Instanz zugreifen könnte, wenn jemand den Client umschreibt. Ich könnte mir vorstellen, dass man diese Separierung der Verbindungen über SSH ohne HTTP besser hinbekommt. Aber wirklich komplett abgrenzen lässt sich das wohl nur, wenn man gar keinen Tunnel mehr hat, sondern nur noch WebSocket Sessions. Zumindest wäre da mein Bauchgefühl besser.

    Zitat von: gvzdus am 28 Januar 2019, 22:55:19Die größere Zeit geht allerdings z.Zt. m.E. beim Aufbau der SSL-Verbindung zwischen Lambda-Funktion und Vereinsserver verloren, eher ein dreistelliger Millisekundenzeitanteil - wegen der Laufzeit Irland <-> Deutschland (und wenn erst der Brexit kommt, wer weiß :-) ). Dazu habe ich mir mal Gedanken über eine verschlüsselte Kommunikation per UDP gemacht, aber das wird in keinem Fall so sauber und standardkonform wie "anständiges" TLS.

    Den initialen Verbindungsaufbau sehe ich da unkritisch und auch ansonsten ist die Reaktionszeit innerhalb Europa ausreichend performant (sieht man ja auch am Feedback, dass alle bemerken, dass es super schnell geht). Wenn man über einen Austausch von TCP nachdenken würde, dann sollte man besser gleich auf QUIC setzen, welches auch bereits für TLS 1.3 und HTTP/3 vorgesehen ist. Im Falle von TLS 1.3 gibt es sogar einen speziellen Modus, der Roundtrips ganz und gar überflüssig macht, sofern die übertragenen Daten nicht anfällig für eine Replay-Attacke sind.
    EDIT: Sorry, hier war natürlich die Rede von AMAZON <--> Vereinsserver. Da ist man natürlich darauf angewiesen, welche Protokolle Amazon da schon anbietet.
    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

    websocket und ssh direkt in node unterscheiden sich ,nur' im aufbau der verbindung und dort mit welchem high level protokoll zertifikate und schlüssel ausgetauscht werden. wobei die eigentlichen verfahren auch wieder zum großen teil identisch sind.

    wenn alles steht ist beides im prinzip identisch.

    auf unterster ebene sind beides direkte verbindungen über sockets.


    ja. openssh ist potentiell sicherer weil verbreiteter und unter strengerer überwachung. andererseits ist es potentiell auch gefährdeter da es ein lohnenderes ziel ist. siehe cert meldungen der letzten tage und wochen. aber das betrifft meistens die server seite dir bei uns auch jetzt schon nicht openssh ist. ich vermute es nimmt sich also nicht viel.
    hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

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

    Loredo

    Zitat von: justme1968 am 29 Januar 2019, 10:02:25
    ja. openssh ist potentiell sicherer weil verbreiteter und unter strengerer überwachung. andererseits ist es potentiell auch gefährdeter da es ein lohnenderes ziel ist. siehe cert meldungen der letzten tage und wochen. aber das betrifft meistens die server seite dir bei uns auch jetzt schon nicht openssh ist. ich vermute es nimmt sich also nicht viel.


    Ich sehe solche Meldungen ja eher immer als Pluspunkt an, denn dann werden die Dinge nochmals besser durchleuchtet. Nur weil eine weniger oft verwendete Software nicht in den Schlagzeilen ist, weil sie als Angriffsziel nicht so attraktiv ist, heißt das nicht, dass man dann bedenken und gefahrlos diese Software einsetzen sollte. Da landet man schnell auch wieder bei "gefühlter" Sicherheit und hält höchstens die Script-Kiddies fern. :-)
    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

    das war auch eher als: auch bei openssh nicht in sicherheit wiegen gemeint.

    und nicht immer ist alles updaten der richtige weg. mancher alte rechner hat ssh versionen die durch die letzten probleme nicht betroffen waren weil zu alt :)
    hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

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