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.
> 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.
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 :-)
