Fritzbox unsichere Anmeldung?

Die Fritzbox macht zur Anmeldung ein eigenes Challenge-Response 
Verfahren. Da gehen keine Passwörte im Klartext über die Leitung und 
mittlerweile soll AVM das auch kryptographisch solide implementiert 
haben.

Warum sie was eigenes machen? Not invented here Syndrom.

Sosos schrieb:
> Die Fritzbox macht zur Anmeldung ein eigenes Challenge-Response
> Verfahren. Da gehen keine Passwörte im Klartext über die Leitung und
> mittlerweile soll AVM das auch kryptographisch solide implementiert
> haben.
>
> Warum sie was eigenes machen? Not invented here Syndrom.

Ist nichts wert. Im lokalen Netz können wir problemlos als aktiver 
Angreifer agieren und somit das Challenge-Response Verfahren aushebeln.

Meine mal gelesen zu haben, dass die FB schon https macht (also 
verschlüsselt), aber das Zertifikat dafür selbst signiert ist (und nicht 
von einer Signaturstelle, die der Browser kennt). Daher beschweren sich 
die Browser.

Also: Traffic ist verschlüsselt, aber der Verschlüsselung wird nicht 
vertraut.

Du kannst an der Fritzbox dich auch per HTTPS anmelden.

Witzigerweise sagt mit mein FF dann, das das Zertifikat nicht gültig 
ist. ;)

Aber wer mein Kabel hackt braucht ne Axt. Und W-Lan ist eh 
verschlüsselt. Also wo ist die Panik.

Schlaumaier schrieb:
> Und W-Lan ist eh
> verschlüsselt. Also wo ist die Panik.

Der Name ist wie immer Programm: Nach der Anmeldung ist alles 
verschlüsselt. Und bei der Anmeldung???
Harald Welte (oder so ähnlich?!) hat schon vor längerer Zeit ein 
weiteres mal bewiesen, daß die Probleme im Randbereich eines Prozesses 
zu finden sind. Also Anfang und Ende. Hier Anfang. Beim internationalen 
Roaming im GSM z.B. wird es etwas anders, und da hat er angesetzt und 
konnte GSM hacken.
Und auch wie immer: Man muß der Maschine ein gefaktes Szenario 
vorspielen, um die Schwachstellen auszunutzen.

Lutz schrieb:
> Der Name ist wie immer Programm: Nach der Anmeldung ist alles
> verschlüsselt. Und bei der Anmeldung???

Häh? Wie nach der Anmeldung ist alles verschlüsselt? Du machst hier auch 
keinen sehr kompetenten Eindruck. Schlaumaier hat hier durchaus recht. 
Wenn du in deinem internen Netz einen Angreifer hast, wird dein FritzBox 
Passwort dein kleinstes Problem sein. In diesem Fall gibt es folgende 
Szenarien:

- Jemand ist auf deinem Rechner (du hast dir selbst Schadsoftware 
installiert). Dann hast du schon ganz andere Probleme.
- Ein wild gewordenes IoT Device hackt dich. Dann solltest du dir 
Gedanken um dein gesamtes Netzwerk machen.
- Jemand ist mit einem eigenen Device ins LAN/WLAN eingedrungen. Dann 
interceptet er eben die verschlüsselte Anmeldung. In internen Netzen 
sind selbst halbwegs gute Admins dahingehend konditioniert, 
Zertifikatsfehler zu ignorieren.

Und zu guter letzt muss man sich auch die Frage stellen: Was kann ein 
Angreifer mit dem FritzBox Passwort wirklich machen? Dann wirst du 
merken, dass es schon recht wertlos ist.

Schlaumaier schrieb:

> Witzigerweise sagt mit mein FF dann, das das Zertifikat nicht gültig
> ist. ;)

Nein, so weit traut sich nicht mal Mozilla zu gehen...

Es meldet (vollkommen korrekt), dass es sich um ein selbstsigniertes 
Zertifikat handelt, mit dem der Server sich ausweist.

Und so ein Zertifikat ist nicht weniger sicher als eins, was von 
irgendeiner verschissenen CA ausgestellt wurde, direkt oder indirekt.

Man muß entweder dem angebotenen Zertifikat direkt vertrauen oder 
irgendeiner CA (und darüber hinaus der ganzen Kette bis runter zum 
angebotenen Server-Zertifikat). Kein normaler User ist auch nur 
annähernd in der Lage, die Vertrauenswürdigkeit so einer 
Zertifikats-Hierarchie einzuschätzen.

Das nimmt ihm "freundlicherweise" sein Browser ab bzw. die Leute beim 
jeweiligen Hersteller, die entscheiden, welche CA vertrauenswürdig ist.

Das ist objektiv der einzige Unterschied. Der Browser entmündigt also de 
facto den User.

c-hater schrieb:
> Es meldet (vollkommen korrekt), dass es sich um ein selbstsigniertes
> Zertifikat handelt, mit dem der Server sich ausweist.
>
> Und so ein Zertifikat ist nicht weniger sicher als eins, was von
> irgendeiner verschissenen CA ausgestellt wurde, direkt oder indirekt.

Dein Browser muß es nur akzeptieren. Selbst signiert ist besser als 
faules Ei einer scheinbaren Zertifizierungsstelle.

oszi40 schrieb:

> Dein Browser muß es nur akzeptieren. Selbst signiert ist besser als
> faules Ei einer scheinbaren Zertifizierungsstelle.

Genau. Nur bietet halt keiner der verbreiteten Browser (oder überhaupt 
irgendeiner?) die Möglichkeit, ihm zu sagen, dass er einem bestimmten 
self-signed Zertifikat vertrauen darf.

Maximal kann man eigene CAs quasi "freischalten". Aber das ist dann auch 
nicht das Wahre, wenn es eigentlich nur darum geht, ein self-signed 
Zertifikat zu akzeptieren. Es wäre im Gegenteil maximal kontraproduktiv, 
wenn man diesem Zertifikat den Status eines CA-Zertifikats zuerkennen 
würde.

Insgesamt kann man wohl sagen: Dieser ganze Zertifikatskram ist 
ziemlicher Kokolores. Der sichert nur die Pfründe der etablierten CAs. 
Nicht mehr und nicht weniger.

c-hater schrieb:
> Genau. Nur bietet halt keiner der verbreiteten Browser (oder überhaupt
> irgendeiner?) die Möglichkeit, ihm zu sagen, dass er einem bestimmten
> self-signed Zertifikat vertrauen darf.

Noch schlimmer ist, dass das früher mal ging und irgendwann abgeschafft 
wurde. Im Firefox konnte man mal permanente Ausnahmen definieren.

Oliver S. schrieb:
> Da sich das aber bei jeder Änderung der öffentlichen IP-Adresse
> mitändert, meckert der Browser trotzdem irgendwann mal wieder, und deine
> Sammlung nutzloser Zertifikate wächst fröhlich weiter.

Wenn du die FritzBox von außen erreichbar machst, kannst du Let's 
Encrypt benutzen. Hier geht es aber offenkundig um eine Anmeldung aus 
dem internen Netz.

Oliver S. schrieb:
> Carla Audimarie schrieb:
>> Hier geht es aber offenkundig um eine Anmeldung aus
>> dem internen Netz.
>
> Genau. Problem siehe oben.
>
> Oliver

Dann macht dein Einwurf mit der öffentlichen IP eben immer noch keinen 
Sinn.

Oliver S. schrieb:
> Da sich das aber bei jeder Änderung der öffentlichen IP-Adresse
> mitändert, meckert der Browser trotzdem irgendwann mal wieder, und deine
> Sammlung nutzloser Zertifikate wächst fröhlich weiter.

Man kann Zertifikate auf bestimmte IP oder NAMEN ausstellen. Allerdings 
wäre ein Zertifikat auf einen Namen, der millionenfach vorkommt, auch 
Mist.

Carla Audimarie schrieb:
> Noch schlimmer ist, dass das früher mal ging und irgendwann abgeschafft
> wurde. Im Firefox konnte man mal permanente Ausnahmen definieren.

Nur weil es nicht mehr schön einfach für jeden Deppen anklickbar ist, 
bedeutet es nicht, dass es nicht mehr geht.

Dann sage wie?

michael_ schrieb:
> Dann sage wie?

Wenn die Warnung ("Potential security risk ahead") kommt, auf "Advanced" 
klicken, dann auf "Accept the risk and continue".

Ob eine permanente Ausnahme (Standard) oder nur eine temporäre angelegt 
wird, hängt von security.certerrors.permanentOverride ab, und zwar zum 
Zeitpunkt des Anlegens der Ausnahme.

Einsehen und löschen kann man die Ausnahmen in den Settings unter 
Privacy & Security - Certificates - View certificates - Servers.

Hmmm schrieb:
> michael_ schrieb:
>> Dann sage wie?
>
> Wenn die Warnung ("Potential security risk ahead") kommt, auf "Advanced"
> klicken, dann auf "Accept the risk and continue".
>
> Ob eine permanente Ausnahme (Standard) oder nur eine temporäre angelegt
> wird, hängt von security.certerrors.permanentOverride ab, und zwar zum
> Zeitpunkt des Anlegens der Ausnahme.
>
> Einsehen und löschen kann man die Ausnahmen in den Settings unter
> Privacy & Security - Certificates - View certificates - Servers.

Das ist ja alles schön und gut. Früher gab es mal eine Checkbox, über 
die das direkt einstellbar war. Ich will für jede Webseite selbst 
entscheiden, ob ich eine temporäre oder permanente Ausnahme möchte und 
ich will sofort sehen, was ich da eigentlich gerade mache. Wer hat den 
Entwicklern eigentlich in den Kopf geschissen?

Carla Audimarie schrieb:
> Was kann ein
> Angreifer mit dem FritzBox Passwort wirklich machen?

Er kann eine getürkte Version von FritzOS installieren, die sämtlichen 
Netzwerkverkehr auswerten und manipulieren kann.

Karl schrieb:
> Carla Audimarie schrieb:
>> Was kann ein
>> Angreifer mit dem FritzBox Passwort wirklich machen?
>
> Er kann eine getürkte Version von FritzOS installieren, die sämtlichen
> Netzwerkverkehr auswerten und manipulieren kann.

Und dann soll er den verschlüsselten HTPPS Traffic mitlesen und sogar 
verändern? Alles was auf WAN rausgeht liest sowieso schon jemand mit. 
Sei es der Provider, die NSA oder andere komische Gestalten.

Hier ist das Szenario, dass es schon einen Angreifer im internen Netz 
gibt, der das Passwort schonmal mitgelesen hat. Wie macht er das 
initial? Ein interner Angreifer kann den Traffic auch per ARP Spoofing 
umbiegen und mitlesen. Dann braucht er aber keine komplizierten 
Firmwaremanipulationen an der FritzBox durchzuführen, zumal die wohl 
ohne den Recovery Modus am Signaturcheck scheitern werden.

Carla Audimarie schrieb:
> Früher gab es mal eine Checkbox, über die das direkt einstellbar war.

Ja, warum diese Möglichkeit entfernt wurde, ist mir auch schleierhaft.

Carla Audimarie schrieb:
> Ich will für jede Webseite selbst entscheiden, ob ich eine temporäre
> oder permanente Ausnahme möchte

Das geht wie gesagt, weil die Config zum Zeitpunkt des Anlegens der 
Ausnahme ausschlaggebend ist. In der Liste wird das auch bei jedem 
Eintrag angezeigt.

Aber statt der Checkbox kurz in about:config zu müssen, ist natürlich 
nervig.

Karl schrieb:
> Er kann eine getürkte Version von FritzOS installieren, die sämtlichen
> Netzwerkverkehr auswerten und manipulieren kann.

Ich glaube, bei einer VoIP-Fritzbox sind teure Telefonate die 
lukrativere Missbrauchsvariante.

Oliver S. schrieb:
> Carla Audimarie schrieb:
>> Dann macht dein Einwurf mit der öffentlichen IP eben immer noch keinen
>> Sinn.
>
> Erzähl das AVM, nicht mir. Die haben den Unsinn so implementiert.
>
> Oliver

Hä? Dann greif doch einfach nicht über die öffentliche IP auf deine 
FritzBox im internen Netz zu.

Carla Audimarie schrieb:
> Hä? Dann greif doch einfach nicht über die öffentliche IP auf deine
> FritzBox im internen Netz zu.

Achso. Jetzt verstehe ich, wie du das meinst. Ja, ist echt selten 
dämlich gelöst.

Cert schrieb:
> Meine mal gelesen zu haben, dass die FB schon https macht (also
> verschlüsselt), aber das Zertifikat dafür selbst signiert ist (und nicht
> von einer Signaturstelle, die der Browser kennt). Daher beschweren sich
> die Browser.
>
> Also: Traffic ist verschlüsselt, aber der Verschlüsselung wird nicht
> vertraut.

Das Problem ist lösbar, wenn man ein eigenes Zertifikat erstellt und mit 
einer eigenen CA zertifiziert und den Browsern diese CA beibringt.

Carla Audimarie schrieb:
> Und zu guter letzt muss man sich auch die Frage stellen: Was kann ein
> Angreifer mit dem FritzBox Passwort wirklich machen? Dann wirst du
> merken, dass es schon recht wertlos ist.

Er könnte deinen gesamten Datenverkehr, der ins Internet soll, umleiten.
Ebenso könnte er die die Firewall aufmachen.
Da gibt es genug Möglichkeiten.

c-hater schrieb:
> oszi40 schrieb:
>
>> Dein Browser muß es nur akzeptieren. Selbst signiert ist besser als
>> faules Ei einer scheinbaren Zertifizierungsstelle.
>
> Genau. Nur bietet halt keiner der verbreiteten Browser (oder überhaupt
> irgendeiner?) die Möglichkeit, ihm zu sagen, dass er einem bestimmten
> self-signed Zertifikat vertrauen darf.

Das wäre auch Unsinn. Begründung siehe unten.

> Maximal kann man eigene CAs quasi "freischalten". Aber das ist dann auch
> nicht das Wahre, wenn es eigentlich nur darum geht, ein self-signed
> Zertifikat zu akzeptieren. Es wäre im Gegenteil maximal kontraproduktiv,
> wenn man diesem Zertifikat den Status eines CA-Zertifikats zuerkennen
> würde.

Eine eigene CA ist viel besser, weil man so dem Browser NUR EINE CA 
beibringen muss und ALLE Zertifikate aller Geräte im eigenen Haus LAN 
sind damit dann abgedeckt, wenn man für diese eine mit dieser CA 
signierten Zertifikat ausstellt.


Müsste man bei jedem Rechner das self-signed Zertifikat aller Geräte im 
Haus LAN beibringen, dann wäre der Aufwand um ein wesentliches höher.

Beispiel:
7 Servergeräte (z.B. NAS, Fritzbox, Farbdrucker, S/W Laserdrucker, Raspi 
1, Raspi 2, Raspi 3)
10 Clients (z.B. Arbeits PC, Spiele PC, TV PC, Handy, Handy von Frau, 
Tablet, Tablet von Frau, Notebook von Frau, PC von Kind 1, PC von Kind 
2)

Bedeutet bei self-signed Zertifikate also, dass man 10 Clients 7 
Servergeräte beibringen muss.
Aufwand = 10*7 = 70

Mit CA dagegen:
7 mit CA signierte Zertifikate für 7 Servergeräte
+
10 Clients 1 CA beibringen
Aufwand = 7 + 10 * 1 = 17

CA wins.
Kommt ein neues Clientgerät dazu, z.B. eigenes Notebook, dann steigt der 
Aufwand mit CA nur um 1. Bei selfed signed Zertifiakten würde er um 7 
steigen.

Noch schlimmer wird es, wenn ein weiteres Servergerät dazu kommt.
Dann muss man alle 10 bzw. 11 Clients updaten.

Aber das ist noch nicht.
So manches Client Gerät kriegt eine Neuinstallation, weil neuer Rechner, 
neue SSD, neues OS  oder sonst was, also müsste man bei selfed signed 
Zertifikate wieder alle selfed signed Zertifikate aller Server 
zusammensuchen und bei jedem Clientupdate wieder installieren.
Mit CA installiert man nur den CA, fertig.



> Insgesamt kann man wohl sagen: Dieser ganze Zertifikatskram ist
> ziemlicher Kokolores. Der sichert nur die Pfründe der etablierten CAs.
> Nicht mehr und nicht weniger.

Blödsinn.
HTTPS funktioniert gut und mein eigener CA für mein gesamtes LAN auch.

Oliver S. schrieb:
> Axel S. schrieb:
>> Hinreichend neue Fritzboxen bieten es an, das Zertifikat das sie zur
>> Signierung benutzen, herunterzuladen. Dann kann man es als
>> vertrauenwürdiges CA-Zertifikat behandeln [1].
>
> Da sich das aber bei jeder Änderung der öffentlichen IP-Adresse
> mitändert, meckert der Browser trotzdem irgendwann mal wieder, und deine
> Sammlung nutzloser Zertifikate wächst fröhlich weiter.
>
> Oliver

Nein, du musst dem Zertifikat einfach noch den Hostnamen bekannt geben.
Dann meckert da gar nichts mehr.

Nano schrieb:
> Er könnte deinen gesamten Datenverkehr, der ins Internet soll, umleiten.

Oh nein. Man Datenverkehr, der ins Internet soll, wird umgeleitet. Alles 
was ins Internet geht kann umgeleitet werden, wohin auch immer. Da ist 
das Risiko genau Null, da genau dies schon im Internet ständig passiert. 
Ganz davon abgesehen kann ein Angreifer im internen Netz das auch schon 
tun.

Nano schrieb:
> Ebenso könnte er die die Firewall aufmachen.

Was hätte ein Angreifer davon? Er ist schon im internen Netz. Muss sich 
also gar nichts mehr aufmachen. Mit der häufig aktivieren Option UPnP 
Portmapping ist das auch egal. Da braucht es nicht mal ein Passwort.

Nano schrieb:
> 7 Servergeräte (z.B. NAS, Fritzbox, Farbdrucker, S/W Laserdrucker, Raspi
> 1, Raspi 2, Raspi 3)

Offenkundig hast du schon ein größeres Heimnetz. Wenn da ein Angreifer 
im internen Netz ist, würde ich mir keine Sorgen mehr um meine FritzBox 
machen, sondern um:
- SMB Shares -> Zugriff normalerweise unverschlüsselt, Passwörter können 
leicht abgegriffen werden
- SMB Shares -> Wenn ich schon Zugriff habe, vielleicht 
lösche/verschlüssle ich Daten, um dich zu erpressen (Ransomware)
- Druckaufträge -> Mitlesen der gedruckten Dokumente

Nano schrieb:
> Eine eigene CA ist viel besser, weil man so dem Browser NUR EINE CA
> beibringen muss und ALLE Zertifikate aller Geräte im eigenen Haus LAN
> sind damit dann abgedeckt, wenn man für diese eine mit dieser CA
> signierten Zertifikat ausstellt.

Eine eigene CA kann man machen. Wenn dann, aber bitte richtig. Ich habe 
lang genug selber eine interne CA betrieben, um das beurteilen zu 
können. Die bringt dir genau gar nichts, wenn nicht hinreichend sicher 
implementiert. Sie ist dann sogar ein Risiko. Auch Dinge wie CRL oder 
OCSP kann kaum eine interne CA. In vielen Fällen macht es das unter 
Sicherheitsaspekten schlimmer.

Nano schrieb:
>> Insgesamt kann man wohl sagen: Dieser ganze Zertifikatskram ist
>> ziemlicher Kokolores. Der sichert nur die Pfründe der etablierten CAs.
>> Nicht mehr und nicht weniger.
>
> Blödsinn.
> HTTPS funktioniert gut und mein eigener CA für mein gesamtes LAN auch.

Das ganze System mit den trusted CAs ist schon ziemlicher Müll, aber 
leider das beste, was wir derzeit haben und immer noch besser als 
nichts. DNSSEC und DANE für HTTPS wären wohl die bessere Alternative, 
aber auch nicht unangreifbar. Ich ziehe inzwischen aber Let's Encrypt 
Zertifikate auch für interne Systeme vor. Das spart mir noch den ganzen 
Aufwand mit der Verwaltung einer eigenen CA und dem ausrollen der 
Zertifikate.

Kilo S. schrieb:
> Nennt sich Man in The Middle.
> Und ja da lässt sich durchaus was machen.
> https://github.com/moxie0/sslstrip
>
> Ob das aktuell noch klappt müsste man ausprobieren, ich kann allerdings
> bestätigen das es bei mir damals zum testen sehr gut funktioniert hat.

Ach was, echt? Machine in the middle hatte ich ja wohl schon mit ARP 
Spoofing erwähnt. Dein sslstrip funktioniert nicht, denn HSTS verhindert 
ein Downgrade. Auch ein gecachter 301 Redirect HTTP->HTTPS dürfte den 
Zweck erfüllen.

Wenn eine Webseite kein HSTS implementiert und der erste Aufruf 
stattfindet, kann das tatsächlich immer noch funktionieren. Aber: Die 
Prämisse hier im Thread ist, dass der Angreifer bereits im internen Netz 
ist. Für einen machine in the middle Angriff muss er nicht die FritzBox 
übernehmen und um sie zu übernehmen, braucht er zunächst einen machine 
in the middle Angriff. Die FritzBox ist also für dein Szenario völlig 
egal, denn auch dort kann schon vorher ein sslstrip passiert sein.

Carla Audimarie schrieb:
> Nano schrieb:
>> Er könnte deinen gesamten Datenverkehr, der ins Internet soll, umleiten.
>
> Oh nein. Man Datenverkehr, der ins Internet soll, wird umgeleitet. Alles
> was ins Internet geht kann umgeleitet werden, wohin auch immer. Da ist
> das Risiko genau Null, da genau dies schon im Internet ständig passiert.
> Ganz davon abgesehen kann ein Angreifer im internen Netz das auch schon
> tun.

Es macht schon einen Unterschied ob der Traffic gezielt über Server des 
Angreifers geleitet wird und er somit alles kontrolliert, oder der 
Traffic über beliebige Server läuft, von denen die meisten irgendwelchen 
ISP Anbietern gehören die an deinen Daten kein großes Interesse haben 
und Gesetzen unterliegen.


> Nano schrieb:
>> Ebenso könnte er die die Firewall aufmachen.
>
> Was hätte ein Angreifer davon?

Er könnte dann einen Server betreiben.

> Er ist schon im internen Netz.

Er ja, aber nicht die anderen.
Und der Dienst, den er laufen lassen will, ist für die anderen.


> Nano schrieb:
>> 7 Servergeräte (z.B. NAS, Fritzbox, Farbdrucker, S/W Laserdrucker, Raspi
>> 1, Raspi 2, Raspi 3)
>
> Offenkundig hast du schon ein größeres Heimnetz. Wenn da ein Angreifer
> im internen Netz ist, würde ich mir keine Sorgen mehr um meine FritzBox
> machen, sondern um:
> - SMB Shares -> Zugriff normalerweise unverschlüsselt, Passwörter können
> leicht abgegriffen werden
> - SMB Shares -> Wenn ich schon Zugriff habe, vielleicht
> lösche/verschlüssle ich Daten, um dich zu erpressen (Ransomware)
> - Druckaufträge -> Mitlesen der gedruckten Dokumente

Das ist mir alles bekannt und daher entsprechend abgesichert.
Hier geht es aber darum, dass auch der Datenverkehr bezüglich HTTP auch 
im LAN verschlüsselt ist und dafür braucht man eben HTTPS und 
vertrauenswürdige Zertifikate.

> Nano schrieb:
>> Eine eigene CA ist viel besser, weil man so dem Browser NUR EINE CA
>> beibringen muss und ALLE Zertifikate aller Geräte im eigenen Haus LAN
>> sind damit dann abgedeckt, wenn man für diese eine mit dieser CA
>> signierten Zertifikat ausstellt.
>
> Eine eigene CA kann man machen. Wenn dann, aber bitte richtig.

Definiere richtig.

Eine CA kann ein USB Stick mit Live CD und offline Rechner sein und den 
USB Stick lagert man dann im Tresor oder glaubst du jetzt, ein CA wäre 
ein Server, der im LAN steht?

> Ich habe
> lang genug selber eine interne CA betrieben,

Aha, also doch Server.

> um das beurteilen zu
> können.

Nein, ich glaube dann nicht. Denn siehe oben.


> Die bringt dir genau gar nichts, wenn nicht hinreichend sicher
> implementiert.

Siehe oben, sicherer geht das gar nicht.


> Ich ziehe inzwischen aber Let's Encrypt
> Zertifikate auch für interne Systeme vor. Das spart mir noch den ganzen
> Aufwand mit der Verwaltung einer eigenen CA und dem ausrollen der
> Zertifikate.

Wenn du unter CA einen Server verstehst und den auch noch verwalten 
musst, dann bist du selber schuld. Und ja, dein System ist dann 
natürlich anfälliger als meines.

Nano schrieb:
> Es macht schon einen Unterschied ob der Traffic gezielt über Server des
> Angreifers geleitet wird und er somit alles kontrolliert, oder der
> Traffic über beliebige Server läuft, von denen die meisten irgendwelchen
> ISP Anbietern gehören die an deinen Daten kein großes Interesse haben
> und Gesetzen unterliegen.

WAN Verbindungen sind nicht vertrauenswürdig. PUNKT. Dementsprechend ist 
das egal, wo die Daten lang gehen. Die Daten müssen auf dem Transportweg 
wirksam geschützt werden und das werden sie. Die NSA liest auch immer 
mit, und die hält sich bekanntermaßen weder an Gesetze, noch ist sie 
vertrauenswürdig. Und nochmal: Das kann der Angreifer auch ohne, dass er 
die FritzBox übernimmt, denn im Szenario hier muss er vorher im internen 
Netz sein. Machine in the middle hatte ich ja schon genannt.

Nano schrieb:
> Er könnte dann einen Server betreiben.

Lohnt sich an den meisten deutschen DSL/COAX/Glasfaser Anschlüssen 
nicht, dafür gibt es viel zu viele Server in Rechenzentren, die sich 
viel leichter kapern lassen und eine brauchbare Bandbreite im Upload 
haben.

Nano schrieb:
> Das ist mir alles bekannt und daher entsprechend abgesichert.
> Hier geht es aber darum, dass auch der Datenverkehr bezüglich HTTP auch
> im LAN verschlüsselt ist und dafür braucht man eben HTTPS und
> vertrauenswürdige Zertifikate.

Respekt, würde ich ja rein aus Neugier tatsächlich mal testen wollen. 
Das ist aber wohl eher nicht der Standard, weder in Heim-, noch in 
Firmennetzen.

Nano schrieb:
> Definiere richtig.

Habe ich bereits oben. Hier zitiere ich mich daher mal selbst:

Carla Audimarie schrieb:
> Auch Dinge wie CRL oder
> OCSP kann kaum eine interne CA. In vielen Fällen macht es das unter
> Sicherheitsaspekten schlimmer.

Nano schrieb:
> Eine CA kann ein USB Stick mit Live CD und offline Rechner sein und den
> USB Stick lagert man dann im Tresor oder glaubst du jetzt, ein CA wäre
> ein Server, der im LAN steht?

Eine CA ohne einen Server macht keinen Sinn. Natürlich kannst du 
Zertifikate offline signieren. Die Verteilung von CRL und der Betrieb 
eines OCSP Responders geht aber nicht serverless. Hast du das nicht, 
kannst du kein kompromittiertes Zertifikat sperren und bei den im 
Heimgebrauch üblichen Laufzeiten von 10 Jahren musst du folglich deine 
gesamte CA wegwerfen.

Nano schrieb:
> Nein, ich glaube dann nicht. Denn siehe oben.

Doch, das glaube ich. Denn siehe oben.

Nano schrieb:

> Siehe oben, sicherer geht das gar nicht.

Siehe oben, es geht viel sicherer.

Nano schrieb:
> Wenn du unter CA einen Server verstehst und den auch noch verwalten
> musst, dann bist du selber schuld. Und ja, dein System ist dann
> natürlich anfälliger als meines.

Du hast einfach keine Ahnung.

Carla Audimarie schrieb:
> Nano schrieb:
>> Das ist mir alles bekannt und daher entsprechend abgesichert.
>> Hier geht es aber darum, dass auch der Datenverkehr bezüglich HTTP auch
>> im LAN verschlüsselt ist und dafür braucht man eben HTTPS und
>> vertrauenswürdige Zertifikate.
>
> Respekt, würde ich ja rein aus Neugier tatsächlich mal testen wollen.
> Das ist aber wohl eher nicht der Standard, weder in Heim-, noch in
> Firmennetzen.

Danke. Ja, im Heimnetz dürften die wenigsten das so machen.
Im Firmennetz kommt's auf das Einsatzfeld an, da kann man das in manchen 
Abschnitten durchaus erwarten.


> Eine CA ohne einen Server macht keinen Sinn.

Natürlich macht es das. Du brauchst für ein LAN nämlich nicht mehr als 
den Publik Key des CA um die signierten Zertifikate zu überprüfen und 
die signierten Zertifikate selbst. Mehr brauchst du nicht. Punkt.

CA bedeutet zudem nicht mehr als Certificate Authority, es bedeutet 
nicht Server.


Ein Server wird erst wichtig, wenn du einen CA professionell betreiben 
willst, wo andere im großen Umfang dann ihre Zertifikate signieren 
lassen können und da muss der Rechner, mit dem die Zertifikate 
ausgestellt werden dann schon gut abgeschottet sein.
Bei extrem wichtigen CAs, die z.B. Zertifkate für Banken ausstellen. 
kann man auch hier offline Rechner und Handarbeit beim Weg vom Netz zum 
offline Rechner erwarten.


> Natürlich kannst du
> Zertifikate offline signieren. Die Verteilung von CRL und der Betrieb
> eines OCSP Responders geht aber nicht serverless. Hast du das nicht,
> kannst du kein kompromittiertes Zertifikat sperren

1. Wie soll das Zertifikat den kompromittiert werden, wenn die CA 
Offline ist?
2. Da ich Zugang zu allen Geräten habe, ist ein Austausch der 
Zertifikate und des CA Public Keys gar kein Thema.

> und bei den im
> Heimgebrauch üblichen Laufzeiten von 10 Jahren musst du folglich deine
> gesamte CA wegwerfen.

Da 1 extrem unwahrscheinlich ist, ist das kein Thema.
Und sollte es im unwahrscheinlichen Falle aus irgendeinem Grund mal 
nötig sein, z.b. Schlüsselimplementierung war fehlerhaft, ist das CA und 
Zertifikate neu machen kein Ding. Der Aufwand ist auf jeden Fall 
deutlich geringer, als 365 Tage lang nen eigenen Server zu betreiben.


>> Siehe oben, sicherer geht das gar nicht.
>
> Siehe oben, es geht viel sicherer.

Offline signierte Zertifikate sind die sicherste Form, besser geht es 
nicht. Zertifikate für Banken werden genau so erstellt, zumindest darfst 
du das erwarten.
Sobald du den Prozess ins Netz einfügst und automatisierst, wie bspw. 
bei Let's encrypt, hast du eine angreifbare Schwachstelle.


>> Wenn du unter CA einen Server verstehst und den auch noch verwalten
>> musst, dann bist du selber schuld. Und ja, dein System ist dann
>> natürlich anfälliger als meines.
>
> Du hast einfach keine Ahnung.

Die hast du nicht, denn CA bedeutet nur Certificate Authority.

Nano schrieb:
> 1. Wie soll das Zertifikat den kompromittiert werden, wenn die CA
> Offline ist?

Jap, hast echt keine Ahnung. Nicht die CA selbst wird kompromittiert, 
aber einer deiner Server, der ein signiertes Zertifikat nutzt. Das ist 
erstens weitaus weniger unwahrscheinlich und zweitens genau das, was mit 
CRL und OCSP mitigiert wird. Setzt aber einen Server voraus. Du 
betreibst deine eigene CA eben nicht richtig. PUNKT.

Nano schrieb:
> Bei extrem wichtigen CAs, die z.B. Zertifkate für Banken ausstellen.
> kann man auch hier offline Rechner und Handarbeit beim Weg vom Netz zum
> offline Rechner erwarten.

Der Angriffspunkt ist selten die CA selbst. Da gibt es richtige 
Verfahren, wie zum Beispiel HSM. Der Angriffspunkt ist der Server, der 
das Zertifikat nutzt und der ist wohl kaum vom Netz getrennt.

Nano schrieb:
> Die hast du nicht, denn CA bedeutet nur Certificate Authority.

Bei dir ist wohl noch nicht angekommen, dass man eine CA, wenn man es 
professionell macht, im Rahmen einer PKI betreibt. Allein schon, weil 
eben nicht alles so einfach ist wie in deiner kleinen, heilen 
Heimumgebung.

Carla Audimarie schrieb:
> Der Angriffspunkt ist selten die CA selbst. Da gibt es richtige
> Verfahren, wie zum Beispiel HSM. Der Angriffspunkt ist der Server, der
> das Zertifikat nutzt und der ist wohl kaum vom Netz getrennt.

Und um noch weiter zu gehen nutzt man in der Regel eine Intermediate CA 
zur Ausstellung der Zertifikate. Die Root CA ist offline, die daraus 
erzeugten Intermediates sind natürlich in entsprechende Prozesse 
eingebunden, der Signing Key allerdings sicher in einem HSM verwahrt. So 
betreibt man so etwas richtig. Das was du machst ist einfach nur 
Bastelei. Richtig betreibt das aber zu hause eben keiner.

Carla Audimarie schrieb:
> Nano schrieb:
>> 1. Wie soll das Zertifikat den kompromittiert werden, wenn die CA
>> Offline ist?
>
> Jap, hast echt keine Ahnung. Nicht die CA selbst wird kompromittiert,
> aber einer deiner Server, der ein signiertes Zertifikat nutzt. Das ist
> erstens weitaus weniger unwahrscheinlich und zweitens genau das, was mit
> CRL und OCSP mitigiert wird. Setzt aber einen Server voraus. Du
> betreibst deine eigene CA eben nicht richtig. PUNKT.

Ich betreibe einen Kerberos Server als Authentifzierungsstelle, also was 
willst du?

Nano schrieb:
> Ich betreibe einen Kerberos Server als Authentifzierungsstelle, also was
> willst du?

Oh, Salamitaktik, wenn nichts mehr hilft. Wie ein Kerberos deine Server 
vor einem Angriff schützen soll, müsstest du aber mal ausführen.

Carla Audimarie schrieb:
> Nano schrieb:
>> Ich betreibe einen Kerberos Server als Authentifzierungsstelle, also was
>> willst du?
>
> Oh, Salamitaktik, wenn nichts mehr hilft. Wie ein Kerberos deine Server
> vor einem Angriff schützen soll, müsstest du aber mal ausführen.

Ich glaube wir reden am Thema vorbei und ich habe hier gerade 29 °C in 
der Wohnung wo der Rechner steht.

Guck in die alten Threads, zum Thema CA und Co habe ich da in den kalten 
Jahreszeiten schon genug geschrieben.

Nano schrieb:
> Ich glaube wir reden am Thema vorbei und ich habe hier gerade 29 °C in
> der Wohnung wo der Rechner steht.

Es ist besser nichts zu schreiben, als Müll zu schreiben.

Nano schrieb:
> Guck in die alten Threads, zum Thema CA und Co habe ich da in den kalten
> Jahreszeiten schon genug geschrieben.

Warum sollte ich die lesen? ICH weiß ja, wie man es richtig macht.

Ja, wie schon gesagt, mir ist es zu warm. Ich steige aus. Schönen Tag 
noch.

Was ich jetzt auf die Schnelle festgestellt habe:

OCSP ist eine nützliche Nachfrage 
https://de.wikipedia.org/wiki/Online_Certificate_Status_Protocol

Eine gute Zertifizierungsstelle braucht etwas Sicherheit gegen Feuer, 
Wasser, Sturm... und Leute, die sich darum kümmern.

Rolf M. schrieb:

> Naja, ein man in the middle würde sich freuen, wenn er sich einfach mit
> selbst signierten Zertifikaten dazwischen schalten könnte, ohne dass der
> Browser da irgendein Problem meldet.

Und was wäre, wenn der Server ein kompromittiertes Zertifikat einer 
etablierten CA verwenden würde?

Auch da würde der Browser erstmal kein Problem melden. Es sei denn, dass 
Zertifikat wäre "revoced" und der Server, der dies vermittelt, wäre 
erreichbar.

Nun ist es aber ein leichtes Unterfangen, die Erreichbarkeit bestimmter 
unliebsamer Server zu verhindern. Z.B. die genau solcher Server...

Was würde passieren? Bei jedem heutigen Browser folgendes: Timeout für 
Anfrage bei eben jenem Server läuft ab->Zertifikat wird akzeptiert.

Glaubst du nicht? Probier es aus. Ende der Ansage.