Hallo zusammen, ich habe ein embedded System entwickelt, dass leider nur einen Monat funktioniert hat. Der Grund ist der, dass mein mqtt-Broker hinter einem Reverse Proxy steht der sich über den Service von let's encrypt SSL-Zertifikate ausstellen lässt, die leider nur drei Monate halten und mein System den public Key im Sourcecode hinterlegt hat. Ich habe nach einer Lösung gesucht tatsächlich scheint es kein einfaches Problem zu lösen zu sein. Google selbst hat das Problem LTS-Domainen (Long Term Support Domains) gelöst. Letztendlich ist es ein selbst signiertes Zertifikat, dass erst im nächsten Jahrhundert abläuft. Was an sich auch vollkommen ausreicht, da ein Browser mit mqtt eh nichts Anfangen kann und man selber vertraut seinem eigenen Zertifikat schließlich, da benötigt man auch keinen CA-Root-Server zu. Der Nachteil, liegt auf der Hand: sollte einer mal an den private Key kommen, dann wäre das sehr fatal. Was haltet Ihr von dieser Lösung? Habt ihr vielleicht schon an Erfahrungen in die Richtung gemacht? Wie habt Ihr das Problem gelöst? LG, Sebastian
Sebastian M. schrieb: > Was haltet Ihr von dieser Lösung? Wenig. Mach's doch lieber sauber, und wenn Du keine riesige Sammlung von Root-Zertifikaten mit Dir herumschleppen willst, nimmst Du nur das von Let's Encrypt (ISRG Root X1).
Hmmm schrieb: > Mach's doch lieber sauber, und wenn Du keine riesige Sammlung von > Root-Zertifikaten mit Dir herumschleppen willst, nimmst Du nur das von > Let's Encrypt (ISRG Root X1). Das verschiebt das grundsätzliche Problem nur rund vier Jahre in die Zukunft:
1 | Data: |
2 | Version: 3 (0x2) |
3 | Serial Number: |
4 | 91:2b:08:4a:cf:0c:18:a7:53:f6:d6:2e:25:a7:5f:5a |
5 | Signature Algorithm: sha256WithRSAEncryption |
6 | Issuer: (CA ID: 7394) |
7 | commonName = ISRG Root X1 |
8 | organizationName = Internet Security Research Group |
9 | countryName = US |
10 | Validity |
11 | Not Before: Sep 4 00:00:00 2020 GMT |
12 | Not After : Sep 15 16:00:00 2025 GMT |
13 | ... |
Für viele Embedded-Geräte sind vier Jahre Betrieb nicht viel. Also mindestens auch ISRG Root X2 mit rein:
1 | Data: |
2 | Version: 3 (0x2) |
3 | Serial Number: |
4 | 41:d2:9d:d1:72:ea:ee:a7:80:c1:2c:6c:e9:2f:87:52 |
5 | Signature Algorithm: ecdsa-with-SHA384 |
6 | Issuer: (CA ID: 183269) |
7 | commonName = ISRG Root X2 |
8 | organizationName = Internet Security Research Group |
9 | countryName = US |
10 | Validity |
11 | Not Before: Sep 4 00:00:00 2020 GMT |
12 | Not After : Sep 17 16:00:00 2040 GMT |
13 | ... |
Damit hast du das Problem rund 19 Jahre in die Zukunft geschoben. Wenn du Cert-Pinning machst dann ist dein Problem in 19 Jahren eventuell, dass du plötzlich 19 Jahre alten Sourcecode finden, ändern, compilieren und auf den Sensor programmieren musst. Vielleicht schmeißt Let's Encrypt auch schon viel früher das Handtuch. Also doch besser zur Absicherung von Außen nachinstallierbare Zertifikate? Damit bist du wieder am Anfang, denn wie willst du diese Änderung absichern? Kurz und gut, es gibt keine richtige Lösung. Ach ja, zusätzlicher Spaß, für das X2 Zertifikat darfst du weitere Ciphersuites implementieren.
:
Bearbeitet durch User
> ein selbst signiertes Zertifikat, dass erst im nächsten Jahrhundert > abläuft. > Was haltet Ihr von dieser Lösung? Der Unterschied liegt ja nur darin, wer das Zertifikat signiert hat, ein Fremder oder du. Der Vorteil des "Fremden" liegt nur darin, dass der in den Browsern hinterlegt ist, die Benutzer dem trauen und dann keine Zwischenfragen kommen. Ein Eigenzertifikat muß ggf manuell "erlaubt" werden. Wenn das kein Problem ist, ist das sicherer als jedes Fremdzertifikat. Außerdem muß es ja nicht self-signed sein - ein eigenes Root-Zertifikat ist schnell erstellt ... > Der Nachteil, liegt auf der Hand: sollte einer mal an den private > Key kommen, dann wäre das sehr fatal. Wenn der Private-Key bekannt wird, ist das immer fatal - da spielt es keine Rolle, wer signiert hat.
Hannes J. schrieb: > Das verschiebt das grundsätzliche Problem nur rund vier Jahre in die > Zukunft Nein. Das Root-Zertifikat (X1) ist noch bis 2035 gültig (self-signed), nur das Intermediate Cert (R3) läuft 2025 aus. Es ist aber nirgendwo die Rede davon, dass man danach auf X2 (und somit ECDSA) wechseln würde. Hannes J. schrieb: > Kurz und gut, es gibt keine richtige Lösung. Auf jeden Fall gehören Updates mit ins Konzept, ansonsten ist ein langfristiger Betrieb über öffentliche Netze ohnehin nicht sinnvoll.
Das Device ist OTA-Update fähig. Wenn ich den public key stetig über die Updates erneure habe ich nur dann ein Problem, wenn ein Device nicht rechtzeitig das Update herunterlädt, da der Website die das Update zur Verfügung stellt nicht mehr vertraut wird und somit kein Download mehr möglich ist. Die Zertifikate könnte ich selber signieren so kann ich in den Transitzeiten in denen noch das alte Zertifikat gilt aber das neue schon in den Updates vorkommt schon beide Zertifikate erstellt haben. Ich könnte wohl auch mit Hilfe des Certbots an die Zertifikate kommen, nur verstehe ich (noch) nicht wie ich eine Domaine die einen AAAA Record auf einen Server hat auf dem ein Reverse Proxy ist der die Anfrage auf 443 auf einen mqtt Server umlenkt eine ACME-Challenge laufen lassen kann ohne den Service offline zu nehmen. Vielleicht müsste ich port 80 woanders hin leiten nach meiner Recherche nach ein MinIO Server? Auf jeden fall scheint es mir mehr und mehr ein eigenes Projekt zu sein Let's encrypt dort in den Loop zu nehmen. Also tendiere ich zu der ersten Lösung. Also OTA-Updates mit Zertifikat Updates und sollte das Device eine längere Zeit nicht in betrieb genommen wurden sein, kann das System sich nicht mehr alleine Updaten.. Irgendwie auch keine gute Lösung
Sebastian M. schrieb: > Das Device ist OTA-Update fähig. Wenn ich den public key stetig über die > Updates erneure habe ich nur dann ein Problem, wenn ein Device nicht > rechtzeitig das Update herunterlädt, da der Website die das Update zur > Verfügung stellt nicht mehr vertraut wird und somit kein Download mehr > möglich ist. Es sei denn, Du nutzt für die Firmware-Updates kein HTTPS, sondern nacktes HTTP mit signierten (und evtl. verschlüsselten) Firmware-Files. Oder Du arbeitest wie die meisten CAs mit Intermediate Certs. Das Root-Cert bleibt "ewig" gültig, aber der Key landet offline im Safe, nachdem Du damit die Intermediate CA aufgesetzt hast. Sebastian M. schrieb: > Vielleicht müsste ich port 80 > woanders hin leiten Für ACME-Updates per HTTP-Challenge reicht das, Port 443 wird nicht benötigt. Ich würde den MQTT-Server allerdings nicht auf Port 443 laufenlassen, wenn es nicht unbedingt notwendig ist. Ansonsten hast Du laufend ungewollte Connections, auf unüblichen Ports ist das Grundrauschen niedriger.
Wer soll denn von außen auf diesen MQTT-Broker zugreifen? Sind das nur Deine Embedded-Geräte oder noch was anderes? Wenn es nur Deine Embedded-Geräte sind, würde ich vorschlagen eine eigene CA zu erstellen. Diese CA hat einen extremen Gültigkeitszeitraum, z.B. von 01.01.1970 bis 31.12.2050 oder so. Damit bekommst Du auch keine Probleme mit falsch laufenden RTCs. Mit dieser CA stellst Du dann einen Schlüssel für den MQTT-Broker aus, meinetwegen 1 Jahr gültig oder so. In Deinem Embedded-Gerät hinterlegst Du jetzt fest das Cert Deiner CA und vertraust den von dieser CA ausgestellten Zertifikaten. Die CA selbst packst Du auf einen separaten Rechner oder Festplatte und hälst den Air-Gapped. Mehrere Kopien an verschiedenen Orten aufbewahren. Dann geht der Schlüssel weder verloren, noch kann jemand anderes so leicht an den ran. Außerdem würde ich darauf achten, daß Deine Embedded-Geräte bei ihren Zugriffen immer Server Name Indication (SNI) mitsenden. Dann gibst Du dem Server per CNAME einen Alias-Namen, der nur für die Zugriffe von den Embedded-Geräten genutzt wird und stellst das Cert auf diesen Namen aus. Sollten dann mal andere Geräte auch noch zugreifen sollen und die dann eine Cert von einer klassischen CA fordern oder ähnliches, kannst Du die über einen anderen CNAME-Hostnamen zugreifen lassen und denen anhand des SNI ein anderes Cert präsentieren.
:
Bearbeitet durch User
Hmmm schrieb: > Es sei denn, Du nutzt für die Firmware-Updates kein HTTPS, sondern > nacktes HTTP mit signierten (und evtl. verschlüsselten) Firmware-Files. Das scheint mir gängige Praxis zu sein. Manche yum und apt repos sind auch nur auf http. Man könnte z.B. durch ein einfaches Http-Auth auf die Firmware zu greifen. Hmmm schrieb: > Oder Du arbeitest wie die meisten CAs mit Intermediate Certs. Das > Root-Cert bleibt "ewig" gültig, aber der Key landet offline im Safe, > nachdem Du damit die Intermediate CA aufgesetzt hast. Das klingt allerdings besser & ich könnte das immer noch mit der HTTP-Auth machen. Also verstehe ich das richtig, dass wenn man den Public Key von einem Zertifikat hat, dass ein anderes Zertifikat signiert hat, dann vertraut man diesem auch? Also wenn ich euch richtig verstehe dann würdet Ihr ein eigenes Root-Zertifikat ausstellen?
Sebastian M. schrieb: > Also verstehe ich das richtig, dass wenn man den > Public Key von einem Zertifikat hat, dass ein anderes Zertifikat > signiert hat, dann vertraut man diesem auch? Das ist eine Hierarchie. Der Server präsentiert Dir seinen Public Key mit einem Zertifikat, in dem die Intermediate CA bestätigt, dass er wirklich er selbst ist. Da Du diese Intermediate CA nicht kennst, liefert er ein weiteres Zertifikat mit, das beweist, dass die Root-CA ihr (zeitlich befristet) ausreichend vertraut, um sie Zertifikate ausstellen zu lassen. Sebastian M. schrieb: > Also wenn ich euch richtig verstehe dann würdet Ihr ein eigenes > Root-Zertifikat ausstellen? Bequemer ist die Variante mit Let's Encrypt (auch da das Root-Zertifikat, sonst knallt es wirklich schon in 4 Jahren), aber wenn Du mit einer eigenen CA arbeiten willst, dann so. So hast Du den Vorteil, mit langen Laufzeiten arbeiten zu können, ohne dabei die Sicherheit zu opfern. Bei Bedarf kannst Du die ganze Intermediate CA abklemmen und mit dem Key aus dem Safe eine neue aufsetzen, der die Geräte ohne Notwendigkeit eines Updates vertrauen.
Sebastian M. schrieb: > Hmmm schrieb: >> Es sei denn, Du nutzt für die Firmware-Updates kein HTTPS, sondern >> nacktes HTTP mit signierten (und evtl. verschlüsselten) Firmware-Files. > > Das scheint mir gängige Praxis zu sein. Manche yum und apt repos sind > auch nur auf http. Keine gute Idee, denn das ermöglicht dann Downgrade-Attacken: - Du bringst Firmware-Update Nr. 1 raus, signierst es und stellst es auf den Update-Server - Ein paar Clients installieren das noch nicht, z.B. wegen Netzwerkschwierigkeiten oder was auch immer - Du findest eine Sicherheitslücke. Du patchst sie und bringst Update Nr. 2 raus, signierst es und stellst es auf den Update-Server - Wenn ein Angreifer die HTTP-Verbindung manipulieren kann, z.B. weil er einen Router auf dem Weg kontrolliert, kann er weiterhin Update 1 verbreiten. Es ist weiterhin signiert, die Clients spielen es ein sobald sie die Verbindung aufbauen können. - Der Angreifer kann sich jetzt die Sicherheitslücke zunutze machen Wenn man die Versionsnummer nicht mit in den signierten Teil des Updatefiles reincodiert und der Updater sicherstellt nur größere Versionsnummern einzuspielen, kann man auf dem Wege sogar Clients, die bereits Version 2 haben, wieder auf Version 1 downgraden lassen. Von daher macht ein Updateserver mit HTTPS und Zertifikatsprüfung mehr Sinn. Die Updatepakete signieren kann man natürlich zusätzlich noch für ein weiter erhöhtes Sicherheitsniveau.
Sebastian M. schrieb: > Der Grund ist der, dass mein mqtt-Broker hinter einem Reverse Proxy > steht der sich über den Service von let's encrypt SSL-Zertifikate > ausstellen lässt, die leider nur drei Monate halten und mein System den > public Key im Sourcecode hinterlegt hat. Du brauchst letsencrypt hier vermutlich gar nicht. Das ist sogar gefährlich wenn jemand drittes für deine Systeme certs ausstellen kann. Bau deine eigene CA auf. Sebastian M. schrieb: > Wie habt Ihr das Problem gelöst? Lass dich von Spezialisten beraten. Security ist nicht trivial. Da kann viel schief gehen. Insbesondere deine Fehlerbeschreibung oben zeigt, dass du noch wenig Erfahrung damit hast. Das ist nicht schlimm, aber du solltest handeln.
Hi! zur Info - du kannst statt der Challenge auch DNS Einträge zur Authentifizierung der Domain übernehmen. Tools wie acme.sh haben sogar eine DNS API (https://github.com/acmesh-official/acme.sh/wiki/dnsapi). Ich würde aber eine eigene CA mit einer CRL (Zertifikatswiederrufsliste) bauen. Dann kannst du bei kompromittierten Private Key auch ein Zertifikat zurück rufen und auf ein neues Umstellen. Lg
Und das alles wahrscheinlich, um so etwas wie die Wassertemperatur des Fischteiches zu übertragen ... und beim Telefonieren wird unverschlüsseltes SIP benutzt ...
foobar schrieb: > [...] Wassertemperatur des Fischteiches zu übertragen ... > [...] unverschlüsseltes SIP benutzt ... You made my Day. Aber: irgendjemand muss es doch den grossen vor machen! Dann wird irgendwann - so in 10-15 Jahren, wenn es den grossen Aufschreib gab, doch mal flächendeckend RTPS genutzt :-)
Thread beobachten
Seitenaufteilung abschaltenBitte 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.