[Info] FRITZ!Box-Zertifikat auf der Box für andere Software mit TLS-Verschlüsselung benutzen

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
15,138
Punkte für Reaktionen
1,703
Punkte
113
Wenn das Kommandozeilen-Programm aus dem Freetz-Ticket 2740 zur Verfügung steht (egal ob in der Version von er13 mit der Benutzung des AVM-Tools oder in meiner mit dem direkten Aufruf von libboxlib.so), ist die Verwendung in der Apache2-Konfiguration mit drei Zeilen tatsächlich schon erledigt:

Code:
SSLCertificateFile "/var/flash/websrv_ssl_cert.pem"
SSLCertificateKeyFile "/var/flash/websrv_ssl_key.pem"
SSLPassPhraseDialog exec:/usr/bin/privatekeypassword
Mehr braucht es eigentlich nicht, aber die beim Apache2-Paket mitinstallierte Datei /etc/apache2/extra/httpd-ssl.conf hat (zumindest in meinen Augen, das muß nicht zwangsläufig auch von anderen geteilt werden) auch noch andere Mängel, denn sie ist bei den zulässigen Cipher-Suites nicht auf dem Stand der Zeit. Daher hänge ich hier mal ein Patch-File an, das man - wenn man das Box-Zertifikat mit dem Apache2 nutzen will und die Voraussetzungen durch Auswahl von privatekeypassword beim Build gegeben sind - z.B. in seiner fwmod.custom mit dem Kommando

Code:
patch -p0 < ../../make/privatekeypassword/packages/apache2/post_install-httpd-ssl.conf.patch
ausführen lassen könnte, wenn man es an den passenden Platz kopiert hat. Da das apache2-Paket im Freetz praktisch ohne Konfigurationsoberfläche auskommen muß, fällt mir aus dem Stand kein besserer Weg zur Integration der notwendigen Änderungen in das fertige Image ein.

Wer dann noch (auch wenn LogJam inzwischen im OpenSSL erst einmal gepatcht wurde - durch die minimale Länge der DH-Parameter von 768 Bit) mit eigenen DH-Parametern arbeiten will, kann diese auch an das Zertifikat im Flash-Speicher der FRITZ!Box anhängen, wie ich es hier erläutert habe.

Allerdings sollte man die Generierung der DH-Parameter besser auf einem etwas potenteren Gerät ausführen lassen, dazu einfach das Kommando

Code:
openssl dhparam -out dh2048.pem -5 2048

starten und sich in Geduld üben. Das Ergebnis dieser Bemühungen (den Inhalt der Datei dh2048.pem) dann an das Zertifikat der FRITZ!Box in der Datei /var/flash/websrv_ssl_cert.pem anhängen, in etwa so (das ist keine "Anleitung", nur ein Beispiel):
Code:
cat /var/flash/websrv_ssl_cert.pem /var/media/ftp/dh2048.pem >/var/cert.pem
cat /var/cert.pem -> Sichtkontrolle, ob da wirklich das Zertifikat und die DH-Parameter drin stehen
cat /var/cert.pem >/var/flash/websrv_ssl_cert.pem
Box neu starten oder zumindest den ctlmgr beenden und neu starten
ctlmgr -s
ctlmgr
Das funktioniert nebenbei bemerkt gleich beim Import eines Zertifikats nicht, da 'firmwarecfg' mit einem DHPARAM-Abschnitt in der Datei nichts anzufangen weiß und daher diesen nicht in die Datei im Flash übernimmt.

Neben dem Apache2 arbeiten auch noch andere Pakete (z.B. stunnel) mit auf diesem Weg definierten DH-Parametern, dabei muß man die Generierung eigener Primzahlen für den Diffie-Hellman-Schlüsselaustausch nur einmal durchführen.

Nach meinen Tests berücksichtigt auch der ctlmgr von AVM die dort vorhandenen DH-Parameter, auch wenn das (dazu komme ich gleich noch einmal) eher uninteressant ist, denn AVM verweigert selbst einer 7490 - vermutlich aus Performance-Gründen - die Benutzung von DHE für PFS in aktueller Firmware im eigenen GUI.

Ob die FRITZ!Box in der Zertifikatdatei auch EC-Parameter akzeptiert (bzw. sie still ignoriert), habe ich nie getestet, da in OpenSSL 1.0.1 ohnehin keine (für mich) vertrauenswürdigen Kurven definiert sind (das leitet sich alles mehr oder weniger aus ANSI X9.92 her, was da vor 1.0.2 implementiert wurde) und sich der ganze Aufwand damit für mich eher nicht lohnt bei dieser Version ... auch wenn ich die EECDH-Verfahren in der Cipher-Suite-Auswahl berücksichtige (und auch ECDSA-Authentication nicht ausgeschlossen habe), weil auch eine von Geheimdiensten (vermutlich) kompromittierte Verschlüsselung - bei Kenntnis der Gefahren - immer noch besser ist als gar keine.

Mit der von mir im Patch verwendeten Auswahl an Cipher-Suites:

Code:
!DSS:!MD5:EDH+AESGCM:EDH+AES256:EDH+AES:EDH+3DES:EECDH+AESGCM:EECDH+AES256:EECDH+AES128:EECDH+3DES:RSA+AESGCM:RSA+AES:RSA+3DES

kommt am Ende folgende Liste an Suites zusammen (bei der Benutzung der AVM-SSL-Libraries ab OpenSSL 1.0.1h, bei selbst kompiliertem OpenSSL - auch im Rahmen von Freetz - kann das natürlich anders aussehen):

Code:
DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH       Au=RSA  Enc=AESGCM(256) Mac=AEAD
DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH       Au=RSA  Enc=AESGCM(128) Mac=AEAD
DHE-RSA-AES256-SHA256   TLSv1.2 Kx=DH       Au=RSA  Enc=AES(256)  Mac=SHA256
DHE-RSA-AES256-SHA      SSLv3 Kx=DH       Au=RSA  Enc=AES(256)  Mac=SHA1
DHE-RSA-AES128-SHA256   TLSv1.2 Kx=DH       Au=RSA  Enc=AES(128)  Mac=SHA256
DHE-RSA-AES128-SHA      SSLv3 Kx=DH       Au=RSA  Enc=AES(128)  Mac=SHA1
EDH-RSA-DES-CBC3-SHA    SSLv3 Kx=DH       Au=RSA  Enc=3DES(168) Mac=SHA1
ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AESGCM(256) Mac=AEAD
ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AESGCM(256) Mac=AEAD
ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AESGCM(128) Mac=AEAD
ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AESGCM(128) Mac=AEAD
ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AES(256)  Mac=SHA384
ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AES(256)  Mac=SHA384
ECDHE-RSA-AES256-SHA    SSLv3 Kx=ECDH     Au=RSA  Enc=AES(256)  Mac=SHA1
ECDHE-ECDSA-AES256-SHA  SSLv3 Kx=ECDH     Au=ECDSA Enc=AES(256)  Mac=SHA1
ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AES(128)  Mac=SHA256
ECDHE-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH     Au=ECDSA Enc=AES(128)  Mac=SHA256
ECDHE-RSA-AES128-SHA    SSLv3 Kx=ECDH     Au=RSA  Enc=AES(128)  Mac=SHA1
ECDHE-ECDSA-AES128-SHA  SSLv3 Kx=ECDH     Au=ECDSA Enc=AES(128)  Mac=SHA1
ECDHE-RSA-DES-CBC3-SHA  SSLv3 Kx=ECDH     Au=RSA  Enc=3DES(168) Mac=SHA1
ECDHE-ECDSA-DES-CBC3-SHA SSLv3 Kx=ECDH     Au=ECDSA Enc=3DES(168) Mac=SHA1
AES256-GCM-SHA384       TLSv1.2 Kx=RSA      Au=RSA  Enc=AESGCM(256) Mac=AEAD
AES128-GCM-SHA256       TLSv1.2 Kx=RSA      Au=RSA  Enc=AESGCM(128) Mac=AEAD
AES256-SHA256           TLSv1.2 Kx=RSA      Au=RSA  Enc=AES(256)  Mac=SHA256
AES256-SHA              SSLv3 Kx=RSA      Au=RSA  Enc=AES(256)  Mac=SHA1
AES128-SHA256           TLSv1.2 Kx=RSA      Au=RSA  Enc=AES(128)  Mac=SHA256
AES128-SHA              SSLv3 Kx=RSA      Au=RSA  Enc=AES(128)  Mac=SHA1
DES-CBC3-SHA            SSLv3 Kx=RSA      Au=RSA  Enc=3DES(168) Mac=SHA1

Das ist sicherlich restriktiv, aber wer den Apache2 eher für den Zugriff auf seine eigenen Daten benutzt und ihn nicht wirklich der Öffentlichkeit zugänglich machen will, muß ja auch nur die Verschlüsselungen anbieten (und sich dabei auch nur wenige Gedanken über deren Auswirkungen auf den Load der Box machen), die er selbst wirklich für seine Clients benötigt.

Da kann man dann sogar noch überlegen, ob man auf die EC-Verfahren (sowohl beim Schlüsselaustausch als auch bei der Authentifizierung) ganz verzichten kann und will, die Box selbst hat ohnehin kein passendes EC-Schlüsselpaar und damit auch kein Zertifikat dafür, das müßte man auch für den Apache2-Server gesondert erstellen und konfigurieren und auch die Verfahren ohne PFS (also ohne DHE bzw. EECDH, wenn man EC "drin" läßt in der Auswahl) braucht eigentlich kein Mensch mehr. Das geht also noch wesentlich stringenter, wenn man es weiter treiben will.

Auf jeden Fall sollte man auf die vom AVM-Interface immer noch (bei älterer Firmware mit OpenSSL 0.9.8 sogar ausschließlich) angebotenen Verfahren mit RC4 und MD5-HMAC komplett verzichten.

OT: Das macht auch die áktuelle Auswahl der Cipher-Suites im ctlmgr (Firmware 113.06.23) etwas merkwürdig - und eine Änderung durch Patchen der Datei im tmpfs einer 7490 an dieser Stelle hat durchaus die erwarteten Auswirkungen, diese Folge wird also tatsächlich auch verwendet ... ja, wenn ich es richtig interpretiere, entscheidet der ctlmgr anhand der Existenz der Datei /lib/libssl.so.0.9.8, welche der beiden Cipher-Suite-Strings er benutzen soll, die für 1.0.1 sieht dann so aus:

Code:
kEECDH+ECDSA:kEECDH+AESGCM:kEECDH+RC4:kEECDH:HIGH:MEDIUM:+SHA:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!DSS:!PSK:!SRP:!kECDH:!CAMELLIA:!EDH:!ADH:!DES:!DH

Wenn ich da nicht etwas fundamental falsch verstanden habe, würden ECDSA-Authentifizierungen (der erste Parameter in der Auswahl) ja ohnehin nicht funktionieren, wenn die Box ihrerseits nur einen RSA-Schlüssel mit 2048 Bit generiert und auch in der Hilfe zum Zertifikatimport ausdrücklich von einem RSA-Zertifikat die Rede ist.

Ob der ctlmgr auch mit einem ECDSA-Schlüssel umgehen könnte, habe ich (wieder wegen der Zweifel am Einsatz der NIST-Kurven) aber gar nicht erst getestet.

Aber hier findet sich dann auch der von mir weiter oben angesprochene Ausschluß von DHE für PFS ... wenn man den ctlmgr geeignet patcht (z.B. mit bspatch eine Kopie im tmpfs erzeugt und den ctlmgr mit dieser Kopie betreibt nach bind-Mount), erhält man sogar für den externen Zugriff auf das AVM-GUI (inkl. NAS/MyFRITZ) wieder den "gewohnten" Umfang an Cipher-Suites und muß nicht länger auf PFS verzichten, wenn man der EC-basierten Kryptographie auf der Basis von NIST-spezifizierten Kurven nicht vertrauen will.

Daß EDH am Ende tatsächlich langsamer ist als EECDH, ist auch klar. Wer mehr Wert auf Geschwindigkeit beim Verbindungsaufbau legt, sollte das also vergessen, wenn ihm die zusätzliche Zeit, die z.B. das Synchronisieren des Tablets mit den OwnCloud-Kontakten auf der eigenen FRITZ!Box benötigt, tatsächlich wichtig ist. Wir reden hier immer noch nur vom Schlüsselaustausch und nicht von der symmetrischen Verschlüsselung der "Nutzdaten", das ist bei EDH und EECDH am Ende bei der AVM-Firmware auch immer AES128 oder AES256 mit oder ohne GCM und SHA1 bis SHA384 als HMAC. Über das zusätzlich dort mögliche RC4 wollten wir ja den Mantel des Schweigens breiten ... das wurde eigentlich schon vor Snowden nicht mehr wirklich empfohlen (nur als Workaround für die BEAST-Attacke) und seitdem ist eigentlich klar, daß dieses Verfahren praktisch als "geknackt" gelten kann, zumindest bei der NSA.

Aber das ist eigentlich ein komplett anderer Beitrag, deshalb "back to topic":

Die in der Liste als SSLv3 aufgeführten Suites sollten in Wirklichkeit TLSv1 sein, was sich ja von SSLv3 (im Wesentlichen) nur durch die Reihenfolge von Operationen (encrypt-then-MAC) unterscheidet und bei der Verwendung der Freetz-Version automatisch an die Stelle von SSLv3 treten sollte.

Die AVM-Version ist ja schon einiges älter (noch vor Poodle, auch wenn sie mangels Cookies dafür nicht anfällig ist) und läßt wohl auch noch "echtes" SSLv3 zu. Dort bliebe dann ggf. nur, die Cipher-Suites noch um ein !SSLv3 am Beginn zu ergänzen, womit dann aber nur noch TLSv1.2-Protokolle übrig bleiben (TLSv1.1 definiert selbst keine zusätzlichen Suites), was etwas angegrauten Clients u.U. sauer aufstößt.
 
Zuletzt bearbeitet:
Ich habe nun noch Freetz-Tickets mit Patches bzw. Erläuterungen/Fragen für ShellInABox, stunnel und OpenVPN angelegt, das apache2-Ticket hat die Nummer 2749. Gleichzeitig habe ich den Thread-Titel hier von "Apache2" auf "weitere Pakete" erweitert.

Ob und wann aus diesen Tickets irgendwann mal ein Commit für den Trunk resultiert, kann ich weder einschätzen noch beeinflussen.

Wenn jemand das bei sich (vorher, falls es überhaupt ein Commit geben sollte) schon durch eigenes Patchen einer aktuellen Trunk-Kopie auf seinem Build-System testen will (zumindest die zwei Pakete mit Patches, für OpenVPN und apache2 sind solche ja nicht erforderlich), darf er nicht vergessen, auch die benötigte Library zum Ermitteln des boxspezifischen Kennworts aus Freetz-Ticket 2740 zu erzeugen und zwar - wenn die Patches unverändert angewendet werden sollen - in der Version 0.5 (ab comment:18).

Weitere Pakete, die für die Nachnutzung in Frage kämen, verwende ich selber nicht, daher ist erst einmal mein Interesse an dieser Stelle erschöpft. Sollte jemand noch ein bereits in Freetz vorhandenes Paket "umstellen" wollen und dabei Hilfe benötigen, stehe ich dafür gerne zur Verfügung.

Die Frage der Nachnutzung des Schlüsselpaars für die SSH-Verschlüsselung mit dropbear steht noch auf meiner eigenen ToDo-Liste, das braucht aber entweder ein komplettes OpenSSL-Binary für die Extraktion des Schlüssels aus der key-Datei (auch wenn man die AVM-Libs wahrscheinlich benutzen könnte und das den zusätzlichen Platzbedarf etwas reduziert) oder eine abgespeckte - dann sicherlich selbst zu schreibende - Version, die den Base64-kodierten Inhalt als ASN.1 interpretiert und die Primzahlen dort so extrahiert, daß dieser private Schlüssel nicht am Ende doch irgendwo in Dateiform für den dropbear "herumfliegt". Das erfordert auch entsprechende Änderungen am dropbear-Code und dafür braucht es noch ein wenig Zeit.
 
Zuletzt bearbeitet:
Nach einer Aktualisierung der stunnel-Version paßt der Patch im Trac-Ticket 2750 nicht mehr, ein angepaßter Patch gegen
Code:
Path: .
Working Copy Root Path: .
URL: http://svn.freetz.org/trunk
Relative URL: ^/trunk
Repository Root: http://svn.freetz.org
Repository UUID: 149334a1-2f27-0410-a3b9-fc62619ac1e6
Revision: 13348
Node Kind: directory
Schedule: normal
Last Changed Author: er13
Last Changed Rev: 13348
Last Changed Date: 2015-08-13 01:03:22 +0200 (Thu, 13 Aug 2015)
ist unter der URL
http://yourfritz.de/patches/stunnel-5.22-boxcert.patch
zu finden.
 
Zuletzt bearbeitet:
Weil ich das jetzt auch außerhalb der Box brauche, habe ich einfach mal ein Shell-Skript eingecheckt, mit dem man das Kennwort für die Datei mit dem privaten Schlüssel auch ermitteln kann. Die bisher von mir geübte "Zurückhaltung" ist am Ende ohnehin viel Augenwischerei ... jeder Anfänger kann sich mit "trial & error" ein Bild davon machen, welcher Bestandteil des Environments da nun wirklich über dieses Kennwort entscheidet und dann ist es auch wieder ein Leichtes, mit diesem Wissen auf einer FRITZ!Box eine passende Umgebung für das C-Programm bzw. die Bibliothek zu etablieren.

Das ist nun auch nicht so "sophisticated", wie dieses Kennwort von AVM ermittelt wird ... weiß man erst einmal, was nun die entscheidende Angabe im Environment ist, ist es (angesichts des "Zeichenvorrats" dieser Kennwörter, den man auch leicht ermitteln kann, wenn man auf mehr als eine Box Zugriff hat) auch keine große Leistung mehr, auf die "Tabelle" zur Übersetzung zu schließen und dann ist es nur noch etwas "Probieren", welche kryptographische Funktion nun das richtige Ergebnis liefert (wobei AVM ja fast überall nur MD5 für (interne) Hashes verwendet).

Von diesem Punkt (mit der Ansicht des Hash-Wertes in hex) bis zur Erkenntnis, daß da einfach die höherwertigen Bits ignoriert werden und dann so eine Art Base64-Kodierung erfolgt (halt mit einer abgewandelten/verdrehten Tabelle), ist es dann nur noch ein kleiner Schritt.

Lediglich das Ermitteln der übersetzten Werte für 62 und 63 ist etwas komplizierter (a-z, A-Z und 0-9 sind ja nur 62 Werte, die für 0 bis 61 stehen), weil man erst mal einen Wert für "maca" finden muß, der diese Werte enthält. Hat man aber erst festgestellt, daß offenbar "securestore_get" die wirkliche Länge der Zeichenkette in "maca" benutzt (einfach mal die "maca" auf "1" setzen und damit das Ergebnis "ekc4G5Jc" erhalten und vergleichen) und das gar nicht auf ein richtiges Format (einer MAC-Adresse) geprüft wird, dann ist es wieder simpel, sich irgendeine Zeichenkette zu suchen, die in den ersten 8 Byte ihres Hash-Wertes eine Zahl hat, die in den 6 niederwertigen Bits dann 62 oder 63 enthält.

Mit dieser Zeichenkette als "maca" (im Urlader-Environment) kann man dann auch aus der AVM-Implementierung die für 62 (Dollar Ausrufungszeichen) und 63 (Ausrufungszeichen Dollar) verwendeten Werte ermitteln. Nun hat aber bereits der MD5-Hash für die "3" den Wert für die 62 und der für "4" dann den für 63 - das dauert also auch nicht wirklich lange, da eine passende "maca" zu finden.

Da lohnt sich eigentlich das verwendete "Suchkommando" nicht wirklich, aber das weiß man vorher auch nicht sicher:
Code:
$ [COLOR="#0000FF"]i=0;while true; do for x in $(printf "%u" $i | md5sum | sed -n -e "s|^\(.\{16\}\).*|\1|p" | sed -e "s|..|& |g"); do [ $(( 0x$x % 64 )) -ge 62 ] && echo $i '->' $x; done; i=$(( i + 1 )); done[/COLOR]
3 -> 7e
3 -> fe
4 -> 7f
5 -> 7f
9 -> 7f
15 -> 7f
16 -> 7e
37 -> bf
42 -> 3f
56 -> 3e
59 -> 3f
61 -> 7f
61 -> 7f
69 -> bf
71 -> bf
79 -> fe
83 -> fe
83 -> ff
85 -> 3e
91 -> bf
92 -> 7e
97 -> bf
^C
Das nur als "Hintergrund-Info", falls jemand es selbst mal "nachermitteln" will.

EDIT: @er13 machte mich darauf aufmerksam, daß ich die Zeichen für 62 und 63 sowohl hier in der Beschreibung als auch in den neuen Implementierungen vertauscht hatte ... das sind bei mir leider alles nur "theoretische Zeichen", daß ich kein Gerät habe, wo der MD5-Hash über die MAC-Adresse in den ersten 8 Byte einen Wert mit 0x3e oder 0x3f in den unteren 6 Bits ergibt.
 
Zuletzt bearbeitet:
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.