FRITZ!Box 7390 Release 6.87+6.87i vom 07.12.2021

[Grisu_]

Bei -90dB ist doch völlig egal wenn das auch ein anderer nutzt.

 

[Karl.]

Man sollte aber trotzdem nicht Kanal 8 nutzen, um 6 und 11 am besten zu stören.

 

[Grisu_]

Meinte ja auch 6 und 11 wo er ein fremdes WLAN riecht, von sehen kann ja fast keine Rede mehr sein.

In seiner Situation würd ich sowieso 1+5 oder 9+13 nehmen, scheint ja recht befreit von Nachbarn zu sein (wie bei mir).

 

[Karl.]

Hast dann aber Störungen, wenn der richtige Nachbar automatisch den Kanal wechselt.

 

[KunterBunter]

Eigentlich ging es gar nicht ums WLAN, sondern nur um das DSL50 ohne Vectoring. Und da ist diese alte Box an dieser Leitung noch sehr gut dabei, wenn auch die Bilder mit den DSL-Daten etwas klein geraten sind.

 

[Karl.]

Ich würde sogar noch weiter gehen sagen, #2 bis #27 sind mehr offtopic als nützlich.

 

[Grisu_]

Stimmt, sonst wird hier aber vermutl. auch kaum mehr jemand etwas zur Release schreiben, da sie quasi keine Veränderung zur vorherigen beinhaltet die bemerkenswert (i.S. nennenswert/auffällig) wäre.
FragAttack "sieht" man nicht im Normalbetrieb und die Anpassung der Zertifikate wird man auch nicht negativ erleben.

 

[B612]

Ich habe mal noch die internationale Version in #1 ergänzt.

 

[erik]

Ein Google-Telefonbuch läßt sich zwar einrichten, die Synchronisation funktioniert aber nicht. Bei der 7362SL wurden die Online-Telefonbücher in dieser Sicherheitsupdate-Runde ganz entfernt.

Edit: Falsche Aussage gelöscht, die erweiterte Ansicht hat gefehlt.

 

[acx_com]

[Edit Novize: Überflüssiges Fullquote des Beitrags direkt darüber gelöscht - siehe Forumsregeln]
Kann ich bestätigen.
Zuvor hat das Online-Telefonbuch mit Google gut funktioniert.
Kaum wurde das Update 6.87 aufgespielt, kann es nicht mehr geladen werden.
Lediglich "meist" klappt es, die Labels zu laden und einzustellen.
In den letzten Schritten bzw. beim Laden des Telefonbuches erdolgt die Fehlermeldung "Die Aktualisieren ist gescheitert. Bitte überprüfen Sie die Benutzerdaten.(14)".
Da fragt man sich, was wichtiger ist, ein scheinbares Sicherheitsupdate, oder eine immer weniger funktionierende Fritzt!Box!
Ist es vielleicht Absicht, dass sich noch mehr zwingen lassen, eine neue zu kaufen, obwohl die alte locker noch supported sein könnte?

 

[Karl.]

Kaum wurde das Update 6.87 aufgespielt, kann es nicht mehr geladen werden.

Ein Reboot hätte gereicht, um das Problem auszulösen...

Man braucht min OS 7.27 (oder 7.28) für das Google Telefonbuch.

 

[NDiIPP]

Kaum wurde das Update 6.87 aufgespielt, kann es nicht mehr geladen werden.

Was wohl eher nur daran lag, dass die Box zuvor schon eine Weile lief und die Daten einfach noch im RAM hatte (aus einer Zeit bevor die Änderung bei Google stattfand). Denn auch mit den vorherigen Firmware-Versionen der 7390 kann das Google-Telefonbuch nicht mehr synchronisiert werden. Diese Änderung erfolgte seitens Google und nicht seitens AVM und da es für die 7390 nur noch Sicherheitsupdates aber keine Feature-Updates mehr gibt, wird sich daran wohl kaum noch was ändern.

Edit:
Ich war erst kürzlich bei jemanden dem war das auch lange Zeit gar nicht aufgefallen. Der wunderte sich nur, dass seine 7430 (noch mit FRITZ!OS 7.1x) die Änderungen aus dem Google-TB nicht mehr übernahm. Er dachte ein Neustart löst das Problem damit wieder synchronisiert wird. Ergebnis: Nun blieb das Telefonbuch gleich ganz leer... Glücklicherweise gibt es für die 7430 jedoch ein Update (bzw. von seinem Stand aus gesehen schon etliche), was er bisher (u.a. aus Unkenntnis) noch nicht durchgeführt hatte:

# Weitere Verbesserungen im FRITZ!OS 7.27

[...]

## Telefonie:
- **Änderung** Notwendige Änderung für die künftige Nutzung eines Online-Telefonbuchs von Google
[...]

 

[erik]

Featureupdates hätte ich auch nicht erwartet, aber der Erhalt einstmals vorhandener Funktionen hätte nach meinem Verständnis bei einer Wartung dazugehört.

 

[PeterPawn]

der Erhalt einstmals vorhandener Funktionen

... ist ja eher nicht "sicherheitsrelevant" und die ganzen 07.29-Updates auch für uralte Modelle (wo die 7390 schon immer ein "unicorn" war, weil das einzige (verbreitete) Modell mit Vx180), dürften deutlich mehr als FragAttack (das ist bei den meisten Modellen ja schon länger gefixt und bisher hielt es AVM ja nicht für nötig, DESHALB ein Update für so viele ältere Modelle bereitzustellen) und irgendwelche CA-Zertifikate reparieren.

---

DoT hat die 7390 gar nicht (oder das wäre komplett an mir vorbeigegangen) und es gibt nicht soo viele Funktionen in der Firmware, wo es tatsächlich eine Rolle spielt, daß das FRITZ!OS selbst auch die aktuellsten CA-Zertifikate hat und damit irgendwelche "vorgelegten" Zertifikate fremder Server verifizieren kann.

Sehr vieles ist bei AVM auch ohne TLS abgesichert ... z.B. die Update-Suche und der Download von Updates, ersteres (JUIS) ist über signierte SOAP-Antworten abgesichert (der Key zur Prüfung ist fest einkompiliert in der Firmware) und der Firmware-Download erfolgt ohnehin üblicherweise unverschlüsselt, weil auch die Update-Images signiert sind und DAS wird dann geprüft (deshalb kriegt man ja auch keine unsignierte/falsch signierte Firmware mehr über Datei-Upload installiert).

Bei anderen Diensten (z.B. der verschlüsselten Übertragung von E-Mails) wird das Zertifikat der Gegenstelle auch nicht wirklich geprüft (so ein SMTP-Server kann problemlos auch ein selbstsigniertes Zertifikat verwenden, ohne daß sich das FRITZ!OS weigert, die E-Mails dort einzuliefern) und sogar beim TR-069 ist vorgesehen, die Zertifikatprüfung einfach abzuschalten, wenn ein Provider keine "richtigen" Zertifikate verwendet. Dasselbe gilt auch für WebDAV-Zugriffe - auch da stört sich das FRITZ!OS nicht an einem "self-signed"-Zertifikat (während jeder lausige Browser heutzutage dabei fast durchdreht).

---

Mir fehlt jedenfalls etwas die Phantasie, welcher Dienst auf einer FRITZ!Box jetzt unbedingt die neuesten CA-Zertifikate bräuchte (Verschlüsselung bei SIP/RTP ist bei der 7390 auch kein Thema) - das ist auch etwas anderes als die Geschichte bei den 7270-Modellen und deren Beschränkung auf RC4-basierte Algorithmen, die dann noch eine 06.06 brauchten, damit man überhaupt noch auf die Boxen kam, weil praktisch alle Browser ArcFour rausgeworfen hatten. TLS 1.0 und 1.1 sind zwar auch mittlerweile "deprecated" und raus in aktuellen Browser-Versionen, aber OpenSSL 1.0.2u in der 06.87 kann ebenso nur TLS 1.2 (TLS 1.3 braucht mind. OpenSSL 1.1.1), wie die 1.0.1t in der 06.86.

Schaut man dann mal genauer nach, was das "Aktualisierung von vertrauenswürdigen Stammzertifizierungsstellen" tatsächlich bedeutet, ist auch das alles nicht wirklich "dringend". Die root_ca.pem zwischen der 06.86 und 06.87 (bei der 7390 kann man das schön sehen, weil die Versionen so alt sind) unterscheiden sich in 7 bzw. 8 CA-Zertifikaten (sieben wurden entfernt, acht hinzugefügt und 13 sind unverändert) - die zweite "Liste" mit CA-Zertifikaten mit dem Namen common_root_ca.pem ist ohnehin jeweils ein Abklatsch der root_ca.pem.

Hinzugefügt wurden:

        Serial Number: 1 (0x1)
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = DE, O = T-Systems Enterprise Services GmbH, OU = T-Systems Trust Center, CN = T-TeleSec GlobalRoot Class 3
        Validity
            Not Before: Oct  1 10:29:56 2008 GMT
            Not After : Oct  1 23:59:59 2033 GMT
        Subject: C = DE, O = T-Systems Enterprise Services GmbH, OU = T-Systems Trust Center, CN = T-TeleSec GlobalRoot Class 3
--
        Serial Number:
            82:10:cf:b0:d2:40:e3:59:44:63:e0:bb:63:82:8b:00
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = US, O = Internet Security Research Group, CN = ISRG Root X1
        Validity
            Not Before: Jun  4 11:04:38 2015 GMT
            Not After : Jun  4 11:04:38 2035 GMT
        Subject: C = US, O = Internet Security Research Group, CN = ISRG Root X1
--
        Serial Number:
            44:af:b0:80:d6:a3:27:ba:89:30:39:86:2e:f8:40:6b
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: O = Digital Signature Trust Co., CN = DST Root CA X3
        Validity
            Not Before: Sep 30 21:12:19 2000 GMT
            Not After : Sep 30 14:01:15 2021 GMT
        Subject: O = Digital Signature Trust Co., CN = DST Root CA X3
--
        Serial Number: 1 (0x1)
        Signature Algorithm: md5WithRSAEncryption
        Issuer: C = ZA, ST = Western Cape, L = Cape Town, O = Thawte Consulting cc, OU = Certification Services Division, CN = Thawte Premium Server CA, emailAddress = [email protected]
        Validity
            Not Before: Aug  1 00:00:00 1996 GMT
            Not After : Dec 31 23:59:59 2020 GMT
        Subject: C = ZA, ST = Western Cape, L = Cape Town, O = Thawte Consulting cc, OU = Certification Services Division, CN = Thawte Premium Server CA, emailAddress = [email protected]
--
        Serial Number: 1 (0x1)
        Signature Algorithm: md5WithRSAEncryption
        Issuer: C = ZA, ST = Western Cape, L = Cape Town, O = Thawte Consulting cc, OU = Certification Services Division, CN = Thawte Premium Server CA, emailAddress = [email protected]
        Validity
            Not Before: Aug  1 00:00:00 1996 GMT
            Not After : Dec 31 23:59:59 2020 GMT
        Subject: C = ZA, ST = Western Cape, L = Cape Town, O = Thawte Consulting cc, OU = Certification Services Division, CN = Thawte Premium Server CA, emailAddress = [email protected]
--
        Serial Number:
            5c:8b:99:c5:5a:94:c5:d2:71:56:de:cd:89:80:cc:26
        Signature Algorithm: ecdsa-with-SHA384
        Issuer: C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust ECC Certification Authority
        Validity
            Not Before: Feb  1 00:00:00 2010 GMT
            Not After : Jan 18 23:59:59 2038 GMT
        Subject: C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust ECC Certification Authority
--
        Serial Number:
            1f:47:af:aa:62:00:70:50:54:4c:01:9e:9b:63:99:2a
        Signature Algorithm: ecdsa-with-SHA384
        Issuer: C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = COMODO ECC Certification Authority
        Validity
            Not Before: Mar  6 00:00:00 2008 GMT
            Not After : Jan 18 23:59:59 2038 GMT
        Subject: C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = COMODO ECC Certification Authority
--
        Serial Number:
            05:55:56:bc:f2:5e:a4:35:35:c3:a4:0f:d5:ab:45:72
        Signature Algorithm: ecdsa-with-SHA384
        Issuer: C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root G3
        Validity
            Not Before: Aug  1 12:00:00 2013 GMT
            Not After : Jan 15 12:00:00 2038 GMT
        Subject: C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root G3
--
        Serial Number:
            02:ac:5c:26:6a:0b:40:9b:8f:0b:79:f2:ae:46:25:77
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert High Assurance EV Root CA
        Validity
            Not Before: Nov 10 00:00:00 2006 GMT
            Not After : Nov 10 00:00:00 2031 GMT
        Subject: C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert High Assurance EV Root CA

und diese wurden entfernt:

        Serial Number: 144470 (0x23456)
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
        Validity
            Not Before: May 21 04:00:00 2002 GMT
            Not After : May 21 04:00:00 2022 GMT
        Subject: C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
        Subject Public Key Info:
--
        Serial Number:
            15:ac:6e:94:19:b2:79:4b:41:f6:27:a9:c3:18:0f:1f
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = US, O = GeoTrust Inc., OU = (c) 2008 GeoTrust Inc. - For authorized use only, CN = GeoTrust Primary Certification Authority - G3
        Validity
            Not Before: Apr  2 00:00:00 2008 GMT
            Not After : Dec  1 23:59:59 2037 GMT
        Subject: C = US, O = GeoTrust Inc., OU = (c) 2008 GeoTrust Inc. - For authorized use only, CN = GeoTrust Primary Certification Authority - G3
--
        Serial Number:
            d0:9f:ab:2b:7d:ca:ef:d4
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = DE, ST = Hessen, L = Darmstadt, O = Deutsche Telekom AG, OU = Products and Innovation, CN = Telekom RMD-CPE KLUK Authority RootCA 1
        Validity
            Not Before: Jan  5 11:34:41 2016 GMT
            Not After : Dec 28 11:34:41 2045 GMT
        Subject: C = DE, ST = Hessen, L = Darmstadt, O = Deutsche Telekom AG, OU = Products and Innovation, CN = Telekom RMD-CPE KLUK Authority RootCA 1
--
        Serial Number:
            60:01:97:b7:46:a7:ea:b4:b4:9a:d6:4b:2f:f7:90:fb
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = US, O = "thawte, Inc.", OU = Certification Services Division, OU = "(c) 2008 thawte, Inc. - For authorized use only", CN = thawte Primary Root CA - G3
        Validity
            Not Before: Apr  2 00:00:00 2008 GMT
            Not After : Dec  1 23:59:59 2037 GMT
        Subject: C = US, O = "thawte, Inc.", OU = Certification Services Division, OU = "(c) 2008 thawte, Inc. - For authorized use only", CN = thawte Primary Root CA - G3
--
        Serial Number: 1 (0x1)
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: C = SE, O = AddTrust AB, OU = AddTrust External TTP Network, CN = AddTrust External CA Root
        Validity
            Not Before: May 30 10:48:38 2000 GMT
            Not After : May 30 10:48:38 2020 GMT
        Subject: C = SE, O = AddTrust AB, OU = AddTrust External TTP Network, CN = AddTrust External CA Root
        Subject Public Key Info:
--
        Serial Number:
            34:4e:d5:57:20:d5:ed:ec:49:f4:2f:ce:37:db:2b:6d
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: C = US, O = "thawte, Inc.", OU = Certification Services Division, OU = "(c) 2006 thawte, Inc. - For authorized use only", CN = thawte Primary Root CA
        Validity
            Not Before: Nov 17 00:00:00 2006 GMT
            Not After : Jul 16 23:59:59 2036 GMT
        Subject: C = US, O = "thawte, Inc.", OU = Certification Services Division, OU = "(c) 2006 thawte, Inc. - For authorized use only", CN = thawte Primary Root CA
--
        Serial Number:
            70:ba:e4:1d:10:d9:29:34:b6:38:ca:7b:03:cc:ba:bf
        Signature Algorithm: md2WithRSAEncryption
        Issuer: C = US, O = "VeriSign, Inc.", OU = Class 3 Public Primary Certification Authority
        Validity
            Not Before: Jan 29 00:00:00 1996 GMT
            Not After : Aug  1 23:59:59 2028 GMT
        Subject: C = US, O = "VeriSign, Inc.", OU = Class 3 Public Primary Certification Authority

Warum sollte es jetzt für das FRITZ!OS (was eben fast immer auch selbstsignierte Zertifikate dort akzeptiert, wo sich ein anderer Server dem OS gegenüber "ausweisen" soll) irgendeine Rolle spielen, daß die sieben entfernten CA-Zertifikate nicht länger gültig sind oder wo würde das FRITZ!OS auf einen (fremden) Dienst zugreifen wollen, der in der "trust chain" seines Zertifikats eine der acht hinzugefügten CAs hat und ansonsten nicht als "sicher" verifiziert werden könnte?

Bliebe noch die Möglichkeit, daß die AVM-Zertifikate für irgendwelche Dienste (z.B. avm.de oder MyFRITZ!) bei einer von den neuen CAs enden ... für avm.de wird ein Wildcard-Zertifikat verwendet (das also JEDER Server unterhalb von avm.de benutzen kann - der SMTP-Server von AVM hat z.B. auch dieses Wildcard-Zertifikat) und das endet bei der DigiCert Global Root CA, die sowohl in der 06.87 als auch in der 06.86 enthalten ist.

Das MyFRITZ!-Zertifikat (www.myfritz.net) ist dann tatsächlich ein EV-Zertifikat (für mehrere DNS-Namen) von der DigiCert EV-CA, die in der 06.86 nicht als CA enthalten war. Aber schaut man sich das Zertifikat genauer an, wurde das am 02.01.2020 gültig und ist ab dem 20.01.2022 (also in ca. 40 Tagen) nicht mehr zu gebrauchen - sicherlich wird AVM das dann rechtzeitig verlängern und ersetzen. Aber auch hier stellt sich ja schon die Frage, warum es bisher in fast 23 Monaten die 7390 nicht gekratzt hat, wenn das Zertifikat der myfritz.net-Seite nicht bis zu einer Root-CA im FRITZ!OS verfolgt werden konnte (m.W. gingen die MyFRITZ!-Services dennoch mit einer 7390), aber plötzlich soll das irgendeine Rolle spielen? Klingt doch eher unwahrscheinlich, oder?

---

Diese beiden Punkte, die da in den News stehen, dürften also kaum dazu angetan sein, ein solches Update notwendig erscheinen zu lassen - FragAttack WAR vor etwas mehr als einem halben Jahr zwar tatsächlich ein Thema, aber dafür hat AVM auch zeitnah dann Updates herausgegeben (https://avm.de/service/aktuelle-sicherheitshinweise/), nachdem die erste Einschätzung "Das ist nicht wirklich gefährlich." abgegeben wurde - DAS kann also auch nicht der Grund sein, warum jetzt Modelle, die schon vor 6 Monaten gegen FragAttack nachgehärtet wurden, nun plötzlich eine Version 07.29 verpaßt bekommen.

Man muß zwar auch nicht gleich Verschwörungstheorien darauf stützen, daß AVM für extrem viele Modelle dieses Update bereitgestellt hat - aber allzuviel Vertrauen in den Hersteller, daß das tatsächlich nur die Änderungen sind, die da mit den zwei Punkten im "Changelog" angegeben wurden, halte ich auch für übertrieben und eher blauäugig (auch wenn jetzt wieder die Zeit gekommen ist, wo an den Weihnachtsmann geglaubt wird). Irgendwo habe ich auch etwas in dieser Richtung (a la "steht doch in der info.txt") gelesen - war halt nicht bei diesem Modell hier, aber das eignet sich eben ganz vorzüglich für solche "Untersuchungen" und zum Aufzeigen von Merkwürdigkeiten in der "Argumentation".

 

[kleinkariert]

der Erhalt einstmals vorhandener Funktionen

Nochmal: Die Funktion wurde einseitig durch Google geändert.
Für den Erhalt wäre also eine nicht unerhebliche Code-Änderung erfoderlich, die AVM beim ex-ex-ex-Flaggschiff von 2009(!) nicht mehr leisten will/kann.

 

[NDiIPP]

Featureupdates hätte ich auch nicht erwartet, aber der Erhalt einstmals vorhandener Funktionen ...

Ja, schön wäre es. Aber dieses Modell ist nun mal schon lange EOS und da sind selbst schon Sicherheitsupdates nicht zwingend selbstverständlich. Aber das ginge dann schon über ein Sicherheitsupdate hinaus, das wäre schon eher eine "Feature-Instandhaltung" aufgrund geänderter äußerer Umstände und damit kann man bei EOS nun wirklich nicht mehr rechnen...

 

[Christiancool]

Hallo, habe mit meiner FB7390 Kombi das Problem, dass ich den Provider "additive" nicht entfernen kann, habe es jetzt 3 x über FTP versucht, qoute UNSETENV provider, Kommando wird mit succsesful bestätigt, aber nach dem Reboot sind die Stadtwerke Schwedt immer noch vorhanden. Hat da jemand einen TIP?

 

[PeterPawn]

Das braucht parallel das Zurücksetzen auf die Werkseinstellungen, ansonsten wird es beim nächsten Start auch wieder im Urlader-Environment eingetragen.

 

[Christiancool]

Danke, für den Hinweis, hat jetzt funktioniert. Habe ein Recovery mit der 6.86 gemacht, Nur zurücksetzen auf Werkseinstellung hat nicht funktioniert.

 

[PeterPawn]

Das geht auch ohne Recovery-Programm ... zuerst die Einstellungen im OS zurücksetzen und dann - direkt BEIM nächsten Start und vor dem Laden des FRITZ!OS - den Eintrag im Urlader-Environment über den FTP-Server in EVA löschen.