- 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:
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
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
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):
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:
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):
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:
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.
Code:
SSLCertificateFile "/var/flash/websrv_ssl_cert.pem"
SSLCertificateKeyFile "/var/flash/websrv_ssl_key.pem"
SSLPassPhraseDialog exec:/usr/bin/privatekeypassword
Code:
patch -p0 < ../../make/privatekeypassword/packages/apache2/post_install-httpd-ssl.conf.patch
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
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: