FritzBox privater Schlüssel (.pem) - Frage dazu

RAMler

Mitglied
Mitglied seit
22 Mrz 2010
Beiträge
787
Punkte für Reaktionen
0
Punkte
18
Schönen guten Abend,

ich las in einem anderen Thread das AVM auf allen Fritzboxen den gleichen, privaten Schlüssel verwendet. Der Gedanke daran will mir irgendwie nicht wirklich zusagen.
Der Schlüssel ist auf der Box zwar AES-128 verschlüsselt, aber die Passphrase muss die Box ja beim booten eingeben, also muss diese ja auch irgendwo hinterlegt sein. Habe ich da einen Denkfehler? Hat jemand mal danach gesucht und kennt evt. den privaten Schlüssel im Klartext?

Kann man die privaten Schlüssel durch selbst erstellte (ohne Passphrase) ersetzen oder gibt das Salat?

Über jegliche Antwort wäre ich dankbar. :)

Viele Grüße

RAMler
 
Um welche Schlüssel geht es dir denn? Meints du den HTTPS-Server der Box für WebIF? Handelt es sich dabei nicht um selbstsignierte Zertifikate? Das ist doch der Grund dafür, warum FF immer meckert. Braucht man dafür wirklich Passphrase?
Ich bin da auch kein Experte in Sachen von Zertifikaten, jedoch hatte ich noch davor einen Trick gelernt, wie man Warnmeldungen von FF umgehen kann. Man muss zunächst eine eigene Zertifizierungsstelle erstellen. Mit dem Zertifikat dieser Stelle unterschreibst du dann alle Zertifikate (unter anderem wäre eine von deiner Fritz!Box). Die Adresse im Zertifikat sollte natürlich deiner externen Adresse gleich sein und der Unterschreiber darf nicht den gleichen Namen besitzen. Danach musst du lediglich Zertifikat der Zertifizierungsstelle auf deinem Client-Rechner (z.B. in FF) als vertrauenswürdig eintragen und alle von dem unterzeichneten Zertifikate werden dann automatisch als vertrauenswürdig angesehen, als ob die von der teursten Zertifizierungsstelle stammen würden.
Diese Geschichte hatte ich erfolgreich mit meinen durch matrixtunnel selbst erschaffenen HTTPS-Servern auf der box mehrfach durchgeführt, noch vor den Zeiten, wo AVM ihren ersten https-Zugang ins Leben gerufen hatten. Als ich von AVM-Lösung erfuhr, hatte ich versucht deren Zertifikat mit meinem zu ersetzen. Leider ist es mir nicht gelungen. man kann zwar die Datei irgendwo unter tmp durch seine eigene ersetzen, jedoch hat ctlmgr diese Datei zu dem Zeitpunkt bereits "eingelesen" und man kann ihm somit keine eigenen Zertifikate vortäuschen. Anscheinend werden Zertifikate beim Hochfahren life generiert und sofort eingelesen, sodass die Datei im RAM danach eigentlich witzlos ist.
Ich hatte angemutet, dass du dich um diese AVM-HTTPs-Geschichte interessierst. Neben dieser Geschichte laufen auf der Box natürlich einige weiteren Sachen, die teilweise auch Zertifikate verwenden: tr069, tr064, onlinespeicher. Da fungiert die Box jedoch als Client.

MfG
 
Das Zertifikat wird aus einem privaten Schlüssel erzeugt. Die Box erzeugt das Zertifikat bei jedem Boot neu, daher auch der jeweils abweichende Fingerprint. Es gibt Schlüssel für FTPES, Fernzugriff, VPN ect. (Ob das nun der gleiche ist, ka, hab ich nicht nachgeschaut - als ich AES128 sah, war das erst mal nebensächlich.)

Der private Schlüssel wurde von AVM außerhalb der Box erzeugt und laut einem Statement hier im Forum ist dieser bei allen Boxen gleich.
Wer diese(n) privaten Schlüssel hat, im Klartext, kann also alle SSL/TLS Verbindungen der Fritzbox entschlüsseln. Oder um es kurz zu machen: Die verschlüsselten Verbindungen einer Fritzbox sind letztendlich nicht vertrauenswürdig, da offen ist wer diesen Schlüssel nun hat und kennt.

Den/die Schlüssel selbst habe ich auch gefunden, nur hat AVM diesen zusätzlich mit 128bit AES verschlüsselt. Ich weiß nicht ob du mal einen privaten Schlüssel z.B. in einen Apache Webserver geknallt hast, aber wenn der private Schlüssel zusätzlich verschlüsselt ist, muss man beim Systemboot dessen Passphrase ("Password") eingeben, damit das System ihn nutzen kann.

Die Fritzbox macht das also bei jedem Boot automatisch, ergo muss die Passphrase irgendwo stehen. ^^

Darum ging es im Großen und Ganzen. Wenn man den Schlüssel durch selbst erstellte ersetzen könnte, wäre mir das natürlich sehr lieb. Wenn ich sogar in der Fritzbox welche mit eigener Passphrase nutzen könnte und diese an passender Stelle hinterlegen könnte, noch lieber.

Das der FF meckert liegt daran, dass das von der FB erstellte Zertifikat von keiner vertrauenswürdigen CA unterzeichnet wurde. Ist auch kein Wunder - das kostet nämlich nen Haufen Geld.

Zu deinem damaligen Problem:
Die Zertifikate musst du nicht selbst zertifizieren. Du kannst auch einfach für das jeweilige Zeritikat eine Ausnahme erstellen. Eine eigene CA zum signieren wird erst dann sinnvoll, wenn man mehrere Zertifikate an verschiedenen Stellen nutzt und diese alle samt mit der gleichen CA signiert, welche man dann wiederum als vertrauenswürdige CA in den Browser aufnimmt. Da kann man als Beispiel gut eine Universität nehmen, die verschiedene https Seiten betreibt. Die Zertifikate werden einfach alle mit der gleichen CA signiert und den Studenten muss man nur noch erklären, dass sie die CA als vertrauenswürdig anerkennen sollen. Schon werden alle Seiten als vertrauenswürdig erkannt und der Student muss nicht z.B.20 Zertifikate von Hand eintragen und bei einem Zertifikatswechsel durch den Uniadmin wieder von vorne beginnen.
 
Zuletzt bearbeitet:
@Peter: Zum Punkt 3. Genau so wird es gemacht, davon bin ich fest überzeugt. Allerdings geschah diese Generierung zumindest früher und für https immer life beim Reboot oder sogar beim reconnect. Ob es mittlerweile nur einmalig passiert und ob es beim von dir beobachteten VPN-Zugang (oder was du da meintest) einmalig passiert, weiß ich nicht. Wäre aber logisch. Ganz am Anfang waren aber Zertifikate definitiv oft geändert, denn das Abspeichern im Browser hatte früher zumindest nie was gebracht. Außerdem waren Zertifikate immer zu dem Zeitpunkt generiert, wo sich die Box noch nicht mit dem Zeitserver synchronisiert hatte. Daher müsste AVM zu miesen Tricks zugreifen, um die Laufzeit der Zertifikate vernünftig zu halten, damit sie auch im Jahre 2010 galten, obwohl sie im Jahre 2000 (Nulldatum für die Boxen) ausgestellt waren.

Ich bin auch voll deiner Meinung bzgl. tr069 und tr064. Genau dort können durchaus solche Spielchen abspielen, die RAMler uns versucht auszumalen, aber nicht beim https oder vpn-Zugang.

@RAMler: Genau dafür nutze ich CA bei meinem STRATO-Server. Ich unterschreibe damit diverse Unterzertifikate auch für IMAP, SFTP, HTTPs, SMTPS und was da auch alles gibt. Nachher reicht es meistens CA einzulesen und dann hat sich alles erledigt. Selbst unterschriebene Zertifikate in FF abspeichern bringt wenig Sinn. Denn die Warnmeldung kriegst du damit nicht weg. Wenn du jedoch CA abspeicherst, dann schon.

MfG
 
@Peter:

Eins vorweg, die These des extrem unsicheren, privaten Schlüssels trifft wohl heute nicht mehr zu. Das sah vor 2 Jahren evt. noch anders aus.

1. Es wäre nicht total unlogisch und kontraproduktiv, es ist es leider. :( Das Phänomen ist bei FTPES vorhanden - bitte teste es selbst.
Ich habe bei jedem Start einen neuen Fingerprint im Zertifikat und dies nun extra erneut getestet.
Zudem wurde es nun mit der Fernwartung getestet (die ich normal nicht nutze) - dort tritt das Phänomen tatsächlich nicht auf. Bei FTPES schon - wie gesagt, teste es bitte selbst. ;)

EDIT:
Kann das mit dem Zertifikat hieran liegen?
./var/websrv_ssl_cert.pem
./var/flash/websrv_ssl_cert.pem
./var/flash/websrv_ssl_key.pem
Der Private Schlüssel ist ja klar, liegt im Flash und ändert sich nicht.
Das Zertifikat im Flash ist wohl das für die Fernwartung.
Ist das Zertifikat unter /var evt. für FTPES zuständig und wird (dort) bei jedem Reboot neu angelegt?


2. Ich kam zu dieser These, aufgrund flgender Aussage von AVM selbst:

Das Schlüsselpaar des Zertifikats ist in allen FRITZ!Box-en derzeit
identisch. Das Schlüsselpaar wurde mit einer betroffenen OpenSSL außerhalb
der FRITZ!Box generiert.

Wenn ich diese missverstanden haben sollte, lass es mich wissen.
Zu finden hier: http://ippf.eu/showpost.php?p=1123583&postcount=571


3. -nodes nutzt man doch normal nur bei "openssl req" um ein Zeritifikat mit dem Schlüssel der CA zu unterschreiben und das erzeugte Zertifikat nicht zu verschlüsseln. Oder eben um den privaten Schlüssel einer CA unverschlüsselt zu erzeugen.
Mit "openssl genrsa", also der Erstellung eines normalen, privaten Schlüssels, geht kein -nodes. Ob man dort nun des/des3 oder aes128-256 zum verschlüsseln des Schlüssels nutzt ist dem User überlassen. Man kann es auch einfach weglassen (keine Passphrase nötig). Oder man entfernt es danach mit einem "openssl rsa -in name.key -out neuername.key" und muss dort zur Bestätigung die vorab gesetzt Passphrase eingehen.

Das Box Zertifikat ist natürlich ein selbst erstelltes Zertifikat, das auf IP und/oder dyndns Host erstellt wird, aber -nodes spielt da keine Rolle.
Die privaten Schlüssel in der Box sind allerdings alle mit Passphrase geschützt und AES128 verschlüsselt.

Also wird die Box zur Erzeugung des Schlüssels ein "openssl genrsa -aes128 -out schlüssel.pem 1024" absetzen und dann die Passphrase festlegen. Oder der Schlüssel ist schon von Werk aus drauf und individuell pro Box/Serie/Modell/Charge ...? Mich würde daher mal der öffentliche Schlüssel einer anderen 7270v3 interessieren. ;)

Wenn die Box aus dem fremden private key ein Zertifikat generieren soll, dann benötigt sie auch das PW für den Schlüssel, sonst kann sie nicht signieren.
Nichts anderes habe ich behauptet. Die Schlüssel sind mit Passphrase geschützt und die Box muss die Passphrase daher kennen und zusätzlich irgend wo anders hinterlegt haben.

Aber nun ja, der einzige, private und mit Passphrase versehene Key der schon in der Firmware vorhanden ist, ist der für TR064. Ich sollte so Kram nicht mehr so spät anfangen. -_-

Mein Schlüssel ist im Übrigen von deinem abweichend. Wobei mich interessieren würde ob die Box den Schlüssel wirklich selbst erstellt. Nach recover sollte man dann ja einen neuen, privaten Schlüssel haben oder sehe ich das falsch? Könnte das mal jemand testen?

4. Wurde ja bereits von dir korrigiert.

5. Ja, würde ich gerne. :) Meine obige Behauptung gehört wohl der Vergangenheit an. Ich bin das gerade wieder in Ruhe angegangen und die Schlüssel werden wohl auf der Box selbst erzeugt. Per tftp rausholen ist leider nicht mögich. (access violation - weshalb ein austauschen wohl auch flach fällt :()

Wobei sich die damalige Aussage von AVM so anhört, als wäre das damals nicht der Fall gewesen und die Boxen hätten einen, gemeinsamen privaten Schlüssel gehabt. Daher kam ich überhaupt auf diese These. Da hätte ich aber besser mal eine Nacht drüber schlafen sollen.

6. Da hast du wohl aktuel Recht - siehe TR064 Key.


Somit hat sich das wohl. Wäre nur noch interessant, ob die Aussage von AVM damals einfach nur unglücklich gewählt wurde oder ob das wirklich mal der Fall war.


EDIT:
Selbst unterschriebene Zertifikate in FF abspeichern bringt wenig Sinn. Denn die Warnmeldung kriegst du damit nicht weg. Wenn du jedoch CA abspeicherst, dann schon.
Wir haben ein selbst signiertes Zertifikat im Webserver laufen, welches von keiner zusätzlichen CA unterzeichnet wurde. Einfach einen privaten Schlüssel erzeugt, das Zertifikat erzeugt und beides in den Apache geknallt bzw. knallen lassen.
Mein FF und die Browser meiner Kollegen (Opera & FF) fressen das hervorragend. Einmal aufgenommen ist natürlich auch die Warnmeldung weg, sofern man dem FF dies dauerhaft erlaubt.
Bei der Fritzbox läuft es doch genau so. Die Zertifikate wurden auch von keiner zusätzlichen CA unterschrieben. :confused:
 
Zuletzt bearbeitet:
Ich konnte es ja nicht lassen - nach recover bzw. neuer FW scheint auch der private Schlüssel ein anderer zu sein.

Die Box erzeugt diesen also allen Anschein nach selbst.
 
Ich habe mal bei mir den Fernzugang aktivert. Das zugehörige Zertifikat sieht so aus:
Code:
        Issuer: CN=fritz.box
        Validity
            Not Before: Jan  1 00:00:43 2000 GMT
            Not After : May 18 00:00:43 2027 GMT
        Subject: CN=fritz.box
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            RSA Public Key: (1024 bit)
                Modulus (1024 bit):
                    00:ad:33:5e:cd:08:ff:dd:b0:be:c3:2e:06:df:8f:
                    69:0b:cf:ef:ea:c6:f2:26:8b:de:08:47:d3:27:db:
                    8f:7d:ea:c0:31:50:6e:3a:76:3b:aa:7a:4a:2a:1a:
                    b4:2a:d7:81:04:63:39:07:a1:ff:72:25:df:c1:61:
                    a1:99:1d:8c:22:73:fd:cd:0b:46:e4:22:70:81:fd:
                    20:2f:07:e0:de:db:f6:e5:49:3f:c2:a1:91:21:1b:
                    bc:15:9a:8d:34:49:db:43:18:e9:1f:5d:b8:be:05:
                    76:6b:85:94:ea:81:1d:1c:9b:ec:2d:7d:15:a7:cc:
                    36:23:ac:8a:08:6d:f4:25:f9
                Exponent: 65537 (0x10001)
Wie man sieht, ist auch die Gültigkeitsdauer sehr großzügig ausgelegt, von 2000 bis 2027. Der Name lautet fritz.box.

Ich habe daher mal einen Eintrag für DynDNS gemacht, jetzt sieht das Zertifikat so aus:
Code:
        Issuer: CN=test.dyndns.org
        Validity
            Not Before: Dec  3 09:48:46 2010 GMT
            Not After : Mar 14 03:20:30 1902 GMT
        Subject: CN=test.dyndns.org
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            RSA Public Key: (1024 bit)
                Modulus (1024 bit):
                    00:ad:33:5e:cd:08:ff:dd:b0:be:c3:2e:06:df:8f:
                    69:0b:cf:ef:ea:c6:f2:26:8b:de:08:47:d3:27:db:
                    8f:7d:ea:c0:31:50:6e:3a:76:3b:aa:7a:4a:2a:1a:
                    b4:2a:d7:81:04:63:39:07:a1:ff:72:25:df:c1:61:
                    a1:99:1d:8c:22:73:fd:cd:0b:46:e4:22:70:81:fd:
                    20:2f:07:e0:de:db:f6:e5:49:3f:c2:a1:91:21:1b:
                    bc:15:9a:8d:34:49:db:43:18:e9:1f:5d:b8:be:05:
                    76:6b:85:94:ea:81:1d:1c:9b:ec:2d:7d:15:a7:cc:
                    36:23:ac:8a:08:6d:f4:25:f9
                Exponent: 65537 (0x10001)
Der Name, auf den das Zertifikat ausgestellt ist, wurde geändert. Die Start-Zeit entspricht auch dem Zeitpunkt, an dem das Zertifikat erstellt wurde. Das Ende der Gültigkeit ist etwas unglücklich. Entweder hat hier openssl ein Problem mit der Anzeige, oder es gibt einen Überlauf beim Ende-Zeitpunkt. Auf jeden Fall meldet der Browser das Zertifikat als abgelaufen. Beim Reboot bleiben die Zeiten erhalten. Der Key ist auch gleich geblieben.
 
Technisch ist es kein Problem, aber AVM bräuchte dazu ein Zertifikat, das andere Zertifikate signieren kann. Und sie müßten entweder jede Anforderung überprüfen, das wäre zusätzliche Arbeit, die wohl kein Anwender bezahlen will, oder jede Anforderung durchwinken, und das wäre dann doch sehr unsicher.
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.