Announcement: there is an English version of this forum on 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.
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.
Oliver S. schrieb: > Je nun, wenn man es richtig macht (Root key ist IMMER offline) Eine CA, deren Key immer offline ist, ist effektiv absolut nutzlos. Das sollte jedem mit logischem Denken gesegneten Menschen klar sein. Ein CA muss mit der Umwelt interagieren und sie muss dazu ihren Key auch benutzen können. Es ist also unvermeidlich, dass der Key zeitweise "online" ist. Klar, er steht natürlich nicht ungeschützt direkt im Internet. Aber er steht mindestens im Speicher irgendeiner Anwendung. Und dieser Speicher IST zu diesem Zeitpunkt "online". Das Problem ist: die "Anwendung" muß noch viel mehr "online" sein. Es genügt also auch, diese Anwendung zu kompromittieren, um früher oder später an den Key zu kommen. Und die Anwendung wiederum läuft im Kontext eines OS. Es genügt also möglicherweise auch schon, das OS zu kompromittieren, um an die Anendung heranzukommen und darüber dann an den Key. Als Fazit bleibt nur: absolute Sicherheit ist vollkommen UNMÖGLICH.
Ob S. schrieb: > Ein CA muss mit der Umwelt interagieren und sie muss dazu ihren Key auch > benutzen können. Es ist also unvermeidlich, dass der Key zeitweise > "online" ist. Weshalb die grossen kommerziellen CAs dazu übergegangen sind, die Root-CA nicht direkt für Signierung zu verwenden, sondern mehrere davon abgeleitete Zwischen-CAs. Das reduziert die Interaktion des Root-Keys und den Umfang an Problemen, wenn einer der Keys dieser Zwischen-CAs entläuft.
:
Bearbeitet durch User
(prx) A. K. schrieb: > Weshalb die grossen kommerziellen CAs dazu übergegangen sind, die > Root-CA nicht direkt für Signierung zu verwenden, sondern mehrere davon > abgeleitete Zwischen-CAs. Das reduziert die Interaktion des Root-Keys > und den Umfang an Problemen, wenn einer der Keys dieser Zwischen-CAs > entläuft. Ja, das reduziert das Problem, löst es aber nicht final. Wie schon gesagt: eine wirkliche Lösung ist vollkommen UNMÖGLICH.
Ob S. schrieb: > Eine CA, deren Key immer offline ist, ist effektiv absolut nutzlos. Das ist falsch. Schon vor gefühlt ewigen Zeiten gab es das Prinzip, dass die Zertifikats-Requests an wichtige CAs (wie eben eine Root-CA) nur über Datenträger reingereicht werden und die signierten Keys den ansonsten von Netzwerken total isolierten Rechner auf dem gleichen Weg wieder verlassen. Das Prinzip konnte man sich z.B. auf der CeBIT öfter am Heise-Stand ansehen, wo für jeden Cert-Request ein isolierter Rechner neu gebootet wurde und dann nur einen Key signiert hat (nachdem ein MA die Identität geprüft hatte).
Ralf D. schrieb: > Das ist falsch. Nein, ist es nicht. > Schon vor gefühlt ewigen Zeiten gab es das Prinzip, dass die > Zertifikats-Requests an wichtige CAs (wie eben eine Root-CA) nur über > Datenträger reingereicht werden Und Datenträger können nicht manipuliert sein? Filesystemtreiber können keine Sicherheitslücken haben? Hör doch auf, dir was vorzumachen.
Es ist zwar nicht trivial, eine als sicher geltende Airgap zu überwinden, aber möglich. Der Iran lernte das auf die harte Tour.
Hmmm schrieb: > 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. Ach. Und die gängigen privaten dürfen das nicht? Oliver
Ralf D. schrieb: > Ob S. schrieb: >> Eine CA, deren Key immer offline ist, ist effektiv absolut nutzlos. > > Das ist falsch. So pauschal ists schon richtig. Der öffentliche Schlüssel muss natürlich verfügbar sein, nur der private gehört offline. Oliver
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. Unsinn In der Regel bedeutet das nur, dass sich der Nutzer über eine Abhängigkeit von der Herstellerinfrastuktur und seine Privatsphäre bzgl. der Daten keinen Kopf gemacht hat. Nicht ohne Grund gibt es genug Smarthome Lösungen, die NICHT an irgendeine Hersteller-Cloud gebunden sind.
Rainer W. schrieb: > Nicht ohne Grund gibt es genug Smarthome Lösungen, die NICHT an > irgendeine Hersteller-Cloud gebunden sind. Ja gibt es. Den "In der Regel" Fall hat Jörg aber korrekt beschrieben, denn er bezieht sich auf die meisten Produkte, die in den vergangenen 20 Jahren angeboten wurden.
auform 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. Zum Verständnis: bahn.de hat natürlich kein self-signed-Zertifikat. Die Bahn hat ihr Zertifikat für bahn.de von Let's Encrypt unterschreiben lassen, und Let's Encrypt hat ihr Zertifikat von ISRG Root X1 unterschreiben lassen. Nur das Zertifikat von ISRG Root X1 ist self-signed. Weil es das Anfangsglied in der Vertrauenskette ist. (Jeder Browser zeigt dir das an. Allerdings musst du dann dem Browser glauben ...) Ein Notar beurkundet das, was er gesehen hat. Er wird kaum die abgesicherten Gebäude von ISRG Root X1 betreten dürfen oder gar in die Rechner dort reinsehen. Letzteres kann er ja fachlich ohnehin gar nicht. Bestenfalls könnte er also die Unterschrift eines Sachverständigen unter eine Bestätigung beurkunden, laut der alles seine Richtigkeit hat. Praktisch geht das so nicht, und selbst wenn doch, dann gäbe es ja zunächst nur EINE solche Beurkundung. Davon ausgehend dann Hunderttausende beglaubigte Kopien verteilen?
Rolf schrieb: > bahn.de hat natürlich kein self-signed-Zertifikat. Die Bahn hat ihr > Zertifikat für bahn.de von Let's Encrypt unterschreiben lassen Es geht aber nicht um die Webseite von denen, sondern um PDF-Dateien, die im Geschäftsverkehr an einen Dienstleister übergeben werden. Kann man PDF-Dateien mit dem Let's-Encrypt-Zertifikat seines Webservers signieren? Und welchen Sinn hätte das, wo die doch nur 90 Tage lang gültig sind?
Rolf schrieb: > 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. > > Zum Verständnis: > bahn.de hat natürlich kein self-signed-Zertifikat. Die Bahn hat ihr > Zertifikat für bahn.de von Let's Encrypt unterschreiben lassen, und > Let's Encrypt hat ihr Zertifikat von ISRG Root X1 unterschreiben lassen. > Nur das Zertifikat von ISRG Root X1 ist self-signed. Ja, so ist es verständlicher. Wenn man in meiner Frage "Bahn" durch "Heizungs-Hersteller" ersetzt, fehlt allerdings die Kette bis zur echten Root CA. Die Heizung (immer noch als Beispiel) erzeugt direkt ihr self-signed Zertifikat. In dem Fall wäre mein Plan, dass der paranoide Benutzer in den Keller geht und sich per USB-Stick den Fingerprint der Zertifikats besorgt. Wünscht sich das (etwas ähnliches) wirklich niemand?
Bauform B. schrieb: > In dem Fall wäre mein Plan, dass der paranoide > Benutzer in den Keller geht und sich per USB-Stick den Fingerprint der > Zertifikats besorgt. Wünscht sich das (etwas ähnliches) wirklich > niemand? Ich wüsste nicht, wieso ein Gerät, das nur und ausschließlch in meinem Netzwerk aktiv ist, ein Zertifikat verwenden muss. Aber vielleicht bin ich ja auch nur nicht paranoid genug, um zu erkennen, daß DIE auch längst in meine Wohnung eingebrochen sind, um im Gehäuse meines Switches einen (kleinen) "Man in the Middle" einziehen zu lassen.
Oliver S. schrieb: > Ach. Und die gängigen privaten dürfen das nicht? Dürfen schon, aber als nicht von den Browsern unterstützte Root-CA wird es schwierig, die CRL an die Clients zu verteilen, was den Sicherheitsgewinn wieder verpuffen lässt. OCSP stirbt ja gerade aus und hätte ohnehin den Nachteil, dass der Hersteller die Server dafür zuverlässig und dauerhaft betreiben müsste, quasi eine Cloud-Abhängigkeit durch die Hintertür.
Hmmm schrieb: > OCSP stirbt ja gerade aus Vielleicht, weil Outlook es nicht kann. Outlook hat da noch eine funktionale Lücke: Emails müssen mit S/MIME Zertifikaten signiert werden, die direkt von Root Zertifikaten abgeleitet wurden. Nur macht das heute (aus gutem Grund) niemand mehr. Outlook ist nämlich nicht imstande, die Chain of Trust zu überprüfen, indem es den HTTP Links folgt und die Parent Zertifikate herunter lädt. Angeblich gibt es einen Workaround, indem man alle Zwischenzertifikate an die Mail anhängt, das prüfen meine Kollegen gerade. Ich finde es aber schon saublöd, dass ausgerechnet im "Maß aller Dinge" Mailprogramm (dass an der Einführung von S/MIME als Alternative zu PGP maßgeblich beteiligt war) so eine grundlegende Funktion fehlt, obwohl sie von Anfang an spezifiziert war.
Bauform B. schrieb: > Die Heizung (immer noch als Beispiel) erzeugt direkt ihr > self-signed Zertifikat. Nein, ich würde sämtliche Zertifikate (eins pro Gerät wie z. B., die Heizung) selbst erzeugen, ebenso das Root-Zertifikat. > In dem Fall wäre mein Plan, dass der paranoide > Benutzer in den Keller geht und sich per USB-Stick den Fingerprint der > Zertifikats besorgt. Wünscht sich das (etwas ähnliches) wirklich > niemand? In den Browser, den man zum Administrieren des Netzes verwendet, kann man die selbst-signierten öffentlichen alle mit Bordmitteln importieren. Dafür braucht die Heizung lediglich eine Netzwerkverbindung, die sie ohnehin hat. Wenn man allerdings – wie hier! – beide Seite der Verbindung unter Kontrolle hat, geht es auch ohne Zertifikate. Man braucht ja dann kein Vertrauen, sondern nur eine Verschlüsselung, z. B. mit SSH. Die Zertifikate im Internet braucht man ja nur, weil man die Server-Seite nicht sehen/konfigurieren kann. Die Heizung aber kann man konfigurieren.
Monk schrieb: > Outlook hat da noch eine funktionale Lücke: > Emails müssen mit S/MIME Zertifikaten signiert werden, die direkt von > Root Zertifikaten abgeleitet wurden. Nur macht das heute (aus gutem > Grund) niemand mehr. > > Outlook ist nämlich nicht imstande, die Chain of Trust zu überprüfen, Sicher? Was meinst du genau mit "Outlook"? Hier liest es sich jedenfalls anders: https://keytalk.com/knowledge-base/smime/s-mime-certificates-seem-not-trusted Da steht, die gesamte Kette müsse zugreifbar sein. Dann wird sie wohl auch geprüft werden können und müssen.
Rolf schrieb: > Wenn man allerdings – wie hier! – beide Seite der Verbindung unter > Kontrolle hat, geht es auch ohne Zertifikate. Man braucht ja dann kein > Vertrauen, sondern nur eine Verschlüsselung, z. B. mit SSH. Wozu eigentlich? Wenn mein PC über mein lokales Netzwerk mit irgendwas kommuniziert, wozu sollte ich da irgendwas verschlüsseln? Ins Internet würde ich irgendwelche Geräte eh' nie lassen; und wenn ich von unterwegs mit ihnen reden will, dann nur und ausschließlich über ein VPN.
Rolf schrieb: >> Outlook ist nämlich nicht imstande, die Chain of Trust zu überprüfen, > Sicher? Was meinst du genau mit "Outlook"? Damit meine ich die Software, mit denen es laut Kunde und Betriebsabteilung nicht funktioniert. Meine Email Programme haben das Problem alle nicht. Rolf schrieb: > Da steht, die gesamte Kette müsse zugreifbar sein. Dann wird sie wohl > auch geprüft werden können und müssen. Ddie Zertifikate sind in Ordnung und per AIA verknüpft. Das wurde doppelt und dreifach manuell und mit unterschiedlichen Programmen geprüft. Weil wir nämlich alle der Meinung waren "kann nicht sein, es muss am Zertifikat liegen". Wer diese S/MIME Zertifikate verkaufen will, der wird natürlich nicht an prominenter Stelle auf mögliche Probleme hinweisen. Schon gar nicht, wenn diese im allgegenwärtigen Office auftreten. Damit würden sie sich ins eigene Knie schießen.
Harald K. schrieb: > Wozu eigentlich? Wenn mein PC über mein lokales Netzwerk mit irgendwas > kommuniziert, wozu sollte ich da irgendwas verschlüsseln? Wenn Du eine Familie mit rudimentärem IT-Talent beherbergst, der du für deren Geschmack etwas zu viel Jugendschutz verordnet hast, könntest du überlegen, ob das Zero Trust Prinzip von Unternehmensnetzen vielleicht ansatzweise auch zu Hause angebracht ist. :) Je nach Wohngegend könnten auch unmittelbar benachbarte Studenten ein Argument sein. Zumindest solltest Du dein WLAN in Schuss halten.
:
Bearbeitet durch User
Monk schrieb: > Outlook ist nämlich nicht imstande, die Chain of Trust zu überprüfen, > indem es den HTTP Links folgt und die Parent Zertifikate herunter lädt. > Angeblich gibt es einen Workaround, indem man alle Zwischenzertifikate > an die Mail anhängt, das prüfen meine Kollegen gerade. Und das ist genau das, was tu typischerweise auch bei einem Webserver tun musst um die Zertifikatskette zum Client zu bringen. Kein Fehler, sondern works-as-designed
Monk schrieb: > Hmmm schrieb: >> OCSP stirbt ja gerade aus > > Vielleicht, weil Outlook es nicht kann. Blödsinn, es geht um erster Linie um Browser. Das Problem ist der Datenschutz, denn eine CA geht es wenig an, welche Clients auf die mit ihren Zertifikaten betriebenen Server zugreifen. Monk schrieb: > Outlook ist nämlich nicht imstande, die Chain of Trust zu überprüfen, > indem es den HTTP Links folgt Das wäre auch ein Traum für Spammer. Monk schrieb: > Workaround, indem man alle Zwischenzertifikate an die Mail anhängt So wird es bei anderen Protokollen auch gemacht.
Harald K. schrieb: > Wozu eigentlich? Wenn mein PC über mein lokales Netzwerk mit irgendwas > kommuniziert, wozu sollte ich da irgendwas verschlüsseln? Weil auch im LAN Angreifer lauern können. Sobald die irgendeinen Rechner im LAN auch nur mit den Rechten eines "normalen Benutzers" unter Kontrolle haben, ergeben sich schon deutlich erweiterte Möglichkeiten zur Infiltration des gesamten LAN. Konsequente Verschlüsselung im LAN ist natürlich keinesfalls der Weisheit letzter Schluss. Nur ein kleiner Beitrag zur Verringerung der Angriffsfläche. Aber eben doch ein Beitrag zur Verringerung des Risikos. Man muss sich einfach von der Vorstellung trennen, dass das LAN eine sichere Umgebung ist. Das mag in einem kleinen LAN mit einem einzelnen kompetenten Admin als einzigem Teilnehmer noch zuverlässig klappen, aber bei allem, was darüber hinaus geht, ist es das nicht. Viele Firmen mussten das bereits auf die ganz harte Tour lernen...
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.