Forum: PC-Programmierung wie funktioniert HTTPS im Smart Home?


von Bauform B. (bauformb)


Lesenswert?

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?

von Mario M. (thelonging)


Lesenswert?

Einfach in der Zertifikatsverwalting des Browsers Ausnahmen hinzufügen.

von Lu (oszi45)


Lesenswert?

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?

von Hannes J. (Firma: _⌨_) (pnuebergang)


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

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.

von Jörg (Gast)


Lesenswert?

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

von Jörg (Gast)


Lesenswert?

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

von Rolf (rolf22)


Lesenswert?

(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.

von Hmmm (hmmm)


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

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
von Lu (oszi45)


Lesenswert?

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".

von (prx) A. K. (prx)


Lesenswert?

Was hat eine solche IP-Adresse mit einem Zertifikat zu tun?

von Bauform B. (bauformb)


Lesenswert?

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!

von Hmmm (hmmm)


Lesenswert?

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.

von Bauform B. (bauformb)


Lesenswert?

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?

von (prx) A. K. (prx)


Lesenswert?

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
von Hmmm (hmmm)


Lesenswert?

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
von (prx) A. K. (prx)


Lesenswert?

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
von Hmmm (hmmm)


Lesenswert?

(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.

von Oliver S. (oliverso)


Lesenswert?

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

von Oliver S. (oliverso)


Lesenswert?

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
von Rolf (rolf22)


Lesenswert?

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.

von Monk (Gast)


Lesenswert?

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.

von Hardy F. (hflor)


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

Monk schrieb:
> Bauform B. schrieb:
>> HTTP wird von den Browsern zunehmend verweigert,
>
> Quatsch

Enstellbar, möglicherweise Standardeinstellung.

von (prx) A. K. (prx)


Lesenswert?

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
von Hardy F. (hflor)


Lesenswert?

(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.

von Oliver S. (oliverso)


Lesenswert?

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
von Bauform B. (bauformb)


Lesenswert?

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?

von Oliver S. (oliverso)


Lesenswert?

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

von Hardy F. (hflor)


Lesenswert?

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

von Harald K. (kirnbichler)


Lesenswert?

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.

von Monk (Gast)


Lesenswert?

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.

von Oliver S. (oliverso)


Lesenswert?

Hardy F. schrieb:
> Aber diese sind im Zertifikatspeicher. Das der DB nicht

Ja, das ist natürlich ein unlösbares Problem…

Oliver

von Oliver S. (oliverso)


Lesenswert?

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

von Harald K. (kirnbichler)


Lesenswert?

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.

von Michi S. (mista_s)


Lesenswert?

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.

von Ob S. (Firma: 1984now) (observer)


Lesenswert?

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.

von Oliver S. (oliverso)


Lesenswert?

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

von Hmmm (hmmm)


Lesenswert?

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.

von Ob S. (Firma: 1984now) (observer)


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

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
von Ob S. (Firma: 1984now) (observer)


Lesenswert?

(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.

von (prx) A. K. (prx)


Lesenswert?

Ob S. schrieb:
> Wie schon gesagt: eine wirkliche Lösung ist vollkommen UNMÖGLICH.

Unstreitig.

von Ralf D. (doeblitz)


Lesenswert?

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

von Ob S. (Firma: 1984now) (observer)


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

Es ist zwar nicht trivial, eine als sicher geltende Airgap zu 
überwinden, aber möglich. Der Iran lernte das auf die harte Tour.

von Oliver S. (oliverso)


Lesenswert?

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

von Oliver S. (oliverso)


Lesenswert?

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

von Rainer W. (rawi)


Lesenswert?

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.

von Monk (Gast)


Lesenswert?

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.

von Rolf (rolf22)


Lesenswert?

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?

von Harald K. (kirnbichler)


Lesenswert?

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?

von Bauform B. (bauformb)


Lesenswert?

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?

von Harald K. (kirnbichler)


Lesenswert?

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.

von Hmmm (hmmm)


Lesenswert?

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.

von Monk (Gast)


Lesenswert?

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.

von Rolf (rolf22)


Lesenswert?

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.

von Rolf (rolf22)


Lesenswert?

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.

von Harald K. (kirnbichler)


Lesenswert?

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.

von Monk (Gast)


Lesenswert?

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.

von (prx) A. K. (prx)


Lesenswert?

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
von Jörg (Gast)


Lesenswert?

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

von Hmmm (hmmm)


Lesenswert?

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.

von Ob S. (Firma: 1984now) (observer)


Lesenswert?

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

Bitte 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
Noch kein Account? Hier anmelden.