Ich habe mir eine Hand hinter den Rücken gebunden ... ich will mich nicht noch weiter verzetteln, auch wenn das LE-Zertifikat ja schon lange auf der "Wunschliste" steht und auch AVM die Reservierung für die Namen schon lange vorgenommen hatte.
Wobei mich schon interessieren würde, ob AVM da einen eigenen ACME-Client in C oder Lua geschrieben hat oder einen in Shell-Code (inzwischen gibt es mehrere) angepaßt hat an die FRITZ!Box oder ob man die C-Implementierung genommen hat, die es seit Mai 2016 gibt (wobei die m.W. LibreSSL als SSL-Stack will in der portablen Version).
Ich glaube jedenfalls nicht daran, daß man sich einen der Clients in einer "Hochsprache" gegriffen hat (das Original war in Python, wenn ich mich richtig erinnere) und dem die passende Runtime-Umgebung spendiert hat ... wobei das sicherlich auch mal etwas wäre, wenn es Python, Perl oder Ruby auf der Box gäbe. Auch der Client in JS sollte (beim bisher bekannten Funktionsumfang auf dem "Server" in der Box) kaum möglich sein ... oder AVM hat einen JS-Interpreter/-Compiler auf die Box gebracht. Ist schon nicht unspannend, aber ich habe mir erst einmal das Image gesichert und verkneife es mir sogar, das überhaupt auspacken zu lassen.
Aber auch sonst gibt es beim LE-Zertifikat noch viele spannende Fragen zu beantworten ... u.a. die, wo AVM am Ende die Informationen zum "Konto" (/acme/new-account) wohl speichert, denn es gibt zwar schon länger die zwei erwähnten Nodes im TFFS (für den privaten Schlüssel und das Zertifikat), aber es gab zumindest bisher keine zusätzliche Konfigurationsdatei und wenn die nicht auch noch neu "erfunden" wurde, dann muß das ja in irgendeiner anderen stehen, denn für das (hoffentlich automatische) Erneuern braucht es ja dann nicht nur CSR und Schlüssel, sondern auch den richtigen Account (wenn ich mich richtig erinnere).
================================================
Das mit der Erkennung von Schadsoftware ist auch nicht ganz so einfach ... wenn das nicht nur plakativ, sondern auch ausreichend wirksam sein soll. Was kann man denn vom Prinzip her nur machen?
Man kann z.B. irgendwo eine Liste bekannter C&C-Server-Adressen verwalten (wer macht das, wie aktuell ist die, wer trägt die Verantwortung für Aktualisierungen) und bei Kontaktaufnahme dahin halt seine Annahmen treffen und Warnungen erzeugen.
Das wird bei Schadsoftware, die einfach IRC in öffentlichen Channels (also gänzlich unverschleiert, aber in der Hoffnung, "im Rauschen" unterzugehen) oder gleich "hidden services" (also "vollverschleiert") für die Kommunikation nutzt, wieder nicht wirklich funktionieren ... und die Schadsoftware lernt ja auch dazu und direkte Verbindungen zu einem C&C-Server sind bei weitem nicht mehr so häufig wie früher - die Malware-Programmierer wollen ja auch nicht, daß jeder AV-Hersteller problemlos mit einem einzigen eingesammelten Sample sofort die Adressen ihrer C&C-Server identifizieren und in der Folge Verbindungen dorthin blockieren kann. Da wird verschleiert (auch über P2P), was das Zeug hält und wenn C&C-Verbindungen über Onion-Routing gehen, steht der Router eigentlich auch dumm da ... es sei denn, alle TOR-(Entry-)Nodes stehen auch gleich noch auf der Liste der "bösen Adressen" und das will ich mal nicht hoffen.
So richtig hilft das halt nur dann (angesichts dessen, was der Router da noch mitbekommen kann in einer Ende-zu-Ende-Verschlüsselung und die verwendet da fast jeder inzwischen), wenn eine Adresse im Netz tatsächlich als (reiner) C&C-Server bekannt ist ... und damit kommt man automatisch wieder zu der Frage zurück, wer diese Liste dann verwaltet und damit ggf. auch die Macht hat, darüber zu entscheiden, was die Box klaglos akzeptiert bei einer ausgehenden Verbindung oder wo sie Alarm schlägt.
Solange sie dann (aktuell soll das ja so sein) die Verbindung auch noch aufbaut, ist das vielleicht auch noch in Ordnung (wobei die meisten Kunden sicherlich auch erst einmal verunsichert sind), aber wenn das dann irgendwann auf automatisches Blockieren hinausläuft, dann hat man - als derjenige, der die Liste "wartet" - auch gleich wieder so etwas wie ein Zensur-Werkzeug an der Hand (wobei Zensur ja eigentlich den Zensor und die Genehmigungspflicht beinhaltet, hier ginge es dann mehr um das Unterdrücken unerwünschter Präsenzen).
Ich sehe also durchaus auch einen denkbaren Nutzen ... aber ich bin mir gar nicht so sicher, ob ich einen solchen Service (solange der nicht wahnsinnig transparent arbeitet) wirklich auf meinem Router haben wollte. Wenn der am Ende die Schadsoftware, die ihre Verbindungen zum C&C-Server besser tarnt, gar nicht erkennen kann und ich mir aber parallel eine unbekannte Quelle für irgendwelche "blacklists" einhandele (irgendwo dort dürfte die Lösung ja dann andocken, auch wenn zur Zeit nicht blockiert werden soll nach der Beschreibung bei AVM), dann sollte man das ggf. noch einmal hinterfragen ... auch die eigene Begeisterung.
Klar, wenn das als Blockieren von Schadsoftware deklariert wird, will das schon mal jeder haben ... wer wäre nicht gerne sicherer? Aber dann muß AVM m.E. auch die genauen Abläufe sehr klar offenlegen ... daß es wahrscheinlich früher oder später auch bei AVM mal in die Richtung gehen könnte, hatte ich schon im Gefühl (und habe das auch hier irgendwo mal geschrieben), als Symantec mit seiner "Norton Core Router"-Idee auflief.
Ich muß ganz ehrlich sagen, daß ich anstelle dieser "Warnung" über mögliche Aktivitäten von Schadsoftware viel lieber eine Möglichkeit hätte, einem Netzwerk-Client schon in der Netzwerk-Übersicht auf Knopfdruck das Recht für den Internet-Zugriff zu entziehen (ihn also direkt in das Profil "Gesperrt" zu verschieben - gibt es zwar inzwischen bei den Details, versteht aber der "normale Kunde" ohne ausreichende Erklärung gar nicht, wie ich selbst feststellen durfte bei mehreren "Einweisungen") und optimal wäre es, wenn man für so einen Client (damit der seine Updates noch kriegt oder ähnliches) einen "Lernmodus" einschalten könnte, in dem die Box die Ziele ausgehender Verbindungen protokolliert und sie einem nach dem Ende dieses Lernvorgangs noch einmal als Liste anbietet.
Da löscht man dann all die Ziele, die für Updates unwichtig sind, aus dieser Liste und im Anschluß darf so ein Gerät dann nur noch externe Verbindungen zu den verbliebenen Adressen (meinetwegen auch Namen, wobei das wieder DNS-Spoofing/-Hijacking möglich macht - andererseits gibt es auch für Updates CDNs und da ist dann eine einzelne Adresse auch Quatsch, wie mancher bei eigenen Sperrversuchen über die Blacklist schon merken durfte) aufbauen ... so eine Art "Whitelist", aber für einzelne Clients getrennt.
Kombiniert man das dann noch mit einer "Datenbank", in der die wichtigsten Hersteller mit ihren Geräten und Update-URLs vertreten sind und man kann dem Benutzer damit auch noch beim Löschen aus der Liste so weit assistieren, daß man ihm "Hinweise" für die bekanntermaßen unschädlichen Update-URLs anbietet (entweder man versucht den LAN-Client gleich selbst durch "fingerprinting" zu identifizieren oder man bietet eine Liste über Hersteller->Typ->Produkt-Zuordnungen an) oder - auf Wunsch - gleich die Liste passend zurechtstutzt, dann kann das auch der durchschnittliche Kunde wieder benutzen. Das wird sicherlich nicht für jedes exotische Gerät klappen, aber die wichtigsten NAS-Hersteller und -Modelle oder IP-Kameras (oder was auch immer) kriegt man relativ schnell zusammen und es ist ja auch keine Schande, wenn man mal sagen muß: "Kenne ich nicht, mußt Du selbst erkunden oder im Netz nach anderen Erfahrungen damit suchen." - das soll ja nur eine "Hilfe" sein und kein komplett automatischer Assistent, der einem das Denken auch noch abnimmt.
Damit beugt man (zumindest bei den wirklich "unsicheren Kandidaten") nicht nur der Kontaktaufnahme mit bekannten C&C-Servern vor, man kann als Benutzer auch steuern (ich weiß, daß das schon heute geht, aber kaum ohne wenigstens den Bachelor in Netzwerktechnik gemacht zu haben (in irgendeinem MINT-Studiengang) und dabei ist das FRITZ!OS schon deutlich mehr "user friendly" als andere Geräte), wie weit diese Geräte dann "nach Hause telefonieren", was gerade bei IoT-Gadgets auch in der Zukunft immer mehr zum Thema werden wird. Ein Dash-Button muß eben irgendwie Kontakt mit den AWS-Servern aufnehmen können, aber kaum mit irgendeinem obskuren Server irgendwo in Panama oder auf den Seychellen.
Meinetwegen kann man das dann tatsächlich noch mit einer Liste von "verdächtigen Adressen" kombinieren ... aber das wäre dann eben mehr die zweite Verteidigungslinie an dieser Stelle bzw. für die Geräte geeignet (PCs, Tablets, Smartphones), bei denen man die sinnvollen Zieladressen nicht wirklich wirksam einschränken kann.
