- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,279
- Punkte für Reaktionen
- 1,754
- Punkte
- 113
Das hier stand ursprünglich in einem Thread zur aktuellen Labor-Version der 7490, da es aber alle Modelle betrifft, habe ich es doch in einen eigenen Thread gepackt.
-----------------------------------------------------
Wie die Zeit vergeht (damit hat AVM vermutlich auch nicht wirklich gerechnet) ... aber da ist es inzwischen fast Mitte/Ende Juli und Google will im nächsten Release mit der (heute vor 5 Monaten mit Termin/Version verkündeten) Kennzeichnung aller unverschlüsselten HTTP-Seiten endlich ernst machen - siehe auch hier: https://heise.de/-4104569 und im IPPF hatten wir das Thema der TLS-Verschlüsselung auch im LAN (als "gute Idee", die AVM mal umsetzen sollte) ja schon öfter.
Ich weiß auch nicht, ob die bei heise.de kolportierten 60% als Anteil von Chrome am Browser-Markt sich auf PCs oder alles (also inkl. Android und Smartphones/Tablets) beziehen ... aber wenn sich AVM da nicht noch etwas einfallen läßt für FRITZ!OS 7 (zumindest eine Einstellung, mit der der Kunde zwischen "sicher" und "weniger sicher" (um das "un"-Wort zu vermeiden) wählen kann), dann wird bald auch die FRITZ!Box nur mehr zum "alten" (und unsicheren, denn es ist sicherlich unbestreitbar, daß auch LAN-Zugriffe mitgesnifft werden können - auch Firefox warnt ja schon lange vor der unverschlüsselten Übertragung des Login-Formulars, wobei diese Warnung nicht wirklich zutreffend war, weil das Kennwort zuvor per Javascript gehasht wird) Internet gehören, das in Chrome (und im Anschluß dann garantiert auch in weiteren Browsern) per se als "unsicher" markiert wird und damit den Benutzer auch wieder darauf trainiert, daß es "gar nicht so schlimm" wäre, wenn so etwas für eine Seite angezeigt wird.
Ich finde durchaus, daß AVM damit auch seinen Kunden einen Bärendienst erweist, wenn man sie auf falsche Informationen konditioniert.
Nun ist es sicherlich kein ganz einfaches Thema und die Frage, wo man das Zertifikat für "fritz.box" herbekommt, ist auch nicht so ohne weiteres zu beantworten ... aber selbst dann, wenn eine Box ein LE-Zertifikat für ihre MyFRITZ!-Adresse hat, führt das (m.W.) noch immer nicht dazu, daß AVM dann unverschlüsselte Zugriffe auf "fritz.box" automatisch auf die MyFRITZ!-Adresse umleitet per HTTP-Redirection (302).
Das Behandeln von LE-Zertifikaten wird ja mit FRITZ!OS 7 wohl kommen und das könnte ohne weiteres auch auf andere DynDNS-Dienste erweitert werden, wenn man es nur will - nicht jeder Kunde wird von MyFRITZ! als DynDNS-Server begeistert sein; aber selbst für diese "braven Kunden", die fleißig MyFRITZ! benutzen, tut AVM an dieser Stelle eigentlich nichts, um die Sicherheit auch im LAN zu erhöhen (ja, ich höre mich an wie eine kaputte Schallplatte).
Eine solche Redirection im LAN sollte dann - dank NAT-Hairpinning - ja dazu führen, daß diese "Umleitung" für den Benutzer nicht mit zusätzlichen Mühen verbunden ist (nicht mal bei abweichendem Port, wobei AVM hier ja auch dafür sorgen könnte, daß intern und extern verschiedene Portnummern genutzt werden können bzw. daß intern in jedem Falle 443 verwendet werden kann) ... es fällt halt die "einfache" Adresse "fritz.box" in der URL weg.
Wenn AVM nicht noch etwas geändert hat (ich habe das jetzt schon wieder ein paar (Labor-)Versionen nicht weiter verfolgt - genauer: zuletzt mit 06.98-56149 bei einer 7580 getestet, die nun gar nicht zu diesem Thread passen würde, aber irgendein Modell muß man sich aussuchen beim Schreiben und die 7490 ist wohl immer noch am weitesten verbreitet), dann geht man sogar hin und verhindert aktiv, daß der Kunde mit einem normalen Browser sich nur einmal mit der Sicherheitswarnung für ein "selbstsigniertes Zertifikat" befassen muß, wenn er selbst für die Verwendung von HTTPS auch beim Zugriff auf der LAN-Seite sorgt.
Wie macht man das? Man generiert einfach bei jedem Wechsel der öffentlichen IP-Adresse (das gilt natürlich auch dann, wenn die Box als LAN1-Router arbeitet - als LAN-Client habe ich es nicht geprüft) ein neues, selbstsigniertes Zertifikat mit der öffentlichen IP-Adresse als "Common Name". Da die Box dieses Zertifikat auch beim internen Zugriff über HTTPS vorlegt (solange nicht ein LE-Zertifikat vorhanden ist und der Zugriff über diesen DNS-Namen erfolgt), wird auch jedesmal erneut die "Zertifikatwarnung" des Browsers getriggert - da kann man (ohne ein selbsterstelltes Zertifikat für "fritz.box", denn glücklicherweise wird da dann lieber der "Namenskonflikt" hingenommen von AVM - warum das wohl so ist, spekuliere ich gleich) machen, was man will.
Warum macht AVM überhaupt solchen Blödsinn? Nun ... man hat bei AVM sich vor ein paar Jahren (Sommer 2014) entschlossen, eine Lücke, die durch den Einsatz und das ständige Neugenerieren eines "self-signed certificate" ohne ausreichende Prüfung vor einem MITM-Angriff entstand, auf dem Weg zu schließen, daß man in den AVM-eigenen FRITZ!Apps nicht mehr komplett auf die Zertifikatprüfung verzichtete, sondern den öffentlichen Schlüssel aus dem Zertifikat "angepinnt" hat.
Damit kann das FRITZ!OS soviele Zertifikate generieren, wie es möchte, solange sich der zugrundeliegende Schlüssel (privater und öffentlicher Teil gehören zusammen, damit muß bei identischem öffentlichen Schlüssel auch der private Teil derselbe sein - diese "Schlußfolgerung" ist zulässig) nicht ändert - die App akzeptiert dieses. Ein Angreifer als MITM kennt dann diesen Schlüssel wieder nicht und müßte einen neuen präsentieren ... diese Lücke ist damit also geschlossen, wenn die App beim Auftauchen eines neuen Schlüssels eine entsprechende Warnung ausgibt.
Leider verleitet diese "privilegierte" Stellung der FRITZ!Apps AVM jetzt aber dazu, davon ausgiebig Gebrauch zu machen und dabei die Verwender anderer Anwendungen, die per HTTPS auf das GUI zugreifen wollen (eben bis hin zum PC-basierten Browser), vollkommen aus den Augen zu verlieren ... anders kann ich mir diesen "Müll" (und auch wenn das nur meine persönliche Ansicht ist - als solchen würde ich das bezeichnen) nicht erklären.
Es gäbe nämlich auch Lösungen (die sind auch nicht neu und selbst hier schon mehrmals ventiliert worden), bei denen man sich seine Zertifikate auf der Box neu generieren könnte und trotzdem nur ein einziges Mal (pro FRITZ!Box, je nach Umsetzung vielleicht noch nach jeder "Werkseinstellung") ein Zertifikat im Browser oder in einer App anpinnen muß ... dazu muß man nur in der Box ein eigenes "CA-Zertifikat" generieren (das aktuell selbstsignierte Zertifikat ist auch nichts anderes, es darf nur nicht verwendet werden, um weitere Zertifikate zu unterschreiben - das ist der einzige (signifikante) Unterschied zwischen den beiden) und jedes weitere Zertifikat dann mit diesem - einmal erstellten - CA-Zertifikat signieren.
Es gibt sogar eine X.509v3-Option für solche CA-Zertifikate, mit der man dann sicherstellen kann, daß jedes weitere Zertifikat in der Kette nur unterhalb einer bestimmten Domain liegen darf: "permittedSubtrees" in https://tools.ietf.org/html/rfc5280#section-4.2.1.10 - setzt man diese, ist man (als Hersteller/Autor der Software, die das Zertifikat generiert) auch wieder so weit aus der Verantwortung für die mit diesem Zertifikat signierten Server-Zertifikate, daß damit unterschriebene Zertifikate für google.com oder irgendeine andere Domain außerhalb des eigenen Namensraums liegen würden und ein Browser (der seinerseits diese Vorgaben korrekt umsetzt) diese nicht akzeptieren sollte (selbst wenn ein Angreifer den privaten Key der FRITZ!Box-internen CA in die Hände bekommt).
Dann reicht es, in einem Browser (oder einer App) dieses CA-Zertifikat anzupinnen und jedes für einen konkreten TLS-gesicherten Zugriff (vom Server - aka FRITZ!OS) vorgelegte Zertifikat darauf zu prüfen, ob es von einer "trusted authority" stammt, wobei dann eben zu den "üblichen Verdächtigen" noch die eigene CA im FRITZ!OS zählen würde (die anderen muß man natürlich auch noch berücksichtigen, falls jemand "richtige" öffentliche Zertifikate - dazu gehört auch LE - verwenden will).
Ja, das ist etwas Arbeit und es erfordert auch etwas Koordination zwischen FRITZ!OS-Versionen und den passenden Apps (notfalls müssen die eben beide Verfahren beherrschen) ... aber die Ankündigungen der Browser-Hersteller sind auch nicht gänzlich neu - genauso wenig wie die Argumente, die zu diesen Entscheidungen geführt haben und die wohl kaum von der Hand zu weisen sind. Im Gegensatz zu "normalen Browsern" (auch auf Mobilgeräten) sind die Apps eben selbst dafür verantwortlich, wie sie die Integrität einer TLS-Verbindung absichern (wobei auch die verschiedenen Betriebssysteme meist schon Mechanismen zum "Anpinnen" von Zertifikaten oder Schlüsseln anbieten) ... aber das Universum an möglichen HTTP-Clients bei den Kunden besteht auch nicht nur aus den FRITZ!Apps von AVM.
PS: Wenn jemand konzeptionelle Fehler sieht bei der Verwendung einer CA auf der FRITZ!Box, diskutiere ich die gerne aus ...
-----------------------------------------------------
Wie die Zeit vergeht (damit hat AVM vermutlich auch nicht wirklich gerechnet) ... aber da ist es inzwischen fast Mitte/Ende Juli und Google will im nächsten Release mit der (heute vor 5 Monaten mit Termin/Version verkündeten) Kennzeichnung aller unverschlüsselten HTTP-Seiten endlich ernst machen - siehe auch hier: https://heise.de/-4104569 und im IPPF hatten wir das Thema der TLS-Verschlüsselung auch im LAN (als "gute Idee", die AVM mal umsetzen sollte) ja schon öfter.
Ich weiß auch nicht, ob die bei heise.de kolportierten 60% als Anteil von Chrome am Browser-Markt sich auf PCs oder alles (also inkl. Android und Smartphones/Tablets) beziehen ... aber wenn sich AVM da nicht noch etwas einfallen läßt für FRITZ!OS 7 (zumindest eine Einstellung, mit der der Kunde zwischen "sicher" und "weniger sicher" (um das "un"-Wort zu vermeiden) wählen kann), dann wird bald auch die FRITZ!Box nur mehr zum "alten" (und unsicheren, denn es ist sicherlich unbestreitbar, daß auch LAN-Zugriffe mitgesnifft werden können - auch Firefox warnt ja schon lange vor der unverschlüsselten Übertragung des Login-Formulars, wobei diese Warnung nicht wirklich zutreffend war, weil das Kennwort zuvor per Javascript gehasht wird) Internet gehören, das in Chrome (und im Anschluß dann garantiert auch in weiteren Browsern) per se als "unsicher" markiert wird und damit den Benutzer auch wieder darauf trainiert, daß es "gar nicht so schlimm" wäre, wenn so etwas für eine Seite angezeigt wird.
Ich finde durchaus, daß AVM damit auch seinen Kunden einen Bärendienst erweist, wenn man sie auf falsche Informationen konditioniert.
Nun ist es sicherlich kein ganz einfaches Thema und die Frage, wo man das Zertifikat für "fritz.box" herbekommt, ist auch nicht so ohne weiteres zu beantworten ... aber selbst dann, wenn eine Box ein LE-Zertifikat für ihre MyFRITZ!-Adresse hat, führt das (m.W.) noch immer nicht dazu, daß AVM dann unverschlüsselte Zugriffe auf "fritz.box" automatisch auf die MyFRITZ!-Adresse umleitet per HTTP-Redirection (302).
Das Behandeln von LE-Zertifikaten wird ja mit FRITZ!OS 7 wohl kommen und das könnte ohne weiteres auch auf andere DynDNS-Dienste erweitert werden, wenn man es nur will - nicht jeder Kunde wird von MyFRITZ! als DynDNS-Server begeistert sein; aber selbst für diese "braven Kunden", die fleißig MyFRITZ! benutzen, tut AVM an dieser Stelle eigentlich nichts, um die Sicherheit auch im LAN zu erhöhen (ja, ich höre mich an wie eine kaputte Schallplatte).
Eine solche Redirection im LAN sollte dann - dank NAT-Hairpinning - ja dazu führen, daß diese "Umleitung" für den Benutzer nicht mit zusätzlichen Mühen verbunden ist (nicht mal bei abweichendem Port, wobei AVM hier ja auch dafür sorgen könnte, daß intern und extern verschiedene Portnummern genutzt werden können bzw. daß intern in jedem Falle 443 verwendet werden kann) ... es fällt halt die "einfache" Adresse "fritz.box" in der URL weg.
Wenn AVM nicht noch etwas geändert hat (ich habe das jetzt schon wieder ein paar (Labor-)Versionen nicht weiter verfolgt - genauer: zuletzt mit 06.98-56149 bei einer 7580 getestet, die nun gar nicht zu diesem Thread passen würde, aber irgendein Modell muß man sich aussuchen beim Schreiben und die 7490 ist wohl immer noch am weitesten verbreitet), dann geht man sogar hin und verhindert aktiv, daß der Kunde mit einem normalen Browser sich nur einmal mit der Sicherheitswarnung für ein "selbstsigniertes Zertifikat" befassen muß, wenn er selbst für die Verwendung von HTTPS auch beim Zugriff auf der LAN-Seite sorgt.
Wie macht man das? Man generiert einfach bei jedem Wechsel der öffentlichen IP-Adresse (das gilt natürlich auch dann, wenn die Box als LAN1-Router arbeitet - als LAN-Client habe ich es nicht geprüft) ein neues, selbstsigniertes Zertifikat mit der öffentlichen IP-Adresse als "Common Name". Da die Box dieses Zertifikat auch beim internen Zugriff über HTTPS vorlegt (solange nicht ein LE-Zertifikat vorhanden ist und der Zugriff über diesen DNS-Namen erfolgt), wird auch jedesmal erneut die "Zertifikatwarnung" des Browsers getriggert - da kann man (ohne ein selbsterstelltes Zertifikat für "fritz.box", denn glücklicherweise wird da dann lieber der "Namenskonflikt" hingenommen von AVM - warum das wohl so ist, spekuliere ich gleich) machen, was man will.
Warum macht AVM überhaupt solchen Blödsinn? Nun ... man hat bei AVM sich vor ein paar Jahren (Sommer 2014) entschlossen, eine Lücke, die durch den Einsatz und das ständige Neugenerieren eines "self-signed certificate" ohne ausreichende Prüfung vor einem MITM-Angriff entstand, auf dem Weg zu schließen, daß man in den AVM-eigenen FRITZ!Apps nicht mehr komplett auf die Zertifikatprüfung verzichtete, sondern den öffentlichen Schlüssel aus dem Zertifikat "angepinnt" hat.
Damit kann das FRITZ!OS soviele Zertifikate generieren, wie es möchte, solange sich der zugrundeliegende Schlüssel (privater und öffentlicher Teil gehören zusammen, damit muß bei identischem öffentlichen Schlüssel auch der private Teil derselbe sein - diese "Schlußfolgerung" ist zulässig) nicht ändert - die App akzeptiert dieses. Ein Angreifer als MITM kennt dann diesen Schlüssel wieder nicht und müßte einen neuen präsentieren ... diese Lücke ist damit also geschlossen, wenn die App beim Auftauchen eines neuen Schlüssels eine entsprechende Warnung ausgibt.
Leider verleitet diese "privilegierte" Stellung der FRITZ!Apps AVM jetzt aber dazu, davon ausgiebig Gebrauch zu machen und dabei die Verwender anderer Anwendungen, die per HTTPS auf das GUI zugreifen wollen (eben bis hin zum PC-basierten Browser), vollkommen aus den Augen zu verlieren ... anders kann ich mir diesen "Müll" (und auch wenn das nur meine persönliche Ansicht ist - als solchen würde ich das bezeichnen) nicht erklären.
Es gäbe nämlich auch Lösungen (die sind auch nicht neu und selbst hier schon mehrmals ventiliert worden), bei denen man sich seine Zertifikate auf der Box neu generieren könnte und trotzdem nur ein einziges Mal (pro FRITZ!Box, je nach Umsetzung vielleicht noch nach jeder "Werkseinstellung") ein Zertifikat im Browser oder in einer App anpinnen muß ... dazu muß man nur in der Box ein eigenes "CA-Zertifikat" generieren (das aktuell selbstsignierte Zertifikat ist auch nichts anderes, es darf nur nicht verwendet werden, um weitere Zertifikate zu unterschreiben - das ist der einzige (signifikante) Unterschied zwischen den beiden) und jedes weitere Zertifikat dann mit diesem - einmal erstellten - CA-Zertifikat signieren.
Es gibt sogar eine X.509v3-Option für solche CA-Zertifikate, mit der man dann sicherstellen kann, daß jedes weitere Zertifikat in der Kette nur unterhalb einer bestimmten Domain liegen darf: "permittedSubtrees" in https://tools.ietf.org/html/rfc5280#section-4.2.1.10 - setzt man diese, ist man (als Hersteller/Autor der Software, die das Zertifikat generiert) auch wieder so weit aus der Verantwortung für die mit diesem Zertifikat signierten Server-Zertifikate, daß damit unterschriebene Zertifikate für google.com oder irgendeine andere Domain außerhalb des eigenen Namensraums liegen würden und ein Browser (der seinerseits diese Vorgaben korrekt umsetzt) diese nicht akzeptieren sollte (selbst wenn ein Angreifer den privaten Key der FRITZ!Box-internen CA in die Hände bekommt).
Dann reicht es, in einem Browser (oder einer App) dieses CA-Zertifikat anzupinnen und jedes für einen konkreten TLS-gesicherten Zugriff (vom Server - aka FRITZ!OS) vorgelegte Zertifikat darauf zu prüfen, ob es von einer "trusted authority" stammt, wobei dann eben zu den "üblichen Verdächtigen" noch die eigene CA im FRITZ!OS zählen würde (die anderen muß man natürlich auch noch berücksichtigen, falls jemand "richtige" öffentliche Zertifikate - dazu gehört auch LE - verwenden will).
Ja, das ist etwas Arbeit und es erfordert auch etwas Koordination zwischen FRITZ!OS-Versionen und den passenden Apps (notfalls müssen die eben beide Verfahren beherrschen) ... aber die Ankündigungen der Browser-Hersteller sind auch nicht gänzlich neu - genauso wenig wie die Argumente, die zu diesen Entscheidungen geführt haben und die wohl kaum von der Hand zu weisen sind. Im Gegensatz zu "normalen Browsern" (auch auf Mobilgeräten) sind die Apps eben selbst dafür verantwortlich, wie sie die Integrität einer TLS-Verbindung absichern (wobei auch die verschiedenen Betriebssysteme meist schon Mechanismen zum "Anpinnen" von Zertifikaten oder Schlüsseln anbieten) ... aber das Universum an möglichen HTTP-Clients bei den Kunden besteht auch nicht nur aus den FRITZ!Apps von AVM.
PS: Wenn jemand konzeptionelle Fehler sieht bei der Verwendung einer CA auf der FRITZ!Box, diskutiere ich die gerne aus ...
Zuletzt bearbeitet:
