An meiner Fritzbox melde ich mich nur über WLAN an. Da kommt immer ein Hinweis, daß diese Verbindung nicht sicher ist. Laut AVM kann man das ignorieren, weil man ja in seinem eigenen Netz ist. Aber wird dann der Anmeldevorgang mit Paßwort im KLartext usw. nicht für jeden abhörbar? Mit wireshark konnte ich zumindest mein Paßwort nicht im Datenstrom finden.
Wenn du dir diese Meldung ersparen willst, dann verbinde dich nicht per http sondern per https. Das gibt dann eine andere Meldung, aber u.U. nur einmal.
:
Bearbeitet durch User
Tobi schrieb: > Mit wireshark konnte ich zumindest mein Paßwort nicht im Datenstrom > finden. Es gibt auch bei http Anmeldeverfahren, die nicht auf einer Klartextübertragung basieren. https://de.wikipedia.org/wiki/Challenge-Response-Authentifizierung
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.
c-hater 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. 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]. Man kann auch sein eigenes Zertifikat erstellen. Und dann richtig mit eigener CA arbeiten. Auch dann importiert man das eigene CA-Zertifikat natürlich als vertrauenswürdig. Bei der Fritzbox 7560 findet man alles auf der Seite: Internet -> Freigaben -> Fritzbox-Dienste [1] wie genau, hängt vom OS ab. Auf debianesken Linuxen verwendet man update-ca-certificates
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
:
Bearbeitet durch User
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.
Carla Audimarie schrieb: > Hier geht es aber offenkundig um eine Anmeldung aus > dem internen Netz. Genau. Problem siehe oben. Oliver
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.
Wer seinen Fritz bereits einmal per MyFritz angesprochen hat, könnte festgestellt haben, dass er keine Zertifikatsfehler bekommt. Das dabei verwendete Zertifikat ist auf jenen Namen ausgestellt, unter dem die Fritzbox beim dabei genutzten Dyn-DNS Verfahren bekannt ist. Also sowas wie iodqnccdcnklcnckceln.myfritz.net. Der ist damit eindeutig. Dieser Name ist (bei mir im DS-lite via IPv6) auch aus dem eigenen Netz direkt ansprechbar und das Zertifikat ist bereits via AVM/Fritz von einem alten Bekannten ausgestellt: Let's Encrypt. Völlig automatisch. Zertifikatsfehler gibt es dann also nur, wenn man über die IP oder fritz.box darauf zugreift. Verwendet man den .myfritz.net Namen, wird sich kein halbwegs aktueller Browser daran stören.
:
Bearbeitet durch User
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.
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.
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
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.
Carla Audimarie schrieb: > Und dann soll er den verschlüsselten HTPPS Traffic mitlesen und sogar > verändern? 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.
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.
c-hater schrieb: > 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... Doch. > Es meldet (vollkommen korrekt), dass es sich um ein selbstsigniertes > Zertifikat handelt, mit dem der Server sich ausweist. Er sagt beides. Bei mir sagt Firefox ganz konkret folgendes: "fritz.box verwendet ein ungültiges Sicherheitszertifikat. Dem Zertifikat wird nicht vertraut, weil es vom Aussteller selbst signiert wurde." > Und so ein Zertifikat ist nicht weniger sicher als eins, was von > irgendeiner verschissenen CA ausgestellt wurde, direkt oder indirekt. 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.
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.
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.