Was soll denn am Ende das Ziel eines solchen Zertifikats sein ?
Wenn es nur darum geht, die Warnmeldungen eines Browsers "auszuschalten" und ansonsten keinerlei Sicherheitsgewinn dadurch erzielt wird, dann ist das eben sogar kontraproduktiv, die Warnmeldungen sind ja kein Selbstzweck.
Auch AVM hatte - zumindest nach meiner Meinung - den Sinn von Zertifikaten eben gerade
nicht verstanden, wenn bei jeder Änderung der DNS-Konfiguration (DynDNS, MyFRITZ!, Boxname bzw. wenn davon nichts gesetzt ist, offenbar sogar bei jedem Wechsel der IP-Adresse) ein neues Zertifikat generiert wurde/wird. Beim FTP-Server war/ist es vor 06.20 sogar so, daß da nach jedem Start des Routers ein neues Zertifikat generiert wurde/wird, nur damit man den Prozess der Ableitung des Kennworts für den privaten Schlüssel nicht offenlegen mußte.
Das ist keine Spekulation meinerseits, das steht in den Kommentaren im betreffenden Quelltext explizit so drin:
Code:
// Generate or update server certificate for FTPS
[B]// We don't use the HTTPS server certificate, cause we can only use a weak private key encryption with open source[/B]
static int FixServerCertificate(void)
{
unlink("/var/tmp/ftps_cert_gen.complete");
if (-1 == system("msgsend ctlmgr ftps_cert_gen")) return -1;
time_t tout = current_secs() + 9;
do {
usleep(20 * 1000); // 20ms
if (0 == access("/var/tmp/ftps_cert_gen.complete", R_OK)) break;
} while(current_secs() < tout);
unlink("/var/tmp/ftps_cert_gen.complete");
return 0;
}
Wenn sich aber die Identität der Gegenstelle ständig ändert und der Benutzer sich bei dieser Identität dann nicht sicher sein kann, daß es sich tatsächlich um
seine FRITZ!Box handelt, dann gibt man im schlechtesten Fall seine Login-Daten (und damit alles daraus folgende) beim falschen Empfänger ab.
Der "Fingerabdruck" eines Zertifikats als einfachstes für den Menschen zu verifizierendes Merkmal ist ja auch nicht zufällig so gewählt, den findet man faktisch in jedem ordentlichen Browser für den Vergleich.
Die eigentliche Herausforderung ist es also nicht, die Browser-Meldungen bei einem geänderten Zertifikat zu unterdrücken, sondern einen Mechanismus in der FRITZ!Box zu etablieren, der die ständige Generierung neuer Zertifikate für die Box verhindert. Ein erster Schritt in diese (meiner Meinung nach unerläßliche und einzig richtige) Richtung ist die Möglichkeit, das eigene Zertifikat zu hinterlegen. Dieses eigene Zertifikat hat dann einen Fingerabdruck, wer diesen in irgendeiner Form mit sich führt (ob im Handy oder in der Brieftasche ist per se egal), der kann jederzeit auf einem "unbekannten Gerät" (wenn man so etwas überhaupt verwenden sollte für den Zugriff auf die eigene FRITZ!Box, denn die SSL-Verbindung sichert ja nur die
Verbindung zwischen der FRITZ!Box und dem benutzten Gerät ab und ob auf einem fremden Client nicht doch ein Keylogger lauert, sieht man diesem Gerät von außen eben nicht an) diesen Fingerabdruck verifizieren.
Wenn man von einem eigenen Gerät auf die FRITZ!Box zugreift, läßt sich meines Wissens bei jedem halbwegs modernen Gerät das Zertifikat der FRITZ!Box für die Verbindungen zu genau diesem einen Host speichern und dauerhaft autorisieren. Damit hat man auf eigenen Geräten genau ein einziges Mal die Warnung vor einem ungültigen Zertifikat und die sollte man dann eben auch ernst nehmen, den Thumbprint vergleichen und dann - da spricht weniger dagegen als dafür in meinen Augen - auch dauerhaft das Zertifikat akzeptieren.
Nur muß man dann eben auch sofort mißtrauisch werden, wenn da plötzlich ein anderes Zertifikat von der "FRITZ!Box" präsentiert wird ...
Ansonsten hat man am Ende nur eine Warnmeldung des Browsers (das Zertifikat paßt nicht zur aufgerufenen Domain) mit einer anderen (Domainname stimmt, aber dem Aussteller wird nicht vertraut) ersetzt ... wenn da trotzdem immer noch eine Warnmeldung des Browsers ausgegeben wird und der Nutzer diese nur anhand der "Details" unterscheiden kann, ändert sich an der Konditionierung des Nutzers (immer wenn ich auf die FRITZ!Box zugreife, muß ich einen Zertifikatfehler abnicken) absolut nichts und die wenigsten sind überhaupt in der Lage, den Unterschied zwischen diesen beiden Problemen zu verstehen.
Insofern ist auch die derzeitige Implementierung von AVM - wenn man eben kein eigenes Zertifikat in die Box lädt - weder Fisch noch Fleisch. Wenn ich bei der Änderung der DNS-Namen immer noch ein neues Zertifikat generiere, tausche ich eben nur eine Fehlermeldung im Browser gegen eine andere aus ... am Bild für den Nutzer ändert sich praktisch nichts. Da muß man also noch einmal kräftig nacharbeiten und sich eine ordentliche Lösung einfallen lassen. Bei der MyFRITZ!-App ging es am Ende ja auch, die prüft nach meinen Informationen eben nicht den Namen, der da im Zertifikat steht, sondern den "public key" der Gegenstelle direkt und der ändert sich selbst nicht, wenn sich das Zertifikat ändert.
Das läuft am Ende auf ein "Pairing" zwischen FRITZ!Box und App hinaus und ist ein möglicher Weg, wie man das Problem angehen kann. Wenn dann von AVM noch in der Box eine "self-signed" CA implementiert wird, dann geht das sogar mit einem beliebigen PC-System (wenn da eine zentrale Verwaltung der "trusted CAs" erfolgt) oder einem beliebigen Browser (wenn der, wie z.B. Firefox für Windows, da sein eigenes Süppchen kocht).
Ein Zertifikat ist - wenn man es genau durchdenkt - eben nichts anderes als eine Bestätigung, daß der vorliegende öffentliche Schlüssel zu der Adresse x.y.z gehört. Wenn man den Schlüssel aber schon kennt und es einem eigentlich egal ist, unter welcher Adresse der betreffende Server (die FRITZ!Box) zu finden ist, solange man nur den richtigen öffentlichen Schlüssel präsentiert bekommt (denn
dieser Schlüssel ist das eigentlich wichtige Merkmal der Gegenstelle), dann macht das Generieren eines neuen Zertifikats nur dann Sinn, wenn man damit den anderen Part der Zertifizierung (die Zugehörigkeit zur Adresse) "erschlagen" kann. Das klappt aber nur dann, wenn man das Vertrauen des Browsers eine Stufe weiter oben verankert.
Wenn man dann nämlich diese "private CA" der FRITZ!Box als "Authority" in seinem Browser (oder dem System) verankert, kann AVM ruhig auf der Box weiterhin ständig neue Zertifikate generieren ... solange diese dann mit dem CA-Zertifikat signiert werden, wird der Browser diese auch ohne weitere Warnmeldungen akzeptieren. Das wäre dann eben ein Pairing zwischen der FRITZ!Box und den betreffenden Gerät nicht anhand des "public key" der Zertifikats, sondern anhand des Zertifikats der CA. Damit könnte man wirklich die Warnmeldungen "ausmerzen" (jedenfalls die zu "no chain of trust" und "domain name mismatch") und verlöre auch nur in dem Maße an Sicherheit, wie es jetzt auch schon der Fall ist. Die bleibende Gefahr ist dann eben nach wie vor der nicht-autorisierte Zugriff auf die FRITZ!Box und das Entwenden des CA-Schlüssels ... das ist aber von der Qualität in etwa vergleichbar mit dem Entwenden des privaten Schlüssels der FRITZ!Box.
Das einzige, was den Browsern meines Erachtens heute immer noch fehlt, ist das "Pinning" einer CA nur für eine bestimmte Domain (so wie es bei einem Zertifikat auch läuft), da liegt eine minimal höhere Gefahr, daß mit dem (als vertrauenswürdig eingestuften) CA-Key der FRITZ!Box dann auch Zertifikate für andere Adressen "gespooft" werden könnten.
Das Mittel der Wahl für Komfort
und Sicherheit ist also ein eigenes Zertifikat in der Box
nachdem die DNS-Einstellungen (s.o.) festgeklopft wurden. Dann kann man u.U. sogar auf das selbstgenerierte Zertifikat der Box zurückgreifen, obwohl auch hier natürlich der Export des Zertifikats
und des privaten Schlüssels ganz dringend im GUI der Box erforderlich wäre. Wenn die Box weiterhin nach jedem Werksreset ein neues Schlüsselpaar generiert (die beliebteste Methode der Fehlerbehebung bei allen Providern und auch bei AVM ist nun mal ein Werksreset und die Sicherung umfaßt Zertifikat und privaten Schlüssel eben nicht), verringert sich zwar u.U. die Frequenz von Warnmeldungen, aber den ganzen Aufwand, den der Nutzer selbst treiben muß, wenn er das Box-Zertifikat in seinen Geräten als vertrauenswürdig eintragen will, hat man nach jedem Schlüsselwechsel erneut.
Diese fehlenden Export-Möglichkeiten sind um so unverständlicher, wenn man sich mal vor Augen hält, vor wem AVM da die Daten überhaupt "versteckt". Ein Angreifer, der anstelle des Nutzers in die FRITZ!Box gelangt, hat trotzdem alle Möglichkeiten, auch den privaten Schlüssel der FRITZ!Box zu extrahieren. Es bringt also gar nichts, diese Daten vor dem berechtigten Nutzer zu verstecken (ein Export mit ordentlicher Verschlüsselung ist mindestens genauso sicher, wie die "Lagerung" im Flash der FRITZ!Box) ... das einzige, was wirklich hilft, ist das Verhindern fremder Zugriffe. Und gerade diesem Anliegen leistet man eben einen Bärendienst, wenn man den Nutzer zum "Abnicken" von Fehlermeldungen "erzieht" und der dann am Ende einem Phishing-Versuch oder einem MITM-Angriff aufsitzt.
Auch die Verwendung von Zertifikaten von kostenlosen Anbietern wie StartSSL ist nur dann wirklich sinnvoll, wenn man sich nicht gleich das gesamte Zertifikat inkl. privatem Schlüssel dort erstellen läßt.
Die Idee der "zentralen Lagerung" von privaten Schlüsseln (solange die nicht bereits vom Nutzer vor dem Upload mit einem eigenen Kennwort sicher verschlüsselt wurden), wie sie im RFC auch "angedacht" ist, hätte auch ohne weiteres von der NSA oder einem anderen Dienst stammen können. Klar, um diese Daten für einen Angriff nutzen zu können, muß man an eine ziemlich zentrale Schaltstelle kommen, aber das ist am Ende auch nur ein "key escrowing" bei einem anderen Anbieter als einem Geheimdienst selbst ... wie schnell die Herausgabe solcher privater Schlüssel dann unter gewissen Rechtssprechungen erfolgen kann (wenn man sich überhaupt die Mühe eines "rechtmäßigen Anstrichs" machen sollte), weiß jeder, der nicht nur die Nachrichten in der BILD liest. Die Generierung des privaten Schlüssels kann zwar auch im lokalen Browser erfolgen (nach "Anstoß" durch eine Webseite), aber auch da ist eben zu diesem Zeitpunkt der "Lauscher an der Wand" nicht auszuschließen und die Lücken in den Browsern sind ja auch nicht alle bekannt ... warum also ein unnötig höheres Risiko eingehen ? Wenn man das ganz ordentlich außerhalb des Browsers in einer Kommandozeile selbst macht und währenddessen eben keine weiteren Programme laufen, beschränkt man das Risiko entsprechend.
Und auch für diesen Zweck (Zertifizierung des eigenen Keys) wäre der Export des privaten Schlüssels (und im Idealfall sogar eines entsprechenden CSR) aus der FRITZ!Box für viele Nutzer eine erhebliche Erleichterung, da gerade dort eben eine relativ hohe Sicherheit bei der Generierung des Schlüsselpaars gewährleistet werden könnte und man dem Nutzer die Installation eigener Software zur Generierung des Schlüsselmaterials abnehmen könnte.
Also, nach all meiner Laberei noch einmal die Frage: Was bringt das Verwenden eines Wildcard-Zertifikats (selbst wenn man mal die zusätzliche Gefährdung durch einen "shared private key" ausblendet aus den Überlegungen) an Vorteilen, was man nicht auch mit einem eigenen Zertifikat (self-signed, dann ist es kostenlos) lösen könnte (mit wesentlich geringerem Aufwand, als sich viele vorstellen) ?
