...mit ihrem Sicherheitswahn.
Da will ich mich in meine Fritz!Box einloggen - und was kommt da? Das hier:
So ein Quatsch. Bei Webseiten ist das ohne Zweifel angebracht, aber wenn ich mich im lokalen Netzwerk irgendwo mit einem Passwort anmelden muss, dann ist das doch absoluter Blödsinn!
andy11 
gelöscht_84526 „Jetzt übertreiben die bei Mozilla aber langsam....“
Ja, auch FritzBoxen haben ihren Stolz. ;-)
Andy
hatterchen1 gelöscht_84526 „Jetzt übertreiben die bei Mozilla aber langsam....“
Dann hast Du dich aber lange nicht mehr auf deiner FB eingeloggt.
gelöscht_84526 hatterchen1 „Dann hast Du dich aber lange nicht mehr auf deiner FB eingeloggt.“
Falsch. Das mache ich eigentlich jeden Tag. Nur hatte ich den FF nicht aktualisiert, bei mir lief noch irgendwas mit der 51. Seitdem ich heute auf die 52 upgedatet habe, kommt dieser bescheuerte Hinweis.
Andreas42 gelöscht_84526 „Jetzt übertreiben die bei Mozilla aber langsam....“
Hi!
Ich bin mir unsicher, ob eine Ausnahme der Sicherheitswarnung für lokale IP-Adressen sinnvoll ist. Ich fürchte damit könnte Schindluder getrieben werden. 
Das ist auch nicht das erste Mal, dass es zu "Problemen" im Zusammenhang mit Browsersicherheitsprüfungen und DSL-Boxen kommt.
In dem Fall waren abgelaufene Sicherheitszertifikate im Speedport die Ursache.
Bei AVM erwarte ich allerdings, dass die das abstellen.
Bis dann
Andreas
gelöscht_84526 Andreas42 „Hi! Ich bin mir unsicher, ob eine Ausnahme der Sicherheitswarnung für lokale IP-Adressen sinnvoll ist. Ich fürchte damit ...“
Ich habe das Problem einfach gelöst, indem ich vor die 192.168.178.1 ein https gesetzt habe. Da kam dann die Warnung, dass die Seite nicht sicher ist und man/ich konnte eine Ausnahmeregel erstellen. Von daher ist es eigentlich kein Problem, aber unsinnig ist es trotzdem.
Merkwürdigerweise tritt der "Fehler" nicht auf, wenn ich unter Linux "CUPS" aufrufe, also 127.0.0.1:631
Wenn ich dann dort was konfigurieren will - mich also als Administrator einloggen muss -, dann habe ich keine Probleme bei der Eingabe des Passwortes und des Usernamens, da erscheint der Hinweis dann nicht.
odin4 gelöscht_84526 „Ich habe das Problem einfach gelöst, indem ich vor die 192.168.178.1 ein https gesetzt habe. Da kam dann die Warnung, dass ...“
Hallo King-Heinz,
Danke für den Tipp mit der Ausnahmeregel. Endlich ist das Nervige weg!
:-)))
gelöscht_84526 odin4 „Hallo King-Heinz, Danke für den Tipp mit der Ausnahmeregel. Endlich ist das Nervige weg! :-“
Endlich ist das Nervige weg!
Ja, so etwas kann ganz schön auf die Nüsse gehen.... :-)
gelöscht_189916 gelöscht_84526 „Ich habe das Problem einfach gelöst, indem ich vor die 192.168.178.1 ein https gesetzt habe. Da kam dann die Warnung, dass ...“
Merkwürdigerweise tritt der "Fehler" nicht auf, wenn ich unter Linux "CUPS" aufrufe, also 127.0.0.1:631
Naja - für denCUPS-Dienst auf localhost wird es wohl keine Zertifikate geben und daher ist das dem Browser eher zweitens. Für die Oberfläche der Box dagegen gibt es dieses und das ist jedoch nicht so hinterlegt, dass der Browser über eine Datenbankabfrage selbiges prüfen kann, also wird die Verbindung als unsicher bemeckert.
https://avm.de/service/fritzbox/fritzbox-7490/wissensdatenbank/publication/show/1489_Meldung-Sicherheitszertifikat-ist-nicht-vertrauenswuerdig/
Ein kleiner Teil dieser ganzen Zertifiziererei ist momentan der Clinch zwischen Symantec und Google:
https://www.heise.de/security/meldung/Google-und-Symantec-Kein-akuter-Handlungsbedarf-fuer-Zertifikats-Inhaber-3669129.html?wt_mc=rss.security.beitrag.atom
Dagegen gab es ja u.A. schon mit diversen älteren Routern eines grossen deutschen Telekommunikations-Anbieters Probleme, weil die für ihre Büchsen keine Zertifikate mehr hinterlegt haben und der Browser dann deswegen auch die Chose mit der Ausnahmeregel haben wollte.
https://www.telekom.de/hilfe/downloads/zertifikat_speedports.pdf
Das war allerdings bereits eine gute Weile vor https im Protokoll.
PS. Sehe gerade, dass Andreas bereits den Erklärbär gegeben hat;-)
dalai gelöscht_84526 „Ich habe das Problem einfach gelöst, indem ich vor die 192.168.178.1 ein https gesetzt habe. Da kam dann die Warnung, dass ...“
Merkwürdigerweise tritt der "Fehler" nicht auf, wenn ich unter Linux "CUPS" aufrufe, also 127.0.0.1:631
Logisch nicht, denn das ist localhost, verlässt also deinen Rechner gar nicht. Etwas anderes ist es, wenn ein Ziel im LAN oder Internet erreicht werden soll, denn die sind potentiell eben nicht sicher. Ja, richtig gelesen, im LAN kann ebenfalls ein Angreifer sitzen, schließlich gibt's dafür auch genügend Wege: WLAN, "offene" IoT-Geräte, Gäste, Malware auf dem eigenen PC, XSS-Angriffe usw.
Die Warnung ist schon sinnvoll, auch wenn sie nervig sein kann. Man kann sie aber problemlos dadurch loswerden, dass man zur Konfiguration interner Geräte einen separaten (älteren) Browser benutzt. Die Warnhinweise werden nämlich immer weiter zunehmen. Chrome warnt schon (oder wird es tun), wenn unverschlüsselte Seiten aufgerufen werden. Weiterhin gibt's Warnungen bei schwacher Verschlüsselung wie z.B. mit SHA-1 etc.
Grüße
Dalai
mi~we Andreas42 „Hi! Ich bin mir unsicher, ob eine Ausnahme der Sicherheitswarnung für lokale IP-Adressen sinnvoll ist. Ich fürchte damit ...“
Bei AVM erwarte ich allerdings, dass die das abstellen.
AVM empfiehlt schlicht, diese blödsinnige Warnung einfach zu ignorieren 
:
https://avm.de/service/fritzbox/fritzbox-7490/wissensdatenbank/publication/show/3303/
gelöscht_84526 mi~we „AVM empfiehlt schlicht, diese blödsinnige Warnung einfach zu ignorieren : ...“
Natürlich funktioniert das auch, man kann sein Passwort trotz des Hinweises eingeben, ist halt nur irgendwie lästig.
Xdata gelöscht_84526 „Natürlich funktioniert das auch, man kann sein Passwort trotz des Hinweises eingeben, ist halt nur irgendwie lästig.“
Lästig - genau, da Fragen von einigen verunsicherten Usern kommen.
Habe im Bekanntenkreis wegen dieses Unsinns schon
besorgte Nachfragen gehabt.
Die die das "Schloss" gleich bei der Einwahl haben sind auch nicht sicherer ..
ullibaer gelöscht_84526 „Jetzt übertreiben die bei Mozilla aber langsam....“
Bei mir geht alles und diese Meldung kommt nicht. Habe auch die FritzBox 7490.
Ich gebe immer fritz.box in die Adresszeile beim Firefox ein.
Firefox Version 52.0.2 64-Bit.
Gruß Ulli
Hellspawn gelöscht_84526 „Jetzt übertreiben die bei Mozilla aber langsam....“
Naja, andererseits, wer sagt denn das im LAN niemand zuhört?
Bei den ganzen haarsträubenden IoT Sicherheitslücken, würde es mich nicht wundern wenn auf dem Fernseher Malware installiert ist und die hin und wieder mal im LAN etwas ARP spooft und einfach mal mitschneidet was so kommt.
Denke die Idee das eine Firewall zwischen Gut (LAN) und Böse (Internet) trennt sollte überdacht werden da auch viel gammeliges im LAN sich ansammelt... traue niemandem :-)
gelöscht_189916 Hellspawn „Naja, andererseits, wer sagt denn das im LAN niemand zuhört? Bei den ganzen haarsträubenden IoT Sicherheitslücken, ...“
Naja, andererseits, wer sagt denn das im LAN niemand zuhört?
Könnte aber ein wie auch immer gearteter LAN-Teilnehmer unter einer anderen IP so etwas mitschneiden und würde da die https-Abfrage selbiges verhindern? M.E. ginge das besser über einen MITM.
Das der ganze IoT-Krempel sicherheitsseitig die Katastrophe ist und vernetzte Geräte grundsätzlich nur im LAN und nicht Richtung draussen bimmeln sollten, interessiert irgendwie nicht. Es gibt ja Router, die meckern beim Abschalten der Fernwartung für das Eingreifen des Herstellers. Ich spiele meine Updates lieber selbst ein;-)
Borlander gelöscht_189916 „Könnte aber ein wie auch immer gearteter LAN-Teilnehmer unter einer anderen IP so etwas mitschneiden und würde da die ...“
Könnte aber ein wie auch immer gearteter LAN-Teilnehmer unter einer anderen IP so etwas mitschneiden und würde da die https-Abfrage selbiges verhindern?
Mitschneiden kannst Du generell nicht verhindern. Aber bei verschlüsselter Übertragungen (mit kryptographisch sicheren Verfahren) kannst Du die Inhalte nicht einfach mal eben ohne jede Mühe abgreifen…
gelöscht_189916 Borlander „Mitschneiden kannst Du generell nicht verhindern. Aber bei verschlüsselter Übertragungen mit kryptographisch sicheren ...“
Mitschneiden kannst Du generell nicht verhindern.
Das ist klar.
Nehmen wir den Fall Login Fritzbox und den Ist-Zustand Einloggen über Kabel, nur von einem PC und dieser mit fester IP.
Ein weiterer nur als Client im selben (W)LAN hängender Rechner kann m.E. das Passwort unabhängig ob verschlüsselt oder nicht eher nicht abgreifen. Dazu müsste er dazwischen sitzen, deshalb der Ansatz MITM, jedenfalls wäre mir nur mit Mitschneiden da keine Möglichkeit bekannt. Das wäre eher so der Punkt bei WPS und ähnlichem.
Dann ist jedoch selbst https nur scheinsicher, weil sich ja z.B. selbst eine AV wie jüngst Kaspersky dazwischen hängen kann, um den Traffic zu "filtern" und dadurch den Appendix s ad absurdum führt.
Borlander gelöscht_189916 „Das ist klar. Nehmen wir den Fall Login Fritzbox und den Ist-Zustand Einloggen über Kabel, nur von einem PC und dieser ...“
Nehmen wir den Fall Login Fritzbox und den Ist-Zustand Einloggen über Kabel, nur von einem PC und dieser mit fester IP. Ein weiterer nur als Client im selben (W)LAN hängender Rechner kann m.E. das Passwort unabhängig ob verschlüsselt oder nicht eher nicht abgreifen. Dazu müsste er dazwischen sitzen, deshalb der Ansatz MITM
Doch. Es gibt verschiedene Änsätze um auch in geswitchten Umgebungen den Datenverkehr abzugreifen. Siehe
Dann ist jedoch selbst https nur scheinsicher, weil sich ja z.B. selbst eine AV wie jüngst Kaspersky dazwischen hängen kann, um den Traffic zu "filtern"
Wenn Du Dir HTTPs auf dem Client kaputt machst, dann bist Du aber auch selbst schuld. Deshalb sollte man von "Sicherheitslösungen" die eine vertrauenswürdige Zertifikatskette zerstören. Nachdem Du einmalig das selbst signierte Zertifikat akzeptiert hast bist Du aber dank Https auch vor Man-in-the-Middle-Angriffe geschützt. Wenn zu dem Zeitpunkt jemand in der Leitung hängt dann hast Du sowieso verloren.
gelöscht_189916 Borlander „Doch. Es gibt verschiedene Änsätze um auch in geswitchten Umgebungen den Datenverkehr abzugreifen. Siehe ...“
MAC-Flooding fällt hier schon einmal heraus, wenn man nicht hinter dem Router einen Switch bammeln hat. In kritischen Netzen wirden sicher auch die Adrssen begrenzt sein und massenhafte Anfragen neuer MAC verworfen, damit es nicht zum Überlauf kommt.
Zumindest sollte dieser eine Mail an den Admin generieren, damit dieser die Ursache suchen kann.
Mit einer gefälschten ARP oder MAC hätte man eine Chance, setzt aber voraus, das man zumindest einmal zeitgleich mit dem zu knackenden Client im Netz ist und dann bereits zwischen PC und Router sitzt, um die Eingabe mittels Sniffer abzufangen.
Die Sache mit den Zertifikaten ist insofern kritischer, wenn eben ein Selbstgebasteltes untergejubelt wird und dazu verleitet, dieses zu bestätigen und auf die 'sichere Seite' einzuloggen. Dann sind wir wieder beim Ausgangspunkt und ich kann die Meldung genauso wegklicken oder eine Ausnahme erstellen, wobei Letzteres in diesem Szenario schon wieder 'unsicherer' ist. Ich bekomme dann ja nicht mit, wann und ob da ein Umstellen erfolgt und gebe dann praktisch den Zugang permanent frei ohne Prüfung, bis ich die Ausnahme im Browser wieder lösche.
Grundsätzlich vermute ich hier, dass sich AVM erst einmal nur die Kosten der Zertifizierung sparen wird für diesen Vorgang, der eigentlich nur intern stattfindet, es sei denn man hat den Wartungs-Port offen.
In der aktuellen c't wird das gerade thematisiert.
Mist - jetzt muss ich wieder Geld ausgeben;-)
Edit: Eine nette Diskussion darüber:
https://blog.root1024.ch/betriebssystem/linux/switch-mac-flooding-fluten/
Borlander gelöscht_189916 „MAC-Flooding fällt hier schon einmal heraus, wenn man nicht hinter dem Router einen Switch bammeln hat. In kritischen ...“
MAC-Flooding fällt hier schon einmal heraus, wenn man nicht hinter dem Router einen Switch bammeln hat.
Für gewöhnlich hast Du im Router bereits einen Switch drin.
In kritischen Netzen
Sollte man vor Allem keine unverschlüsselten Prokolle verwenden ;-)
gelöscht_189916 Borlander „Für gewöhnlich hast Du im Router bereits einen Switch drin. Sollte man vor Allem keine unverschlüsselten Prokolle ...“
Sollte man vor Allem keine unverschlüsselten Prokolle verwenden ;-)
Hilft aber auch nicht immer:
https://threatpost.com/lessons-from-top-to-bottom-compromise-of-brazilian-bank/124770/
https://www.heise.de/security/meldung/Game-Over-Online-Raeuber-kapern-komplette-Domain-Infrastruktur-einer-Bank-3677164.html?wt_mc=rss.security.beitrag.atom
Borlander Hellspawn „Naja, andererseits, wer sagt denn das im LAN niemand zuhört? Bei den ganzen haarsträubenden IoT Sicherheitslücken, ...“
Denke die Idee das eine Firewall zwischen Gut (LAN) und Böse (Internet) trennt sollte überdacht werden da auch viel gammeliges im LAN sich ansammelt... traue niemandem :-)
In der aktuellen c't wird das gerade thematisiert.
