[Problem] Stunnel mit MyFRITZ SSL Zertifikat ausführen

bfmeb

Neuer User
Mitglied seit
16 Feb 2021
Beiträge
5
Punkte für Reaktionen
0
Punkte
1
Hallo,
Ich hoffe ihr könnt mir weiter helfen. Leider habe ich zu meinem Problem kein passendes Thema gefunden.

Ich habe freetz auf der Fritz Box 6490 cable mit Apache, PHP und stunnel installiert. Das läuft alles soweit. Der Apache HTTP Server ist aus dem Internet erreichbar. Zusätzlich nutze ich mein MyFritz Konto um die Fritz Box als Host anzusprechen (DNS record). Vorher hatte ich DynDNS mit no-ip als provider genutzt.

Als nächsten Schritt möchte ich eine SSL Verbindung mittels stunnel ermöglichen. Das funktioniert soweit auch mit dem Fritz OS Zertifikat, nur ist dieses natürlich kein gültiges (vertrauenswürdiges) SSL Zertifikat. Für den HTTPS Zugriff auf die Fritz Box mittels MyFritz gibt es automatisch ein gültiges Lets Encrypt SSL Zertifikat.

Nun möchte ich stunnel mit diesem Zertifikat ausführen, daran scheitere ich leider weil stunnel (logischerweise) einen unverschlüsselten private Key braucht.
Beim entschlüsseln des private Key benötige ich eine pass phrase. Ich habe gehofft, dass der private key eventuell mit den gleichen Passwort wie bei den Fritz OS Zertifikat verschlüsselt würde. Demnach habe ich das Tool privatekeypassword von PeterPawn genutzt. Leider stimmte das Passwort nicht.

Nun ist die Frage, kann man stunnel irgendwie mit den lets encrypt Zertifikaten ausführen? Wenn ja, wie könnte man dann den Schritt der Erneuerung (alle 3 Monate bei lets encrypt?) automatisieren.

Ich habe mir auch andere Alternativen (certbot) angeschaut. Da schien mit der Aufwand auf den ersten Blick recht hoch. Gibt es andere bzw. bessere Alternativen die man verfolgen sollte?
Habe ich eventuell grundsätzlich einen Denkfehler bei meiner Herangehensweise?
Ich freue mich über jede Rückmeldung dazu. Vielen Dank schonmal vorab für eure Zeit, und Hilfe!
 
Zuletzt bearbeitet:

berndy2001

Mitglied
Mitglied seit
26 Nov 2005
Beiträge
415
Punkte für Reaktionen
6
Punkte
18
Ich habe haproxy in Verbindung mit einem von acme.sh (extern) automatisiert importierten Letsencrypt-Zertifikat im Einsatz. Damit haproxy das Zertifikat nutzen kann habe ich folgendes in der rc.custom.
openssl rsa -in /var/flash/websrv_ssl_key.pem -passin pass:$(privatekeypassword) -out /tmp/flash/haproxy/haproxy.pem 2>/dev/null && cat /var/flash/websrv_ssl_cert.pem >> /tmp/flash/haproxy/haproxy.pem


Vielleicht kannst du das für das LetsEncrypt-Zertifikat anpassen.
 

bfmeb

Neuer User
Mitglied seit
16 Feb 2021
Beiträge
5
Punkte für Reaktionen
0
Punkte
1
Danke für die schnelle Antwort. Ich habe das Mal ausprobiert, aber wie vermutet kann ich den Key mit dem Tool nicht entschlüsseln. Im Hinblick auf die Automatisierung würde ich das gerne nach deinem Vorschlag umsetzen. Im Rahmen der Zertifikatsaustellung von lets encrypt wird vermutlich eine andere Routine bei der private Key Verschlüsselung verwendet. Wahrscheinlich kann ich das Zertifikat dann nicht für einen eigenen HTTPS Server verwenden oder sehe ich das falsch? Hat noch jemand eine Idee dazu?
 

berndy2001

Mitglied
Mitglied seit
26 Nov 2005
Beiträge
415
Punkte für Reaktionen
6
Punkte
18
ping @PeterPawn

Ich ging davon aus, dass der Schlüssel für letsencrypt_key.pem und websrv_ssl_key.pem gleich sei, aber dem ist nicht so. Wahrscheinlich ist LE auch deshalb in Peters Doku zu privatekeypassword nicht erwähnt.
 

bfmeb

Neuer User
Mitglied seit
16 Feb 2021
Beiträge
5
Punkte für Reaktionen
0
Punkte
1
OK. Eventuell ist es wohl auch nicht gewollt dass man das Zertifikat einfach nutzen kann für eigene TLS Verschlüsselungen unter dem myfritz Host. Dann muss ich wohl ein eigenes LE Zertifikat importieren/automatisieren. Ich habe im Forum einige Hinweise gefunden wie so etwas funktionieren kann.
Link
Danke
 

bfmeb

Neuer User
Mitglied seit
16 Feb 2021
Beiträge
5
Punkte für Reaktionen
0
Punkte
1
OK das schau ich mir Mal an danke
 

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
13,625
Punkte für Reaktionen
1,189
Punkte
113
Ich benutze kein LE-Zertitikat und habe auch keine FRITZ!Box (mit Shell) an einer Stelle installiert, wo sie in der Lage ist, sich das LE-Zertifikat unfallfrei zu besorgen. Eine 7490 mit 07.21 als Testobjekt hat das - auch mit dem Recht auf automatische Portfreigaben über PCP im Edge-Router - schon mal nicht gepackt.

So viele Optionen gibt es ja nicht, wie das Kennwort gebildet werden kann - ich würde mir mal die Datei mit dem privaten Schlüssel aus der Box holen und die dann so lange mit OpenSSL traktieren (mit diversen Kombinationen der "bekannten" Werte als Eingabedaten für einen MD5-Hash, der dann wieder als Kennwort für den privaten Schlüssel getestet wird), bis sie ihr Geheimnis preisgeben will.

Ansonsten dauert das noch länger - ich WILL meinen Edge-Router nicht mit einer FRITZ!OS-Version ausstatten, bei der die LE-Zertifikate funktionieren würden und müßte daher (obwohl's mich eigentlich nicht wirklich interessiert) erst mal einen Debugger anwerfen bzw. mir erst mal ansehen, wie das bei AVM im letsencrypt-Binary läuft. Vermutlich wird das auch wieder über securestore_get in der libboxlib.so verwaltet ... da gibt es (bzw. "gab es aus der Erinnerung") mehrere Zusammenstellungen von Box-Variablen, die über einen Parameter beim Aufruf der Funktion ausgewählt wurden.

Meine "Anleitung" zum Ermitteln der tatsächlich verwendeten Daten für das Kennwort wäre die Benutzung eines Debuggers, mit dem man einen Breakpoint auf MD5Update setzt (eine andere Hash-Funktion wird von der libboxlib.so nicht importiert, nach dem was ich beim nm -D -C so sehe) und sich die Daten ansieht, die da durch die Hash-Funktion gejagt werden sollen.

Das erfordert aber sowohl den Debugger (am ehesten sicherlich gdb) als auch die Kenntnis zum Umgang mit ihm (da ist nichts mit GUI oder so) - vermutlich ist da das "systematische Probieren" (so wie hier: https://github.com/PeterPawn/decoder/blob/master/scripts/privatekeypassword#L304 für das Kennwort für den Key in der websrv_ssl_key.pem zu sehen) mit anderen denkbaren Kombinationen (ich würde mich zunächst mal auf die vier bekannten "Variablen" beschränken, die an anderen Stellen auch genutzt werden, die kann man erst mal in allen denkbaren Permutationen, jeweils mit und ohne "newline" zwischen den Werten und am Ende, durchlaufen lassen, ob es nicht doch einen Treffer gibt) sogar einfacher für jemanden, der den Debugger (und natürlich die jeweils verwendete Maschinensprache, denn es gibt keine C-Quellen o.ä., die man da laden könnte) nicht bereits beherrscht.

Die vier Zeilen ab der verlinkten Stelle sind jedenfalls "das Herz" des ganzen Algorithmus (alles davor ist nur Beiwerk im Shell-Skript) und das ist schnell umformuliert - aber man braucht eben die Daten der Box und die Datei mit dem verschlüsselten privaten RSA-Schlüssel für das LE-Zertifikat. Kennt man die zum Hashen verwendeten Eingabedaten erst einmal, kann man damit auch wieder ganz einfach ein lekeypassword als Pendant zu dem anderen Programm erstellen.

Da von /bin/letsencrypt die Funktion securestore_get aus der libboxlib.so eingebunden wird und die ihrerseits nur MD5 als Hash einzubinden scheint, kann ich mir auch nur schwer vorstellen, daß AVM sich da irgendetwas Neues hat einfallen lassen - lediglich die Kombinationen der Box-Variablen als Eingabedaten für den MD5-Hash scheinen zu variieren und das machen sie an anderen Stellen ja auch schon (Export, Speicherung von Kennwörtern, etc.).
Rich (BBCode):
vidar:~/._fritzbox/FB7590/154.07.24-84707 $ nm -D bin/letsencrypt | grep securestore
         U securestore_get
vidar:~/._fritzbox/FB7590/154.07.24-84707 $ nm -D lib/libboxlib.so | grep securestore
000209bc T securestore_get
vidar:~/._fritzbox/FB7590/154.07.24-84707 $ nm -D lib/libboxlib.so | grep "\(SHA\|MD5\)"
         U MD5Final
         U MD5Init
         U MD5Update
vidar:~/._fritzbox/FB7590/154.07.24-84707 $
Da dürfte sich also - außer den Eingabedaten für den MD5-Hash - nicht so viel geändert haben - würde ich zumindest mal (bis zum Beweis des Gegenteils) als These in den Raum stellen.
 
Zuletzt bearbeitet:
  • Like
Reaktionen: bfmeb und berndy2001

bfmeb

Neuer User
Mitglied seit
16 Feb 2021
Beiträge
5
Punkte für Reaktionen
0
Punkte
1
Vielen Dank für die sehr ausführliche und hilfreiche Antwort! Ich verstehe nun besser wie das Skript privatekeypassword funktioniert und werde mich mal an einem entsprechenden Pendant versuchen. Ich bin noch relativ neu auf dem Gebiet, demnach muss ich mich trotzdem erstmal einarbeiten.
Wenn ich das richtig verstehe, könnte ich mir dann die acme routinen für die Provisionierung eines eigenen LE Zertifikats sparen. Bei Erneuerung des MyFRITZ LE Zertifikats würde ich dann stunnel einfach neu starten. Wäre das Vorgehen denn grundsätzlich denkbar?
 

berndy2001

Mitglied
Mitglied seit
26 Nov 2005
Beiträge
415
Punkte für Reaktionen
6
Punkte
18
Ja du kannst dir acme sparen (weil das ja die fritzbox ootb macht) und ca. das machen wie ich in #2 beschrieben habe. Sprich Zertifikat verwendbar machen und dann stunnel neu starten. zB per Cronjob 1x/Monat.

Meiner Meinung nach lohnt sich der Aufwand für eine kryptische myfritz Subdomaine nicht. Eine dyndns-Adresse wäre merkbar und ein Zertifikat von acme.sh läge in einem direkt verwendbaren Format vor. Ich muss aber dazu sagen, dass ich nicht weiß wie gut acme.sh auf der Box läuft und welche Besonderheiten es gegenüber einem normalen System gibt.
 

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
13,625
Punkte für Reaktionen
1,189
Punkte
113
Ich habe mir das gestern dann doch noch einmal etwas genauer angesehen ... die Neugierde war stärker als die Vernunft.

Der Witz ist eigentlich, daß auch das /bin/letsencrypt von AVM die Domain für das zu beantragende Zertifikat per Aufruf-Parameter erhält:
Rich (BBCode):
# /bin/letsencrypt -?
usage: letsencrypt [options]
options:
  -?                 - print this help
  -v                 - verbose. (NOTSET)
  -p                 - use production api (server) of letsencrypt.org. (NOTSET)
  -a STRING          - file with letsencrypt.org account info (may not exist). ("/var/tmp/letsencrypt.account")
  -d STRING          - domain dame (subject) for certificate. (NULL)
  -r                 - renew cert instead of initial generate. (NOTSET)
  -c STRING          - certificate PEM file. (NULL)
  -k STRING          - private key PEM file. (NULL)
  -D STRING          - switch debug logs on. (FUNC)
letsencrypt
#
und man daher damit wohl auch ein Zertifikat für einen anderen Domainnamen erhalten könnte. Nur hat AVM offenbar "Vorkehrungen" getroffen (wenn ich das so auf die Schnelle alles richtig gesehen habe) und prüft beim Start von letsencrypt direkt, ob der Vaterprozess, von dem es aufgerufen wurde, auch tatsächlich der ctlmgr ist.

Etwas in der Art hatten wir (bzw. gibt es wohl immer noch) beim ftpd ja schon - extra für den hat AVM das getprivkeypass in der Firmware und dieses Programm prüft auch, ob es vom ftpd aufgerufen wurde und gibt ansonsten nur Mist aus - sehr viel früher hatte ich das mal mit dem getprivkeypass auch gebaut und dabei den Aufruf aus dem ftpd heraus gefaked: https://www.ip-phone-forum.de/threa...at-aus-dem-avm-gui-nutzen.278914/post-2091917

Ich würde eine Wette eingehen, daß man das letsencrypt auf demselben Weg austricksen kann und daß da jemand den schon vorhandenen Code aus dem getprivkeypass nachgenutzt hat. Ich will zwar nicht darauf schwören, daß man das "MyFRITZ!-Zertifikat" tatsächlich für einen anderen Domain-Namen ausstellen lassen kann und daß es hinterher auch ohne jedes Problem vom ctlmgr genutzt werden kann (denn der muß das dann wieder beherrschen, wenn es um die Auswertung der SNI geht), aber zumindest sollte man dem letsencrypt von AVM eine passende Umgebung "vorgaukeln" können (notfalls mit Mount-Namespaces), damit man keine weitere Software zum Ausstellen eines LE-Zertifikats braucht (sofern man nicht andere Anforderungen hat, wie z.B. ein Wildcard-Zertifikat).

Jetzt muß man halt erst einmal das Kennwort für den privaten Schlüssel zum LE-Zertifikat irgendwie herausbekommen - danach würde mich auch interessieren, ob ggf. in der Zertifikat-Datei auch mehr als ein X509-Zertifikat liegen kann (die Frage stellt sich für LE- und FRITZ!Box-Zertifikat - also für das "selbstsignierte") und ob der ctlmgr mittlerweile in der Lage ist, anhand der SNI im Request auch das passende Zertifikat zu wählen - auswerten muß er die Angaben jedenfalls, denn ein TLS-Request für einen Namen, für den kein Zertifikat vorliegt, wird ja jetzt schon abgelehnt. Da das üblicherweise aber auch Sache der Crypto-Library wäre, stehen die Chancen vielleicht sogar gut ... auch das mit den eigenen DH-Parametern als "Anhängsel" am eigenen FRITZ!Box-Zertifikat funktioniert(e) beim TLS ja (wie es heute ist, weiß ich gar nicht genau), selbst wenn man diese Daten "von Hand" hinzufügen muß zur Zertifikat-Datei, weil sie beim Upload ignoriert/entfernt werden.