Firmware Update über Weboberfläche schlägt fehl

Kommt mir ein bisschen aufwändig vor ne parallelinfrastruktur für Firmware updates hinzustellen weil einmal in ein paar Jahren github seine cert root wechselt. Wenn du dich da berufen fühlst :wink:. Checkbox „release notes say I need to disable trust for this update“ erscheint mir da ausreichend. Wenn man will könnte man das Zertifikat fürs Update auch ganz ignorieren und die Firmware stattdessen signieren. Bin aber nicht sicher ob irgendeine technische Lösung für das Problem her muss, kaum jemand wechselt regelmäßig sein cert root. Und manuell runterladen und installieren sind nur ein paar klicks mehr.

Edit: grad noch ne idee gehabt nach Lektüre dieses Artikels noch einer evtl reicht spiffs : je nach dem, ob arduino tls damit umgehen kann wäre auf der sd Platz für die „vertrauenswürdigen“ root zertifikate aus nem browser oder einer Linux distro.

Wir können die Zertifikate auch von unserem Server nachladen. Ich hoffe aber wirklich, dass sich das Root Zertifikat nicht oft Ändert. Blöd ist halt, das GitHub das vermutlich nicht vorher ankündigt und wir das immer erst im Nachgang wissen.

Edit: wie groß ist denn der komplette cert store?

Bei unserem Server hätten wir das gleiche Problem - Letsencrypt könnte ja genauso seine root ändern. (es sei denn natürlich wir updaten das bei jedem Wlankontakt)

certs.ar mit dem pythonscript aus diesem post zusammengestellt ist 180kb groß und man könnte es auch automatisch im Buildprozess zusammenbauen so dass immer die aktuelle Mozilla certroot Datenbank verwendet wird.

Alternativ könnten wir den von-github-herunterladen mechanismus umbauen dass der Browser die neue Firmware herunterlädt und dann an den OBS postet, dann wird das Cert aus dem OS vom Browser verwendet. Das geht dann auch, wenn du’s am Handy machst und der Hotspot kein Internet hat aber das Handy Mobilnetz.

Aber um ehrlich zu sein finde ich den Aufwand, die Datei selbst runterzuladen und in der Weboberfläche auszuwählen überschaubar. Das ist einen aufwändigen Umbau oder gar eigene Infrastruktur (die wahrscheinlicher ausfällt als dass Github’s Root CA sich ändert) IMO nicht wert :man_shrugging:

Bei unserem Server hätten wir das gleiche Problem - Letsencrypt könnte ja genauso seine root ändern. (es sei denn natürlich wir updaten das bei jedem Wlankontakt)

Stimmt nicht ganz, wenn du eine eigene certificate chain mit custom CA aufbaust. Das mögen die Browser dann nicht („Verbindung ist nciht sicher!!!11einself!!“) aber das ist egal wenn das nur der OBS anspricht um sich Firmware zu laden, und das cert der custom CA dann im OBS liegt und sich nicht ändert. Auch hier: vermutlich sind wir irgedwann gezwungen das zu ändern, und dann war der ganze Tanz auch wieder für nichts. Überlassen wir es den Profis (LetsEncrypt, Github, DigiCert Inc,…) :wink:

1 „Gefällt mir“

Wenn du eh dein eigenes Zertifikat ausrollst nur für die Firmware kannst du es auch gleich self-signed machen und brauchst keine echte CA ausrollen :wink: aber genug SSL diskutiert. Wir wissen alle dass es ginge, aber IMHO haben wir jetzt auch schon mehrfach gesagt dass wir uns die eigene PKI nicht ans Bein binden wollen. Den Vorschlag mit dem automatischen Browserupload finde ich am attraktivsten - Obwohl auch da der der Zeitaufwand vermutlich in keinem Verhältnis zum Nutzen steht.

Bei der ganzen Diskussion um das Update der Firmware fehlt das Thema Upload in die Portale über den OBS. Jedes Portal kann am Ende eine andere Root benötigen, und dann bringt auch eine eigene PKI nichts. Wir sollten definitiv LE empfehlen, da wir deren Root haben.

Bei den Portalen sehe ich Let’s Encrypt tatsächlich gesetzt. Falls jemand Lust hat, sich mal um die Weboberfläche des OBS zu kümmern nur vor :), tatsächlich wird die Erkennung der aktuellen Version auch im Browser gemacht, nur der Download passiert dann innerhalb des OBS.

Bei 180KB CA Zertifikate könnte es am RAM scheitern. Mal sehen.

Ok, alle zu holen ist nicht zielführend. Ich hab die Certs unter „CA/Included Certificates - MozillaWiki“ - „PEM of Root Certificates in Mozilla’s Root Store with the Websites (TLS/SSL) Trust Bit Enabled“ (212KB) geholt und in die Firmware eingebunden, das führt beim Zugriffsversuch dann zu einem X509 - Allocation of memory failed. Da lässt sich sicher noch etwas optimieren, aber mit wenig Aussicht auf Erfolg und dann immer mit dem Risiko, dass es irgendwann doch bricht.

Der Download über den Browser wie von @opatut vorgeschlagen ist da sicherlich zielführender und eine dauerhafte Lösung.

So schlimm ist das auch nicht, das werden ca. 20-30 Zeilen (nicht besonders schönes aber sehr funktionales) JavaScript sein :man_shrugging: Ich kann’s mal versuchen bei Gelegenheit.

2 „Gefällt mir“

LetsEncrypt hat vor ein paar Wochen seine CA Chain gewechselt. Ist überall in der Regel nach 10 Jahren fällig. Das macht halt irgendwann Arbeit.
Ausser man baut eine PKI mit subCAs, die ausstellen und von der RootCA signiert sind. Hier geht das etwas geschmeidiger.

@nofkabu Kannst du das „hat seine CA Chain gewechselt“ genauer ausführen?
Die Letsencrypt root ISRG Root X1 ist seit 2015 und noch bis 2035 gültig Ich hab in den letzten paar Wochen keine Änderung am Letsencrypt root gesehen - Meine Zertifikate von Anfang Februar und Anfang April sind beide mit Ketten, die im ISRG Root X1 münden signiert. Und beide auch vom intermediate Zertifikat R3. Würde mich interessieren, was die genau geändert haben.

@gluap siehe hier: Let's-Encrypt-Zertifikate: Ruckler am 30. September möglich | heise online

@nofkabu Aber auch bei einer eigenen PKI wird irgendwann das Root-Zertifikat der Chain irgendwann auslaufen - oder was vergesse ich etwas?

Der Kreis der Beteiligten und zu änderenden Trusts ist im Vergleich zu einem „offiziellen“ Root CA File aber überschaubar.

Gibts schon eine Lösung? 1. Über die Weboberfläche ist bei mir kein update möglich 2. Ich finde die firmware.bin in Github nicht zum direkten File Upload (blind chicken?) 3.Ich kann nur mit Safari einen Zugang zu meinem OBS erhalten, über Chrome funktioniert das nicht…

@pepponia
Für das erste Update nach dem Zertifikatswechsel ist es technisch unmöglich anders als mit manuellem upload wieder aus der Situation raus zu kommen - die ganze Diskussion über CAs bezieht sich darauf wie das Problem in Zukunft vermieden werden kann, da es theoretisch wieder auftreten kann und wird, aber praktisch sehr selten auftritt. Und keiner weiß, ob wir in 10 Jahren noch mit 2022er OBS herumfahren…

DIe firmware.bin findest du unten am aktuellen release - derzeit 14.731: Releases · openbikesensor/OpenBikeSensorFirmware · GitHub

Hochladen kannst du sie dann im normalen upload dialog:

Dankeeee! Wie immer rasch und kompetent :blush:

@gluap Wollen wir den Thread auftrennen?

Hat jetzt alles funktioniert! Danke

1 „Gefällt mir“