Hallo, ich arbeite seit einiger Zeit an einem relativ aufwändigen ESP32-Projekt auf Arduino-Basis. Eine Kernkomponente ist eine mittlerweile umfangreiche HTTP REST API mit EspAsyncWebserver. Leider unterstützt der kein SSL (auf dem ESP8266 schon, aber die Antwortzeiten waren vollkommen inakzeptabel). Andere Lösungen für Arduino scheinen nur verlassene Projektruinen in der Wüste zu sein. Anfangs dachte ich zähneknirschend, dass ich verzichten kann. Mittlerweile kommen aber doch ein Paar sensiblere Daten zum Übertragen dazu. Bei IDF scheint der https server zumindest Herstellersupport zu haben und FreeRTOS macht im Nachhinein betrachtet auch mehr Sinn für mein Projekt (ich weiß, dass ich das auch unter Arduino nutzen kann). Ich bin allerdings jetzt doch einigen Bibliotheken aus dem Arduino-Framework verfallen, ArduinoJSON möchte ich ungern in meinen HTTP handlern missen und da es sich um ein LED-Projekt handelt, kann und will ich eigentlich nicht auf FastLED verzichten. Da gibt es einfach nichts, was ansatzweise so mächtig ist (lass mich da gerne korrigieren!). Ich könnte jetzt Arduino als component in IDF einbinden (muss ich eigentlich, weil ich praktisch nicht auf FastLED verzichten kann). Aber irgendwie wirkt das "falsch". Ich kann den Overhead nicht abschätzen und weiß auch nicht, welche Risiken das noch so bergen würde. Einen riesen Migrationsaufwand erwarte ich sowieso, dabei ist unverschlüsseltes HTTP das einzige, was mich an meinem Projekt wurmt gerade. Und nach meiner Erfahrung mit HTTPS unter ESP8266 fürchte ich, dass ich am Ende vor einem inakzeptablen Performanceeinbruch meiner REST-API (Latenzen) stehe. Am liebsten würde ich einfach in der Arduino-Welt bleiben und HTTPs ans Laufen kriegen. Ich weiß, dass in dem ganzen Getexte hier keine so richtig konkrete Fragestellung drin steckt. Meine Hoffnung ist, dass jemand mein Problem nachvollziehen und mir ein paar gute Denkanstöße geben kann.
Hast du schon mal über einen Reverse-Proxy und SSL offloading nachgedacht? Bei mir läuft z. B. ein Apache, der sich auch regelmäßig ein neues Zertifikat von Letsencrypt abholt. Der Traffic zwischen Reverse-Proxy und ESP läuft dann zwar immer noch unverschlüsselt im (verschlüsselten) WLAN - aber ich kenn jetzt auch deinen Anwendungsfall nicht, ob es dir darum geht, den ESP ins Internet zu hängen oder ob du den Traffic vom ESP einfach verschlüsseln möchtest, damit keiner im WLAN mithören kann. Gruß Roland
Oder wäre es eine Alternative die Daten direkt verschlüsselt zu übertragen? Der ESP32 hat doch einen extra core für Kryptographie soweit ich weiß.
hätte ich erwähnen sollen: die Kommunikation ist nur innerhalb des WLAN. Sicherheitsmäßig ist mein Problem überschaubar. Ich finde aber unverschlüsselte Kommunikation in IOT/Smart-Home-Devices heutzutage eigentlich nicht mehr akzeptabel. Zumal mein Web-Browser, über den ich mit dem ESP kommuniziere, auch sehr deutlich sagt, was er davon hält.
Oscar schrieb: > Ich finde aber unverschlüsselte Kommunikation in IOT/Smart-Home-Devices > heutzutage eigentlich nicht mehr akzeptabel Ja, das ist lobenswert 👍 > Zumal mein Web-Browser, über den ich mit dem ESP kommuniziere, auch sehr deutlich sagt, was er davon hält. Leider wird dir der Browser auch deutlich sagen, was er von dem Zertifikat hält, sofern du selbst signierte verwendest. Du müsstest den ESP dann regelmäßig mit einem offiziellen Zertifikat versorgen UND über einen dazu gültigen Domainnamen ansprechen. (Ja, das Problem wäre nicht unlösbar) Ewu schrieb: > Oder wäre es eine Alternative die Daten direkt verschlüsselt zu > übertragen? Ja, aber da müsste man dann wahrscheinlich ein eigenes Protokoll verwenden. Https am ESP wäre schon die sicherste Lösung, aber zum einen mit jeder Mengen Aufwand verbunden, zum anderen langsam. Vielleicht wird anders rum ein Schuh draus: der ESP verbindet sich ZU einem Server und empfängt darüber Befehle. Tasmota macht das z. B.: https://tasmota.github.io/docs/TLS/ Achtung: Sobald Zertifikate im Spiel sind (egal welche Richtung) - laufen diese irgendwann ab. Das muss man bedenken. Wenn die Updates dann auch noch signiert sein müssen, dann hat man u. U. ein Problem Gruß Roland
Roland P. schrieb: >> Zumal mein Web-Browser, über den ich mit dem ESP kommuniziere, auch sehr > deutlich sagt, was er davon hält. > > Leider wird dir der Browser auch deutlich sagen, was er von dem > Zertifikat hält, sofern du selbst signierte verwendest. > Du müsstest den ESP dann regelmäßig mit einem offiziellen Zertifikat > versorgen UND über einen dazu gültigen Domainnamen ansprechen. (Ja, das > Problem wäre nicht unlösbar) > Das weiß ich. Und ohne offizielle Domain sehe ich auch keine Lösung. Find ich aber akzeptabel. Selbst das Web-Frontend meines Routers hat dieses Problem.
Ewu schrieb: > Oder wäre es eine Alternative die Daten direkt verschlüsselt zu > übertragen? Was heißt "direkt verschlüsselt"? Einen Verschlüsselungsalgorithmus anzuwenden ist das eine, aber den Schlüssel sicher auszutauschen oder zu speichern das andere. Der Umgang mit dem Schlüssel ist der kompliziertere Teil, wenn es wirklich sicher sein soll. HTTPS ist da ja schon ein fauler Kompromiss. Ein eigenes Verfahren zu verwenden, dass überzeugt und doch effizienter ist, ist gar nicht so einfach. Aber durchaus machbar. Überlege dir nur, ob du dieses Fass wirklich aufmachen willst. Das weckt ganz schnell Begehrlichkeiten wo du am Ende sagst "hätte ich bloß ein fertiges Gateway von der Stange verwendet".
Vielleicht ist dein Projekt (wenn es um iot geht) mit ESPHome verwertbar?
Peter schrieb: > Vielleicht ist dein Projekt (wenn es um iot geht) mit ESPHome > verwertbar? ich versteh den Hinweis nicht so wirklich im Bezug auf mein Problem mit HTTPS. Kannst du das erläutern?
sieh dir mal Rust für Esp32 an https://github.com/esp-rs da findest du auch eine httpd Implementierung
Oscar schrieb: > hätte ich erwähnen sollen: die Kommunikation ist nur innerhalb des WLAN. > Sicherheitsmäßig ist mein Problem überschaubar. Ich finde aber > unverschlüsselte Kommunikation in IOT/Smart-Home-Devices heutzutage > eigentlich nicht mehr akzeptabel. Dann schalt halt WPA ein (ist wahrscheinlich schon an), dann hast du deine Verschlüsselung. Wenn die Kommunikation direkt ist (z.B. ESP32 als AP) mußt du nichtmal deinem "Router" trauen. > Zumal mein Web-Browser, über den ich mit dem ESP kommuniziere, auch > sehr deutlich sagt, was er davon hält. Der Browser ist diesbezüglich nicht kompetent.
foobar schrieb: > Oscar schrieb: >> hätte ich erwähnen sollen: die Kommunikation ist nur innerhalb des WLAN. >> Sicherheitsmäßig ist mein Problem überschaubar. Ich finde aber >> unverschlüsselte Kommunikation in IOT/Smart-Home-Devices heutzutage >> eigentlich nicht mehr akzeptabel. > > Dann schalt halt WPA ein (ist wahrscheinlich schon an), dann hast du > deine Verschlüsselung. Wenn die Kommunikation direkt ist (z.B. ESP32 > als AP) mußt du nichtmal deinem "Router" trauen. > >> Zumal mein Web-Browser, über den ich mit dem ESP kommuniziere, auch >> sehr deutlich sagt, was er davon hält. > > Der Browser ist diesbezüglich nicht kompetent. wie verhindert das man-in-the-middle-Angriffe?
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.