Guten Morgen, ja klar, mit App und Cloud funktioniert alles, irgendwie, egal. Aber manche Leute wollen ihre Heizung, Kaffeemaschine, Türklingel... nicht ins Internet lassen und trotzdem ein buntes Bild vom integrierten Webserver anschauen. Oder ihr Oszilloskop im Browser bedienen (der Nachbar-Thread brachte mich zu dieser Frage). Wie wird das gemacht und was wird in Zukunft noch funktionieren? HTTP wird von den Browsern zunehmend verweigert, wird das trotzdem noch benutzt? Für HTTPS braucht die Heizung ein Zertifikat - kein Problem, solange die sowieso ständig online ist. Wenn nicht, wird ein "echtes" Zertifikat nach spätestens einem Jahr ungültig. Gibt es Geräte, bei denen der Benutzer das updaten muss/kann? Der Hersteller könnte mit einer eigenen CA Zertifikate mit beliebigem Ablaufdatum erstellen oder self signed benutzen. In beiden Fällen muss der Benutzer den Browser überreden, das zu akzeptieren. Die Meldungen des Browsers sind aber wenig hilfreich, irreführend und abschreckend. Geht das irgendwie benutzerfreundlicher? Ein paranoider Benutzer müsste überprüfen, ob er wirklich mit seiner Heizung verbunden ist. Die Heizung kann ihm aber mangels Internet keine Mail schicken und er würde der Mail sowieso nicht trauen. Also müsste er sich per USB-Stick etwas wie eine Signatur von seiner Heizung holen. Was könnte die Heizung ihm anbieten? Eine Firma mit eigener IT-Abteilung kann eine eigene CA betreiben und das root-Zertifikat auf jedem PC installieren und das Gegenstück auf jedem Gerät. Die FritzBoxen unterstützen das anscheinend, aber sonst? Geht das, wird das gemacht?
Einfach in der Zertifikatsverwalting des Browsers Ausnahmen hinzufügen.
Zertifikate haben ein endliches Ablaufdatum. Im Browser Ausnahme erlauben ist möglich. Zu denken gibt mir nur, dass ein Haus 100 Jahre steht und manches Betriebssystem schneller updatet/wechselt als Bill Gates seine Socken. Ob dann noch alles wie geplant funktioniert?
Wasch mir den Pelz, aber mach mich nicht nass. Denn darauf läuft es hinaus. Du willst die Sicherheit von HTTPS, dann hast du auch die Nachteile davon am Hals. Bauform B. schrieb: > manche Leute wollen ihre Heizung, Kaffeemaschine, Türklingel... nicht > ins Internet lassen und trotzdem ein buntes Bild vom integrierten > Webserver anschauen. Oder ihr Oszilloskop im Browser bedienen (der > Nachbar-Thread brachte mich zu dieser Frage). Wie wird das gemacht und > was wird in Zukunft noch funktionieren? Wenn der Rotz kein HTTPS kann, und du im Internet HTTPS machen willst, dann setzt du im Heimnetz einen Proxy davor der HTTPS mit gültigem Zertifikat kann. Übrigens reicht HTTPS alleine nicht aus um Zeug wie die Kaffeemaschine sicher ins Internet zu bringen. Da sollte schon eine Authentifizierung mit dabei sein. Alternativ: VPN ins Heimnetz. > HTTP wird von den Browsern zunehmend verweigert, wird das trotzdem noch > benutzt? Browser können das immer noch. Mein aktueller Stand ist dass sie mittlerweile per Default HTTPS versuchen, auch wenn die Webseite gar nicht HSTS fordert und nur wenn HTTPS nicht geht auf HTTP zurückfallen - eventuell mit einer Warnung. Allerdings machen rund 28% der öffentlichen Websites sowieso HSTS, und 85% haben HTTPS als Default https://w3techs.com/technologies/overview/site_element > Für HTTPS braucht die Heizung ein Zertifikat - kein Problem, solange die > sowieso ständig online ist. Wenn nicht, wird ein "echtes" Zertifikat > nach spätestens einem Jahr ungültig. Das ist nur eine Konvention. Zertifikate können mit längerer Gültigkeit ausgestellt werden, was die Sicherheit der Zertifikate einschränkt. > Gibt es Geräte, bei denen der > Benutzer das updaten muss/kann? Wenn es richtig gemacht wurde (bei SmartHome Rotz häufig nicht), dann gibt es einen automatischen Zertifikaterneuerungs-Mechanismus. Der bekannteste im Heimbereich dürfte Let's Encrypt sein. Für große IoT-Flotten werden allerdings andere Erneuerungs-Mechanismen verwendet. Da gibt es dann so lustiges wie RFC7030 oder über Mobilfunk, oder was proprietäres. Wenn du Pech hast musst du es händisch machen. Wenn du viel Pech hast ist das Zertifikat nicht erneuerbar und du kannst den SmartHome Rotz wegwerfen. > In beiden Fällen muss > der Benutzer den Browser überreden, das zu akzeptieren. Die Meldungen > des Browsers sind aber wenig hilfreich, irreführend und abschreckend. Das ist Absicht. Hat ein Hacker den Benutzer erst man davon überzeugt seine eigene Root-CA zu akzeptieren, dann kann er sehr viel Spaß haben. > Geht das irgendwie benutzerfreundlicher? Let's Encrypt. > Ein paranoider Benutzer müsste überprüfen, ob er wirklich mit seiner > Heizung verbunden ist. Er könnte es einfach aus dem Heimnetz heraus machen. > Was > könnte die Heizung ihm anbieten? Warum sollte sie ihm was anbieten. > Eine Firma mit eigener IT-Abteilung kann eine eigene CA betreiben Machen große Konzerne. > und > das root-Zertifikat auf jedem PC installieren Machen sie meist nicht, außer sie wollen wirklich den Traffic der Mitarbeiter mitschnüffeln. Was sie häufig machen ist sich ihr CA-Zertifikat von einer bekannten öffentlichen CA, die von Browsern etc. akzeptiert wird, gegen viel $$$ signieren lassen. Dann generieren sie mit ihrer CA eigne Zertifikate für ihre Server und installieren diese und die notwendigen Intermediate Zertifikate auf den Servern.
Hannes J. schrieb: > Du willst die Sicherheit von HTTPS, dann > hast du auch die Nachteile davon am Hals. Wobei HTTPS mit Pseudo-Zertifikaten immerhin verhindert, dass nicht dazu autorisierte Familienmitglieder auch praktisch ohne tieferen Kenntnis im Netz Klartext mitlesen können.
Hannes J. schrieb: >> und das root-Zertifikat auf jedem PC installieren > > Machen sie meist nicht, außer sie wollen wirklich den Traffic der > Mitarbeiter mitschnüffeln. Wobei eine eigene Root-CA bei einer Windows Infrastruktur nicht weiter kompliziert ist.
Smarthome heute bedeutet in der Regel, dass ein Gerät sich mit einer Herstellerinfrastruktur verbindet und der Anwender dort zugreift; Das sichert die ~Abhängigkeit~ Kundenbindung. Dabei ist der Userzugriff auf den Server beim Hersteller (per Browser) über eine öffentliche CA (Verisign, Let's Encrypt, etc) signiert. Lokale Zugriff im Smarthome sind bisher nicht gut gelöst. Ein öffentliches Zertifikat (z.B. mit Let's Encrypt) geht nicht, da die CA es nicht verifizieren kann und eine Abhängigkeit zur Namensauflösung bei dir zuhause besteht. Unverschlüsseltes HTTP geht (zumindest noch) ist aber unschön. Zertifikatswarnungen wegzuklicken oder individuelle Gerätezertifikate/Hersteller-CAs als vertrauenswürdig zu installieren ist unpraktisch und wirkt nicht vertrauenswürdig
> Machen sie meist nicht, außer sie wollen wirklich den Traffic der > ... Was sie häufig machen ist sich ihr > CA-Zertifikat von einer bekannten öffentlichen CA, die von Browsern etc. > akzeptiert wird, gegen viel $$$ signieren lassen. Dann generieren sie > mit ihrer CA eigne Zertifikate für ihre Server und installieren diese > und die notwendigen Intermediate Zertifikate auf den Servern. Nicht wirklich. Meißt wird einfach nur eine eigene CA als vertrauenswürdig auf die Clients verteilt und damit signiert.
(prx) A. K. schrieb: > Wobei eine eigene Root-CA bei einer Windows Infrastruktur nicht weiter > kompliziert ist. Das Problem liegt in dem Aufwand, das Ganze sicher gegen Sabotage von innen und außen zu machen.
Hannes J. schrieb: > Wenn es richtig gemacht wurde (bei SmartHome Rotz häufig nicht), dann > gibt es einen automatischen Zertifikaterneuerungs-Mechanismus. Der > bekannteste im Heimbereich dürfte Let's Encrypt sein. ...der in diesem Fall wenig bringt, weil Du für die RFC1918-Adresse Deiner Smarthome-Kiste kein Zertifikat bekommst. Liesse sich zwar theoretisch lösen, wenn Du eine eigene Domain und entweder die Möglichkeit hast, DNS-Challenges in die Zone zu packen, oder mit Split-Horizon DNS arbeitest, aber beides dürfte Otto Normalverbraucher deutlich überfordern.
Rolf schrieb: > Das Problem liegt in dem Aufwand, das Ganze sicher gegen Sabotage von > innen und außen zu machen. Das hat dann aber mehr mit Windows/Microsoft allgemein als mit Zertifikaten zu tun.
:
Bearbeitet durch User
Private IP 192.168.x.x gibt es Millionenfach doppelt. Deswegen bezweifle ich dass ein Zertifikat dafür wirklich sicher sein könnte. Eher pseudosicher wie ein Schild "Tür verschlossen".
Was hat eine solche IP-Adresse mit einem Zertifikat zu tun?
Hmmm schrieb: > Hannes J. schrieb: >> Wenn es richtig gemacht wurde (bei SmartHome Rotz häufig nicht), dann >> gibt es einen automatischen Zertifikaterneuerungs-Mechanismus. Der >> bekannteste im Heimbereich dürfte Let's Encrypt sein. > > ...der in diesem Fall wenig bringt, weil Du für die RFC1918-Adresse > Deiner Smarthome-Kiste kein Zertifikat bekommst. > > Liesse sich zwar theoretisch lösen, wenn Du eine eigene Domain und > entweder die Möglichkeit hast, DNS-Challenges in die Zone zu packen, > oder mit Split-Horizon DNS arbeitest, aber beides dürfte Otto > Normalverbraucher deutlich überfordern. DNS geht anscheinend auch einfacher. Bei regfish kann ich beliebige Adressen ins DNS eintragen, also habe ich jetzt eine de-Domain für 192.168.178.39. Firefox löst das richtig auf, zeigt seine Warnung und akzeptiert ein selbstgemachtes Zertifikat, in dem nichts stimmt, außer IP Address unter Subject Alt Names. Vor allem steht eine andere Phantasie-TLD im Zertifikat :) Sehr konsequent, ich habe ja "ich akzeptiere das Risiko" geklickt. Reverse Lookup geht natürlich nicht, braucht man das? Wenn letsencrypt auch die lokale Adresse akzeptiert fehlt nur noch eine Kleinigkeit:
1 | To use Certbot, you'll need... |
2 | an HTTP website |
3 | that is already online |
4 | with an open port 80 |
Das muss ja nicht meine Heizung sein. Wie unmoralisch wäre das, wenn ich es spaßeshalber mal probiere? Automatisches Update geht so nicht, weil die Heizung ja gerade nicht ins Internet darf, am besten physikalisch isoliert. Manuell wäre es wohl möglich, aber wer will sich den Aufwand antun? Jörg schrieb: > Smarthome heute bedeutet in der Regel, dass ein Gerät sich mit einer > Herstellerinfrastruktur verbindet und der Anwender dort zugreift; Das > sichert die ~Abhängigkeit~ Kundenbindung. Also dafür wurde HTTPS erfunden ;) Vielen Dank für die vielen ausführlichen Hintergrundinformationen!
Bauform B. schrieb: > DNS geht anscheinend auch einfacher. Bei regfish kann ich beliebige > Adressen ins DNS eintragen, also habe ich jetzt eine de-Domain für > 192.168.178.39. Damit bekommst Du aber kein LE-Zertifikat, das geht nur mit den o.g. Methoden. Bauform B. schrieb: > Wenn letsencrypt auch die lokale Adresse akzeptiert Selbst wenn es nicht direkt eine Fehlermeldung gibt, wie soll LE für die Challenge dorthin connecten? Sicher, dass Du die Funktionsweise von LE verstanden hast? Entweder DNS-Challenge oder Split-Horizon DNS, sonst wird das nichts.
Hmmm schrieb: > Bauform B. schrieb: >> Wenn letsencrypt auch die lokale Adresse akzeptiert > > Selbst wenn es nicht direkt eine Fehlermeldung gibt, wie soll LE für die > Challenge dorthin connecten? äh, ja, also... ach, irgendwas ist immer :) War ja auch nur Spaß. Kein Spaß ist, dass es wirklich ein Argument für die Cloud gibt. Hannes J. schrieb: > Bauform B. schrieb: >> Ein paranoider Benutzer müsste überprüfen, ob er wirklich mit seiner >> Heizung verbunden ist. > Er könnte es einfach aus dem Heimnetz heraus machen. Waren diese Zertifikate nicht (auch) dafür gedacht? Das irritiert mich auch beim Online-Banking. Ich meine, ein formal gültiges Zertifikat sagt doch nicht, dass ich mit dem richtigen Rechner verbunden bin?
Bauform B. schrieb: > Ich meine, ein formal gültiges Zertifikat sagt > doch nicht, dass ich mit dem richtigen Rechner verbunden bin? Genau darum geht es bei Web-Zertifikaten eigentlich. Du bist mit sehr hoher Sicherheit mit einem System verbunden, das den Key zu dem Zertifikat im Bauch hat, das auf den Namen der Webseite lautet. Idealerweise ist das nur dieses eine System.
:
Bearbeitet durch User
Bauform B. schrieb: > Ich meine, ein formal gültiges Zertifikat sagt > doch nicht, dass ich mit dem richtigen Rechner verbunden bin? Das Zertifikat sagt aus, dass eine CA, der Du vertraust, bestätigt, dass derjenige, der das Zertifikat ausgestellt bekommen hat, die Kontrolle über den FQDN, den Du eingetippt hast, hat bzw. hatte. Bestätigt wird das bei LE entweder durch eine HTTP-Challenge (Du musst die Kontrolle über einen unter diesem FQDN laufenden und öffentlich erreichbaren Webserver haben) oder durch eine DNS-Challenge (Du musst Änderungen an der DNS-Zone vornehmen können). Wenn Du den falschen FQDN eintippst (www.sparkasse.ru oder so), hilft das natürlich nicht.
:
Bearbeitet durch User
Je nach Zertifizierer und Zertifikat reicht es, eine Mail an den Hostmaster der Domain empfangen zu können. Aber das kostet dann halt.
:
Bearbeitet durch User
(prx) A. K. schrieb: > Je nach Zertifizierer und Zertifikat reicht es, eine Mail an den > Hostmaster der Domain empfangen zu können. Das reicht eigentlich für alle manuell angeforderten "domain-validated" Zertifikate aus. Allerdings wollen die Anbieter Geld dafür, die meines Wissens einzige Ausnahme StartCom wurde den Browserherstellern irgendwann zu unseriös.
Bauform B. schrieb: > Wenn nicht, wird ein "echtes" Zertifikat > nach spätestens einem Jahr ungültig. Ein selbstsigniertes Zertifikat (was anderes kommt in dem Fall ja kaum in Frage) kann auch Jahrzehnte gültig sein. Oliver
Bauform B. schrieb: > Waren diese Zertifikate nicht (auch) dafür gedacht? Das irritiert mich > auch beim Online-Banking. Ich meine, ein formal gültiges Zertifikat sagt > doch nicht, dass ich mit dem richtigen Rechner verbunden bin? Nein. Ein formal richtiges Zertifikat ist zunächst mal nur ein Datensatz ohne tiefere Bedeutung. Die Garantie, daß dieses Zertifikat repräsentiert, kommt durch die Trust of Chain zustande. Letztendlich musst du dem Aussteller des Zertifikats vertrauen, der dafür geradesteht, daß das Zertifikat auch wirklich das garantiert, was es garantieren soll. Im Falle der https-Garantie „der Inhaber dieses Zertifikats ist Inhaber der Domain www.meinedomain.de“ musst du der ausstellenden Stelle wie z.B. letsencrypt vertrauen, daß die das ausreichend geprüft haben. Was halt für Zertifikate im eigenen Heimnetz bedeutet, daß du die dir auch selber ausstellen kannst. Oliver
:
Bearbeitet durch User
Oliver S. schrieb: > Was halt für Zertifikate im eigenen Heimnetz bedeutet, daß du die dir > auch selber ausstellen kannst. Die sind dann eigentlich sogar sicherer als welche, die du von Fremden bekommen kannst. Dir selbst wirst du ja bedingungslos vertrauen. Also unterschreibst du einfach deine selbst erstellten Zertifikate mit einem Root-Zertifikat, dass du ebenfalls selbst erstellt hast. Damit hast du eine Chain of Trust.
Bauform B. schrieb: > HTTP wird von den Browsern zunehmend verweigert, Quatsch > Eine Firma mit eigener IT-Abteilung kann eine eigene CA betreiben und das root-Zertifikat auf jedem PC installieren und das Gegenstück auf jedem Gerät So hat es ein bekannter Hersteller von Kopfhörern gemacht. Schluss mit Lustig war in dem Moment, als ein Hacker an den privaten Key dieser CA kam.
:
Bearbeitet durch User
Hannes J. schrieb: >> Eine Firma mit eigener IT-Abteilung kann eine eigene CA betreiben > > Machen große Konzerne. Was sind bei Dir große Konzerne? Selbst die Deutsche Bahn betreibt keine eigene CA, jedenfalls sind ihre elektronischen Unterschriften mit einer self-signed CA verknüpft.
Monk schrieb: > Bauform B. schrieb: >> HTTP wird von den Browsern zunehmend verweigert, > > Quatsch Enstellbar, möglicherweise Standardeinstellung.
Hardy F. schrieb: > Was sind bei Dir große Konzerne? > Selbst die Deutsche Bahn betreibt keine eigene CA, jedenfalls sind ihre > elektronischen Unterschriften mit einer self-signed CA verknüpft. Eine firmen- oder konzernlokale CA ohne externe Gültigkeit dürfte gemeint sein, ist einfach gemacht und im Windows Kontext auch einfach zu nutzen.
:
Bearbeitet durch User
(prx) A. K. schrieb: > Hardy F. schrieb: >> Was sind bei Dir große Konzerne? >> Selbst die Deutsche Bahn betreibt keine eigene CA, jedenfalls sind ihre >> elektronischen Unterschriften mit einer self-signed CA verknüpft. > > Eine firmen- oder konzernlokale CA ohne externe Gültigkeit dürfte > gemeint sein, ist einfach gemacht und im Windows Kontext auch einfach zu > nutzen. Da ja, aber wir bekommen als Dienstleister (DB-fremde Firma) diese PDFs. Wir können diese soit nicht prüfen.
Rolf schrieb: > Also unterschreibst du einfach deine selbst erstellten Zertifikate mit > einem Root-Zertifikat, dass du ebenfalls selbst erstellt hast. Damit > hast du eine Chain of Trust. Oder du setzt dir gleich einen eigenen ACME-Server auf… Was aber alles, genauso wie HTTPS im Heimnetz, letztendlich völlig überflüssig ist. Oliver
:
Bearbeitet durch User
Hardy F. schrieb: > Selbst die Deutsche Bahn betreibt keine eigene CA, jedenfalls sind ihre > elektronischen Unterschriften mit einer self-signed CA verknüpft. Hardy F. schrieb: > wir bekommen als Dienstleister (DB-fremde Firma) diese PDFs. > Wir können diese soit nicht prüfen. Ihr müsstet dieser self-signed CA vertrauen können, richtig? Könnte die Bahn das irgendwie möglich machen? Zum Beispiel mit einem Stück Papier, notfalls mit Siegel von einem Notar? An anderer Stelle vertraut man so einem Papier ja auch. Unabhängig davon, ob das praktikabel und vernünftig wäre, technisch müsste es doch möglich sein. Die Browser überprüfen anscheinend (nur) einen 32-Byte Fingerprint, das könnte ich gerade noch händisch machen. So ähnlich könnte es doch für Geräte mit HTTPS funktionieren?
Hardy F. schrieb: > Was sind bei Dir große Konzerne? > Selbst die Deutsche Bahn betreibt keine eigene CA, jedenfalls sind ihre > elektronischen Unterschriften mit einer self-signed CA verknüpft. Jedes Root-Zertifikat ist Self signed. Das liegt in der Natur der Sache. Es liegt jetzt an euch, ob ihr dem vertraut, und wie ihr das technisch implementiert. Oliver
Oliver S. schrieb: > Hardy F. schrieb: >> Was sind bei Dir große Konzerne? >> Selbst die Deutsche Bahn betreibt keine eigene CA, jedenfalls sind ihre >> elektronischen Unterschriften mit einer self-signed CA verknüpft. > > Jedes Root-Zertifikat ist Self signed. Das liegt in der Natur der Sache. > > Es liegt jetzt an euch, ob ihr dem vertraut, und wie ihr das technisch > implementiert. > > Oliver Aber diese sind im Zertifikatspeicher. Das der DB nicht, und da muß man einfach mal etwas Geld in die Hand nehmen und seine CA zertifizieren lassen. Die Verträge die damit unterschrieben werden können nicht elektronisch geprüft werden. Aber es geht ja immer noch persönlich ...
Bauform B. schrieb: > Ihr müsstet dieser self-signed CA vertrauen können, richtig? Könnte die > Bahn das irgendwie möglich machen? Zum Beispiel mit einem Stück Papier, > notfalls mit Siegel von einem Notar? An anderer Stelle vertraut man so > einem Papier ja auch. Der Aufwand ist gar nicht nötig. Es genügt, den "public key" auf einem abgesicherten Weg zu veröffentlichen. Und da genügt auch der von der DB AG betriebene Webauftritt, der nämlich ist von einer anderen Root-CA signiert. Oh, ich hab' gerade nachgesehen, da ist jemand modern: Das ist let's encrypt. Bei bahn.de. Wie auch immer, man wird davon ausgehen können, daß das nicht irgendwer anderes als die Bahn selbst ist. Denn um so ein Zertifikat zu falsifizieren, bedarf es Zugriff auf den zuständigen Nameserver. Ansonsten könnte die DB AG den public key natürlich auch per Brief, per Fax oder Flugratte versenden.
Harald K. schrieb: > Es genügt, den "public key" auf einem > abgesicherten Weg zu veröffentlichen. Das ist ja die Methode von PGP. PGP signiert und verschlüsselt nur. Der Austausch der Schlüssel bleibt "Problem" der Anwender. Und wie gerne die das in der breiten Masse benutzen, wissen wir ja.
Hardy F. schrieb: > Aber diese sind im Zertifikatspeicher. Das der DB nicht Ja, das ist natürlich ein unlösbares Problem… Oliver
Harald K. schrieb: > Oh, ich hab' gerade nachgesehen, da ist jemand modern: Das ist let's > encrypt. Bei bahn.de. Es ging wohl um signierte pdfs. Dafür stellt letsencrypt keine Zertifikate aus. Oliver
Monk schrieb: > Und wie gerne die > das in der breiten Masse benutzen, wissen wir ja. Hier geht es aber nicht um die "breite Masse", sondern um die DB AG und einen geschäftlichen Dienstleister, der irgendwelche internen signierten Unterschriften braucht.
Hardy F. schrieb: > Da ja, aber wir bekommen als Dienstleister > (DB-fremde Firma) diese PDFs. > Wir können diese soit nicht prüfen. Wo ist jetzt das Problem? Bei allen bisherigen Arten der Auftragserteilung (insb. im Rahmen einer lfd. Geschäftsbeziehung) war das doch auch nicht anders. Oder wie hättest Du die Unterschrift auf einem Fax prüfen wollen, selbst bei einem Original-Brief würde das an fehlenden Unterschrifts-Mustern zum Vergleich scheitern. Hardy F. schrieb: > Die Verträge die damit unterschrieben werden können nicht > elektronisch geprüft werden. Verträge auf totem Baum, mit edlem Füller handsigniert kannst Du doch genauso wenig elektronisch prüfen, nichtmal wenn die Unterschriften sogar notariell beglaubigt wären.
Monk schrieb: > So hat es ein bekannter Hersteller von Kopfhörern gemacht. Schluss mit > Lustig war in dem Moment, als ein Hacker an den privaten Key dieser CA > kam. Ja, natürlich ist die sichere Aufbewahrung und Verwendung des Keys der Root-CA letztlich das, an dem die Sicherheit von ALLEM anderen hängt, was darauf aufbaut. Das Problem ist: Es gibt KEINE absolute Sicherheit. Die großen CAs betreiben zwar einen ganz erheblichen Aufwand, um die Sicherheit möglichst gut herzustellen, aber perfekt ist auch das nicht. Kann es schon aus rein theoretischen Erwägungen heraus auch niemals sein. Es kann also auch bei einer eigenen CA nur darum gehen, die Sicherheit so gut wie möglich herzustellen. Und, nunja, man wird gegenüber dem Standard der Großen einige Abstriche machen müssen, um die Sache praktikabel zu halten. Aber: Gegenüber der Schwierigkeit, dem ganzen IoT-Gesolms eine eigene CA-Infrastruktur überzuhelfen, geht das Thema sowieso völlig unter. In vielen Fällen ist das ja garnicht möglich. Weil: von den jeweiligen Herstellern nicht vorgesehen. Würde ja auch deren Datenschnüffelei über Gebühr behindern. Wer sich sowas in's Haus holt, hat sowieso nicht alle Latten am Zaun.
Monk schrieb: > Schluss mit > Lustig war in dem Moment, als ein Hacker an den privaten Key dieser CA > kam. Je nun, wenn man es richtig macht (Root key ist IMMER offline), brauchts schon massives Social Engineering, um da dran zu kommen. Mit Hacken kommt man da dann nicht weit. Oliver
Oliver S. schrieb: > Je nun, wenn man es richtig macht (Root key ist IMMER offline) Das ist in der Praxis leichter gesagt als getan, wenn laufend automatisiert Zertifikate ausgestellt werden müssen. Die gängigen öffentlichen CAs verwenden deshalb Intermediate CAs. Falls die Keys davon kompromittiert werden sollten, muss man "nur" diese revoken, also auch alle Zertifikate neu ausstellen, und erspart sich immerhin den Austausch der in den Clients hinterlegten Root-CAs.
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.