AlexaLazy - Sicherheitsübeelegungen

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

Vorheriges Thema - Nächstes Thema

Sidey

Hi,

Ich habe mir das Fhem Lazy angesehen.
Die Entwicklung passt prinzipiell auch gut, zu dem was ich bereits als Risiko bezüglich einer Alexa Anbindung erkannt habe.

Ich bin allerdings noch etwas skeptisch, ob es wirklich so sicher ist, wie ich es gerne hätte
Es kann gut sein, dass ich es nicht richtig verstanden habe.

Ich fasse grob zusammen, wie ich es verstehe:

Es gibt AWS Lambda Funktionen und einen Skill. Diese werden vom FHEM Verein zur Verfügung gestellt.

Der Verein stellt auch einen Server bereit der als Proxy mit Authentifizierung agiert.

Ein lokal laufendes NodeJS wird über einen SSH Tunnel an den Proxy Server angebunden.

Wie genau Fhem nun an NodeJS hängt, habe ich mir noch nicht angesehen.  Ist glaube ich auch nicht so entscheidend.


Wenn ich das soweit richtig erfasst habe, dann habe ich gegenüber der vorherigen Implementierung folgendes geandert:

1. Ich habe keinen Port im Internet geöffnet auf den potentiell 7 Mrd.
zugreifen können.

2. Ich muss mich nicht mit AWS Lambda Funktionen abgeben.

3. Ich vertraue dem FHEM Verein, dass nur ich über meinen SSH Tunnel auf meinen nodeJS Server zugreife.

Der Letzte Punkt ist auch genau der, mit dem ich hadere.

1. Die Kommunikation läuft über HTTP. Also kann NodeJS nicht feststellen, wer gerade zugreift. Dem Proxy Server dürfte es auch schwerfallen zu erkennen, ob er die Daten an das richtige System leitet.
Eine Prüfung der Gegenstellen mit HTTPS wäre hier sicher Vorteilhaft.

2. Der SSH Tunnel wird über einen Schlüssel etabliert.
Der läuft vermutlich nie ab und ob ich mit dem richtigen Endpunkt kommuniziere, hängt vom DNS ab. Das wird nicht verifiziert (oder?).
Wie sicher die Erzeugung der Schlüssel ist, lasse ich mal offen. Eine Variante über eine anerkannte Zertifizierungsstelle wäre mir lieber.

Diese Annahmen haben mich zur Frage gebracht, ob dieser SSH Tunnel wirklich so gut ist.

Ich würde am liebsten ja bei mir selbst entscheiden wollen, wer auf das nodeJS Zugriff bekommt und es ungern einem anderen System überlassen.

AWS scheinen ja auch Oauth2 Tokens des Accounts zu erstellen unter dem der Echo läuft.
Oauth2 Authentifizierung habe ich bereits über einen Reverse Proxy evaluiert. Das ist nicht wirklich schwierig und man kann die Accounts auch whitelisten.
Gibt es Gründe, die dagegen sprechen die Zugriffe lokal bei sich selbst zu verifizieren?

Ich will die Lösung mit dem SSH Tunnel nicht schlecht machen. Aber ich vermute, auf den Proxy Server des Vereins können die gleichen 7 Mrd. Zugreifen, wie auf meinen potentiell im Internet geöffneten Port.
Der Sicherheitsgewinn ist mir dazu noch nicht so visibel :(


Grüße Sidey





Gesendet von meinem Moto Z (2) mit Tapatalk

Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

gvzdus

Hi, ich finde es gut, dass Du mal laut und kritisch über das Sicherheitskonzept nachdenkst.

Allerdings sind an 1-2 Stellen Deiner Fragen m.E. die Fragen schon im Wiki beantwortet, z.B. nach der DNS-Manipulation. Kannst Du bitte noch mal im Wiki den Abschnitt "Sicherheitskonzept und Secrets" lesen?

Zu SSH: Das gilt als sicher, jedenfalls viel sicherer als Passwörter. Nicht umsonst setzt Amazon bei EC2 durchgängig da drauf.

Zu Deiner Sicherheit: Die hängt im Kern am BearerToken, das durchaus in FHEM abrufbar ist (auch wenn Andre es künftig nicht direkt sichtbar macht). Das BearerToken reichst Du einmalig über den Vereinsserver an Amazon weiter, aber es wird auf dem Vereinsserver nicht gespeichert.

Einfach die Einladung, Dich selber zu hacken (oder mich), im Moment geht das noch, weil auf dem Vereinsserver nicht die Kommandos auf den Amazon-IP-Range gefiltert werden:

Schnappe Dir aus Deinem Lizenzschlüssel die erste Gruppe. Ich sage Dir meinen aktuellen ersten Teil: 1469F4

Wenn Du jetzt folgenden Aufruf machst:

curl -H 'Authorization: Bearer 1469F4' https://va.fhem.de/alexa

setzt Du einen Request auf meinen persönlichen Raspberry ab! Feel free!

Wenn Du jetzt noch mein Bearer-Token kennen würdest, dann könntest Du in der Tat meine Geräte steuern! Aber Alexa-FHEM prüft halt das BearerToken mit dem in FHEM hinterlegten, und solange Du das nicht kennst, werden Deine Zugriffe abgelehnt.

Happy testing mit Dir selbst oder mir!

gvzdus

P.S. In der Tat will ich das Kommando im IP-Range auf bekannte Amazon-IPs beschränken.
Ich hatte aber genau darauf gehofft, dass jemand die Frage stellt!

Was lässt sich noch verbessern?
Da die Lambda-Funktion "vom Verein" nicht public ist, kann man hier auch halbwegs brauchbar ein Secret hinterlegen, dass auf der URL

  https://va.fhem.de/alexa

dann geprüft wird. Das ist eine zusätzliche Hürde. Aber wie gesagt: Im Prinzip habe ich auf die Frage gehofft und das an der Stelle bewusst noch offen.

justme1968

von mir auch noch ein paar kurze anmerkungen... (ok... ist doch etwas länger geworden ;))

und eins vor weg: das ganze ist in jedem fall immer ein kompromiss aus sicherheit, komfort und kosten. egal wie man es dreht... du kannst nur zwei der drei optimieren. welche das sind und ob du dann mit dem erst risiko leben möchtest ist die entscheidung jedes einzelnen.


das jemand (oder auch am liebsten mehrere) sich das ganze anschauen und ideen haben ist sehr gut! hierbei sollte aber die zielgruppe nicht aus den äugen verloren werden. das ist weder der sicherheitsfanatiker noch der technisch so versierte der sich alles mit eigenen skills selber einrichtet. sondern es sind die anwender die nicht das können und die zeit und die lust dazu haben.


nun etwas zum konzept:
- wenn man eine lösung anbieten möchte die eine benutzung von alexa mit fhem über einen ganz normal für alle veröffentlichten skill erlaubt ist erst mal ganz abstakt (unabhängig von port forwading oder reverse proxy oder wie auch immer) zwingende voraussetzung das dieser eine skill auf irgend eine art die jeweilige fhem installation des nutzers erreichen kann.

hierzu ist es zwingend nötig das der eine skill bei der aktivierung durch irgend einen mechanismus die möglichkeit bekommt den anwender der diesen skill aktiviert mit seiner fhem installation bzw. mit einem weg diesem fhem kommandos zu senden in verbindung bringen kann.

dazu wird in einem ersten schritt bei dir privat ein token und ein key erzeugt den nur du kennst. bei der skill aktivierung wird dein account mit dem token verknüpft. das token wird bei amazon gespeichert. weder key noch token werden an einer anderen stelle gespeichert.

wenn amazon ein sprach kommando von einem echo erkennt und dem skill zuordnet wird ein event erzeugt das dieses token enthält.

anhand des tokens kann die zuordnung zu dir und der proxy verbindung getroffen werden die du aufgebaut hast. über diese verbindung bekommt dann dein lokales alexa-fhem das event.


- ein grundprinzip ist das niemals jemand direkt von aussen auf deinen rechner zugreift oder direkten zugriff auf dein fhem system hat. das ist einer der gründe warum alexa-fhem nicht direkt ein fhem modul ist sondern ein getrennter prozess.

- es werden zu keinem zeitpunkt kommandos von aussen (egal ob von amazon, vom skill oder vom proxy) direkt ausgeführt (von 'normalen' sicherheistlücken abgesehen gilt das nach besten gewissen auch für ein gehacktes proxy system). das einzige was von amazon über den proxy an deinen lokalen alexa-fhem NodeJs prozess  geschickt wird sind events, die eine aktion beschrieben die amazon einem sprach kommando zugeordnet hat. dieses event wird vom alexa-prozess in kommandos für fhem umgesetzt. d.h. erst hier in deiner lokalen installation und nur für fhem devices die du auch zur steuerung durch alexa freigegeben hast werden die kommandos zusammen gebaut.

- jedes event enthält zur authentisierung ein token das wären den installation lokal bei dir erzeugt wird und das nur du und amazon kennen. dieses token und auch der key der am anfang ein mal zur skill verknüpfung verwendet wird ist nirgends auf dem proxy server oder im skill oder in der lambda funktion gespeichert.

- alexa-fhem akzeptiert nur events von denen das token geprüft werden kann. im falle des proxy wird das token gegen das nur dir bekannte token geprüft.

- auch wenn ein event akzeptiert wird: es lassen sich nicht beliebige geräte steuern sondern nur die geräte die du freigeben hast. d.h. selbst wenn jemand es schaffen würde auf irgend einem weg ein gefakedes event für dein tüschloss ein zu schmuggeln kann er es nicht steuern wenn du das schloss nicht für alexa frei gegeben hast.

deine fragen 1 und 2 stimmen so weit.
deine frage 3 ist zumindest unglücklich formuliert.

ja. es ist nötig das nur du den key kennst und nur du und amazon das token.
ja. es ist nötig das du dem proxy server bzw. dem verein vertraust das tatsächlich keine daten gespeichert werden und das mit den temporär für den betrieb empfangen daten kein missbrauch getrieben wird.

wenn du das nicht kannst ist dieser skill nichts für dich und wenn du trotzdem einen echo mit fhem verwenden möchtest musst du wie bisher alles selber mit einem privaten skill und port forwading machen.

wenn du beides weitergibst hast du ein problem. das hast du aber mit jeder anderen art des cloud zugriffs auf wenn du deine zugangsdaten weitergibst.


zu deinen anderen punkten:

1. was meinst du mit 'wer zugreift' ?

die verbindung zwischen proxy tunnel und alexa-fhem nodejs prozess ist nur für localhost aktiv (siehe code oder netstat). d.h niemand ausser dem tunnel und einem anderen prozess auf deinem eigenen rechner kann events an dein alexa-fhem schicken. diese events müssen deine geheimes token enthalten damit sie verarbeitet werden.

szenarien:
- proxy server ist sicher
    -> die events sind immer zuzuordnen
- netzwerk verkehr wird belauscht/manipuliert
    -> das geht nicht. ssh ist mindestens so sicher wie https
- jemand biegt den proxy server auf einen anderen host um
    -> wenn der ssh key des servers nicht mehr passt wird der tunnel nicht aufgebaut. genau so wie bei https
- der proxy server wird gehackt
    -> ja. es gibt ein problem. das würde es im https fall aber genau so gelten.


2. ein ssh key ist genau so sicher wie ein https zertifikat. beiden liegen die gleichen verfahren zu grunde
    einziger unterschied: du entscheidest selber ob du einem key vertraust und überlässt das nicht einer
    zentralen instanz die nicht immer zuverlässig ist.

ja. ein ssh tunnel ist mindestens so sicher wie eine https gesicherte verbindung.



wenn du selber entscheiden willst: siehe oben. dir bleibt nur der private skill und selber tunnel oder proxy aufbauen.

aber achtung: du musst aufpassen verschlüsselung und authentifizierung (und hier noch mal client und server) durcheinander zu bringen. ssh und https sind erst mal nur verschlüsselung und authentifizierung des servers. nicht des clients.

wenn amazon ein event erkennt und dir schickt wird die verbindung von amazon aus aufgebaut. du bist der server. amazon kann erkennen das du 'echt' bist. du kannst aber nicht erkennen das amazon 'echt' ist. es wird kein client zertifikat verwendet.

du kannst die 'echtheit' nur am oauth token das amzon mit schickt feststellen. dieses ist aber keine signatur des events und gilt für eine stunde. d.h. wenn auf dem weg irgendetwas gehackt wird kann man mit dem einen event beliebig viele weiter erzeugen und senden. innerhalb der einen stunde.

bleibt nur die absender ip. das wird der vereins proxy auch noch tun. wenn du dem nicht vertraust bleibt nur selber machen.



der proxy ist nicht da um einen sicherheitsgewinn zu haben. sondern um allen die es nicht selber machen wollen eine lösung zu bieten, die so sicher wie möglich ist.

das ist unsicherer als alles selber zu machen. aber weniger weil die konzepte unsicher sind sondern weil es zum einen eine instanz mehr ist der man vertrauen muss und zum anderen ein zentraler server potentiell im angriffs- und fehlerfall auswirkungen auf mehr accounts hat als nur deinen eigenen.

womit wir wieder beim abwägen der drei faktoren vom anfang sind. du kannst nicht alle drei optimieren. höchstens zwei.

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

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

gvzdus

Da ich ja viel teste, hat sich der Routing-Key bei mir geändert....
12D182
ist aktuell. Ich würde gerne demnächst die Seite zwischen Lambda und Vereinsserver mit einem Secret schützen - besteht die Absicht, mal das Hacking meines Servers zu versuchen?

ThoTo

Zitat von: gvzdus am 13 Januar 2019, 20:38:01
Ich würde gerne demnächst die Seite zwischen Lambda und Vereinsserver mit einem Secret schützen - besteht die Absicht, mal das Hacking meines Servers zu versuchen?

Diese Idee hatte ich auch... Vielleicht lesen professionelle Pentester mit und würden ihre Dienste anbieten?
KNX | MQTT | Docker | Sonos | FHEMapp

"Zwei Dinge sind unendlich, das Universum und die menschliche Dummheit, aber bei dem Universum bin ich mir noch nicht ganz sicher." (Albert Einstein)

Loredo

#6
Ich verschiebe meinen Post aus dem Main Thread mal in diesen hier:






Ist geplant seitens des SSH Servers auch Ed25519 zu unterstützen?


Man könnte auch noch ein wenig was an den Server Einstellungen drehen:


ssh-audit -p 58824 fhem-va.fhem.de


# general
(gen) banner: SSH-2.0-APACHE-SSHD-2.1.1-SNAPSHOT
(gen) compatibility: OpenSSH 7.3+ (some functionality from 6.6), Dropbear SSH 2016.73+ (some functionality from 0.52)
(gen) compression: enabled (zlib, zlib@openssh.com)


# key exchange algorithms
(kex) ecdh-sha2-nistp521                    -- [fail] using weak elliptic curves
                                            `- [info] available since OpenSSH 5.7, Dropbear SSH 2013.62
(kex) ecdh-sha2-nistp384                    -- [fail] using weak elliptic curves
                                            `- [info] available since OpenSSH 5.7, Dropbear SSH 2013.62
(kex) ecdh-sha2-nistp256                    -- [fail] using weak elliptic curves
                                            `- [info] available since OpenSSH 5.7, Dropbear SSH 2013.62
(kex) diffie-hellman-group-exchange-sha256  -- [warn] using custom size modulus (possibly weak)
                                            `- [info] available since OpenSSH 4.4
(kex) diffie-hellman-group-exchange-sha1    -- [fail] removed (in server) since OpenSSH 6.7, unsafe algorithm
                                            `- [warn] using weak hashing algorithm
                                            `- [info] available since OpenSSH 2.3.0
(kex) diffie-hellman-group18-sha512         -- [info] available since OpenSSH 7.3
(kex) diffie-hellman-group17-sha512         -- [warn] unknown algorithm
(kex) diffie-hellman-group16-sha512         -- [info] available since OpenSSH 7.3, Dropbear SSH 2016.73
(kex) diffie-hellman-group15-sha512         -- [warn] unknown algorithm
(kex) diffie-hellman-group14-sha256         -- [info] available since OpenSSH 7.3, Dropbear SSH 2016.73
(kex) diffie-hellman-group14-sha1           -- [warn] using weak hashing algorithm
                                            `- [info] available since OpenSSH 3.9, Dropbear SSH 0.53
(kex) diffie-hellman-group1-sha1            -- [fail] removed (in server) since OpenSSH 6.7, unsafe algorithm
                                            `- [fail] disabled (in client) since OpenSSH 7.0, logjam attack
                                            `- [warn] using small 1024-bit modulus
                                            `- [warn] using weak hashing algorithm
                                            `- [info] available since OpenSSH 2.3.0, Dropbear SSH 0.28


# host-key algorithms
(key) ssh-rsa                               -- [info] available since OpenSSH 2.5.0, Dropbear SSH 0.28


# encryption algorithms (ciphers)
(enc) aes128-ctr                            -- [info] available since OpenSSH 3.7, Dropbear SSH 0.52
(enc) aes192-ctr                            -- [info] available since OpenSSH 3.7
(enc) aes256-ctr                            -- [info] available since OpenSSH 3.7, Dropbear SSH 0.52
(enc) arcfour256                            -- [fail] removed (in server) since OpenSSH 6.7, unsafe algorithm
                                            `- [warn] disabled (in client) since OpenSSH 7.2, legacy algorithm
                                            `- [warn] using weak cipher
                                            `- [info] available since OpenSSH 4.2
(enc) arcfour128                            -- [fail] removed (in server) since OpenSSH 6.7, unsafe algorithm
                                            `- [warn] disabled (in client) since OpenSSH 7.2, legacy algorithm
                                            `- [warn] using weak cipher
                                            `- [info] available since OpenSSH 4.2
(enc) aes128-cbc                            -- [fail] removed (in server) since OpenSSH 6.7, unsafe algorithm
                                            `- [warn] using weak cipher mode
                                            `- [info] available since OpenSSH 2.3.0, Dropbear SSH 0.28
(enc) 3des-cbc                              -- [fail] removed (in server) since OpenSSH 6.7, unsafe algorithm
                                            `- [warn] using weak cipher
                                            `- [warn] using weak cipher mode
                                            `- [warn] using small 64-bit block size
                                            `- [info] available since OpenSSH 1.2.2, Dropbear SSH 0.28
(enc) blowfish-cbc                          -- [fail] removed (in server) since OpenSSH 6.7, unsafe algorithm
                                            `- [fail] disabled since Dropbear SSH 0.53
                                            `- [warn] disabled (in client) since OpenSSH 7.2, legacy algorithm
                                            `- [warn] using weak cipher mode
                                            `- [warn] using small 64-bit block size
                                            `- [info] available since OpenSSH 1.2.2, Dropbear SSH 0.28
(enc) aes192-cbc                            -- [fail] removed (in server) since OpenSSH 6.7, unsafe algorithm
                                            `- [warn] using weak cipher mode
                                            `- [info] available since OpenSSH 2.3.0
(enc) aes256-cbc                            -- [fail] removed (in server) since OpenSSH 6.7, unsafe algorithm
                                            `- [warn] using weak cipher mode
                                            `- [info] available since OpenSSH 2.3.0, Dropbear SSH 0.47


# message authentication code algorithms
(mac) hmac-md5                              -- [fail] removed (in server) since OpenSSH 6.7, unsafe algorithm
                                            `- [warn] disabled (in client) since OpenSSH 7.2, legacy algorithm
                                            `- [warn] using encrypt-and-MAC mode
                                            `- [warn] using weak hashing algorithm
                                            `- [info] available since OpenSSH 2.1.0, Dropbear SSH 0.28
(mac) hmac-sha1                             -- [warn] using encrypt-and-MAC mode
                                            `- [warn] using weak hashing algorithm
                                            `- [info] available since OpenSSH 2.1.0, Dropbear SSH 0.28
(mac) hmac-sha2-256                         -- [warn] using encrypt-and-MAC mode
                                            `- [info] available since OpenSSH 5.9, Dropbear SSH 2013.56
(mac) hmac-sha2-512                         -- [warn] using encrypt-and-MAC mode
                                            `- [info] available since OpenSSH 5.9, Dropbear SSH 2013.56
(mac) hmac-sha1-96                          -- [fail] removed (in server) since OpenSSH 6.7, unsafe algorithm
                                            `- [warn] disabled (in client) since OpenSSH 7.2, legacy algorithm
                                            `- [warn] using encrypt-and-MAC mode
                                            `- [warn] using weak hashing algorithm
                                            `- [info] available since OpenSSH 2.5.0, Dropbear SSH 0.47
(mac) hmac-md5-96                           -- [fail] removed (in server) since OpenSSH 6.7, unsafe algorithm
                                            `- [warn] disabled (in client) since OpenSSH 7.2, legacy algorithm
                                            `- [warn] using encrypt-and-MAC mode
                                            `- [warn] using weak hashing algorithm
                                            `- [info] available since OpenSSH 2.5.0


# algorithm recommendations (for OpenSSH 7.3)
(rec) -diffie-hellman-group14-sha1          -- kex algorithm to remove
(rec) -ecdh-sha2-nistp256                   -- kex algorithm to remove
(rec) -diffie-hellman-group-exchange-sha256 -- kex algorithm to remove
(rec) -diffie-hellman-group1-sha1           -- kex algorithm to remove
(rec) -diffie-hellman-group-exchange-sha1   -- kex algorithm to remove
(rec) -ecdh-sha2-nistp521                   -- kex algorithm to remove
(rec) -ecdh-sha2-nistp384                   -- kex algorithm to remove
(rec) +curve25519-sha256@libssh.org         -- kex algorithm to append
(rec) +ssh-ed25519                          -- key algorithm to append
(rec) +rsa-sha2-256                         -- key algorithm to append
(rec) +rsa-sha2-512                         -- key algorithm to append
(rec) -blowfish-cbc                         -- enc algorithm to remove
(rec) -3des-cbc                             -- enc algorithm to remove
(rec) -aes256-cbc                           -- enc algorithm to remove
(rec) -arcfour256                           -- enc algorithm to remove
(rec) -aes192-cbc                           -- enc algorithm to remove
(rec) -arcfour128                           -- enc algorithm to remove
(rec) -aes128-cbc                           -- enc algorithm to remove
(rec) +aes128-gcm@openssh.com               -- enc algorithm to append
(rec) +chacha20-poly1305@openssh.com        -- enc algorithm to append
(rec) +aes256-gcm@openssh.com               -- enc algorithm to append
(rec) -hmac-sha2-512                        -- mac algorithm to remove
(rec) -hmac-md5-96                          -- mac algorithm to remove
(rec) -hmac-sha2-256                        -- mac algorithm to remove
(rec) -hmac-sha1-96                         -- mac algorithm to remove
(rec) -hmac-md5                             -- mac algorithm to remove
(rec) -hmac-sha1                            -- mac algorithm to remove
(rec) +hmac-sha2-256-etm@openssh.com        -- mac algorithm to append
(rec) +hmac-sha2-512-etm@openssh.com        -- mac algorithm to append
(rec) +umac-128-etm@openssh.com             -- mac algorithm to append



Den SSH Server zu härten ist da kein großer Aufwand, muss man eben halt nur machen.




Für den TLS HTTP Dienst gäbe es auch noch ein wenig zu tun:
https://www.ssllabs.com/ssltest/analyze.html?d=va.fhem.de&s=88.99.31.202&hideResults=on&latest
- TLS 1.0 und 1.1 ausschalten; Bonus: Aktivierung von TLS 1.3
- Umstellung auf LetsEncrypt EC Zertifikat (oder zumindest Wechsel von RSA 2048 auf 4096 Bit Schlüssel)
- Aktivierung von OCSP Stapling
- Abgleich der Settings mit Mozilla TLS Modern compatibility Empfehlungen




Der Form halber verweise ich auch noch auf den SecurityHeaders Report mit dem aktuellen Ergebnis "F" (betrifft eher Client-Server-Kommunikation Vereinsserver<>Alexa):
https://securityheaders.com/?q=va.fhem.de%2Falexa&hide=on&followRedirects=on


Wenn Hilfe beim härten der Serverdienste und der Client-Server-Kommunikation gewünscht ist, meldet euch gerne per PN.
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

Hi Loredo,

danke, lass mal hier weiter diskutieren.

Zu den SSH-Protokollen: Da ist mir jeder Ratschlag sehr willkommen. In der Tat wird derzeit vorzugsweise ein klassisches RSA-Paar ausgehandelt - das habe ich gewählt, weil ich mir davon die höchste Kompatibilität mit dem Client, auf dem alexa-fhem läuft, verspreche. Wenn Du mir Ratschläge zusammenstellen magst: "Versuch es doch der Reihe nach so, siehe der Artikel" ist das willkommene Mitarbeit!

Zu TLS: Fände ich gut, müsste aber Rudi König machen, denn der ist das "Gate". Das Abschalten der Alt-Protokolle TLSv1 & TLSv1.1 als Empfehlung kenne ich, setze es aber bei "meinen" Webservern nicht um, weil es Androids bis Lollipop ausschließt (Android bis inkl. 4.4).

Die Header-Thematik finde ich etwas übertrieben: Für die Kommunikation Lambda<=>Verein reden wir einem HTTPS-Client (nodejs), der interessiert sich nicht für Browser-Header, egal ob HSTS, CSP, Frames o.ä.

Für den Nutzer, der von Amazon "rübergeschickt" wird:
Für den "Connect" / Skillverknüpfung: Ich halte mir zugute, beim verweisenden Link auf der Check-Seite das "No-Referer"-Attribut gesetzt zu haben :-)
Bei der Registrierungsseite denke ich, dass die Frame-Header und CSP-Header Sinn ergeben.

Wie eingangs erwähnt:
Vor allem würden mich Empfehlungen für eine Reihenfolge des SSH-Key-Generierens interessieren, bzw. ein Link zu einem guten Artikel dazu.

Loredo

#8
Zitat von: gvzdus am 12 Januar 2019, 11:50:23
P.S. In der Tat will ich das Kommando im IP-Range auf bekannte Amazon-IPs beschränken.
Ich hatte aber genau darauf gehofft, dass jemand die Frage stellt!

Die Idee ist gut, aber es ist nicht ganz trivial betriebssicher umzusetzen. Da sich in den Wolken häufig so viel ändert, kann man sich nicht darauf verlassen, dass die IP Ranges lange bestand haben. Das manuell nachzuverfolgen ist oft aufwändig und fehleranfällig. Azure bietet eine API zur Abfrage aller IP Ranges und URLs an, mit denen man seine Firewalls etc. automatisch mit den gültigen IP Ranges versorgen kann.
Ob es sowas bei AWS gibt, kann ich nicht sagen, aber es lohnt ggf. mal zu googlen.

Zitat von: gvzdus am 14 Januar 2019, 18:06:54
Zu den SSH-Protokollen: Da ist mir jeder Ratschlag sehr willkommen. In der Tat wird derzeit vorzugsweise ein klassisches RSA-Paar ausgehandelt - das habe ich gewählt, weil ich mir davon die höchste Kompatibilität mit dem Client, auf dem alexa-fhem läuft, verspreche. Wenn Du mir Ratschläge zusammenstellen magst: "Versuch es doch der Reihe nach so, siehe der Artikel" ist das willkommene Mitarbeit!

Im Grunde bist du da auf Server Seite absolut flexibel. Es müssen eigentlich nur 2 Verbindungsarten unterstützt werden: Ed25519 und als Fallback RSA mit einem 4096 Bit Schlüssel, DSA und auch ECDSA sollten ausgeschlossen werden.
Ich habe gesehen, dass Apache SSHd verwendet wird, daher kann ich dir nicht genau sagen, wie man den damit füttert. Mit dem OpenSSH Server kann ich dir folgendes Script aus meiner eigenen Host Configuration liefern:


# Harden SSH server settings
rm -rf /etc/ssh/ssh_host_dsa*
rm -rf /etc/ssh/ssh_host_ecdsa*
if [[ ! -f /etc/ssh/ssh_host_rsa_key || $(ssh-keygen -lf /etc/ssh/ssh_host_rsa_key | cut -d " " -f 1) -lt 4096 ]]; then
  rm -f /etc/ssh/ssh_host_rsa*
  ssh-keygen -t rsa -b 4096 -f /etc/ssh/ssh_host_rsa_key -N "" -o -a 100
fi
if [[ ! -f /etc/ssh/ssh_host_ed25519_key || $(ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key | cut -d " " -f 1) -lt 256 ]]; then
  rm -f /etc/ssh/ssh_host_ed25519*
  ssh-keygen -t ed25519 -f /etc/ssh/ssh_host_ed25519_key -N "" -o -a 100
fi
if [ -f /etc/ssh/moduli ]; then
  awk '$5 >= 3071' /etc/ssh/moduli > /etc/ssh/moduli.safe
  mv -f /etc/ssh/moduli.safe /etc/ssh/moduli
fi
if [ ! -f /etc/ssh/sshd_config.bak ]; then
  mv /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
echo "Protocol 2
HostKey /etc/ssh/ssh_host_ed25519_key
HostKey /etc/ssh/ssh_host_rsa_key

StrictModes yes
PasswordAuthentication no
#PermitEmptyPasswords no
ChallengeResponseAuthentication no
UsePAM yes
PrintMotd no
PermitRootLogin without-password
AcceptEnv LANG LC_*
Subsystem   sftp   /usr/lib/openssh/sftp-server

# Crypto hardening
#
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
HostKeyAlgorithms ssh-ed25519,ssh-rsa
KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group-exchange-sha256
MACs hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,umac-128-etm@openssh.com

# Disable all forwarding methods
AllowTcpForwarding no
AllowStreamLocalForwarding no
GatewayPorts no
PermitTunnel no
AllowAgentForwarding no
X11Forwarding no" > /etc/ssh/sshd_config
fi
systemctl restart ssh


Wenn du dazu eine spezielle Doku brauchst, müsste ich googeln. Ansonsten ist "man ssh-keygen" und "man sshd_config" aber sehr hilfreich die Parameter zu entschlüsseln.




Den SSH Client Key generierst du ja für den Fall, dass der User noch keinen hat.
Das habe ich vor einiger Zeit schonmal in das FHEM Docker Image eingebaut, weshalb du dort spicken könntest:
https://github.com/fhem/fhem-docker/blob/2eeead5012188d802257136e6d77c1356aa826bb/src/entry.sh#L85-L122

Das SSH Key Pinning macht aber nur für das Image Sinn (und müsste ich auch aktualisieren, wenn du neue Server Keys generierst  ;) ). Ist auch nur dafür da, dass beim ersten Verbindungsaufbau sich auch niemand dazwischen hängen kann. Für den SSH Client ist "StrictModes yes" recht wichtig. Damit einige Optionen immer zur Anwendung kommen und du dem User das in der ~/.ssh/config nicht vorgeben kannst (man weiß ja nicht, was er noch für Verbindungen aufbauen will), solltest du diese Optionen beim Verbindungsaufbau mittels "-o" direkt mit übergeben (siehe "man ssh").

Zitat von: gvzdus am 14 Januar 2019, 18:06:54
Zu TLS: Fände ich gut, müsste aber Rudi König machen, denn der ist das "Gate". Das Abschalten der Alt-Protokolle TLSv1 & TLSv1.1 als Empfehlung kenne ich, setze es aber bei "meinen" Webservern nicht um, weil es Androids bis Lollipop ausschließt (Android bis inkl. 4.4).

Hatte ich bei der Umstellung auf den Vereinsserver schon erwähnt, wurde aber dann wohl nicht weiter beachtet. Ich kenne auch das genaue Setup von Markus nicht - möglich, dass man dabei auch das Setup aller anderen Vereinsseiten inkl. des Forum mit berücksichtigen müsste (bzw. ggf. entkoppeln mittels Offloading o.ä.). Ich will aber nicht ausschließen, dass Markus das eh auf seiner wohl eher laaaangen Todo Liste hat.
Zu Android 4.4 muss man IMHO nicht Rückwärts kompatibel sein - da wäre ich streng und würde sagen "da muss eh ein aktuelleres Gerät her" (wobei Android seine Aktualitäts- und Sicherheitsprobleme ohnehin nicht im Griff hat, aber das ist eine ganz andere Debatte  ;D ).

Zitat von: gvzdus am 14 Januar 2019, 18:06:54
Die Header-Thematik finde ich etwas übertrieben

War ja auch eher der Vollständigkeit halber. Der Nutzen bei Maschinen-Kommunikation ist auch nicht bei allem ganz so hoch wie bei manuellen Zugriffen.
Für die Registrierungsseite kann ich nochmal schauen und einen Vorschlag machen. Wenn du selbst schauen möchtest: Diesen Generator nutze ich gerne. HSTS kann man setzen, aber da man ohnehin über den Redirect dorthin gelangt ist das eher unwichtig.
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

rudolfkoenig

ZitatHatte ich bei der Umstellung auf den Vereinsserver schon erwähnt, wurde aber dann wohl nicht weiter beachtet.
"Nicht beachtet" ist nicht ganz richtig.
"Nach Kosten/Nutzen Analyze auf spaeter verschoben" trifft es eher.

Loredo

Wenn man keine weitere Rückmeldung erhält, dann lässt sich das leider nur schwer unterscheiden, Rudi.
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

Danke, ich setze zumindest EC statt RSA ganz hoch auf die Prio-Liste mit Commitment < 7 Tage.

Loredo

Ein solches Commitment ist jetzt übertrieben, aber schön, dass du eine Rückmeldung dazu gibst,, vielen Dank!  :)
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

Ich habe es mal auf die Schnelle probiert, und so ganz unverändert klappt es nicht, sich per Hand einen Ec25519-Key zu konfigurieren und dann zum Server zu gehen.

Der Grund ist hier zu finden:
https://github.com/apache/mina-sshd/blob/master/README.md

Sprich, ich muss noch weitere Module einbinden, was ich dann natürlich erst mal testen muss.

Loredo

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

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.

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