Perfect Forward Secrecy - Synology DS?

[ssdnvv]

Ich hab die Ciphersuite geändert zu

SSLCipherSuite ECDH: DH:HIGH:MEDIUM:!RC4:!aNULL:!eNULL:!LOW:!DES:! 3DES:!kRSA

Bekomme aber in Chrome die "Fehlermeldung"

Ihre Verbindung zu <ph name="DOMAIN"/> ist mit einer veralteten Codier-Suite verschlüsselt.

Zugegeben, der Thread ist ein Jahr alt, aber ist das heute tatsächlich schon veraltet? Was wäre denn eine aktuelle Ciphersuite, die nur PFS erlaubt?

 

[Frogman]

Zunächst ein paar Formalien: Deine Cipher-Definition enthält Leerzeichen - das sollte nicht sein (also vor "_DH" und "_3DES" entfernen).
Dazu kannst Du das "MEDIUM" weglassen, weil es nicht mehr liefert, als ohnehin in "HIGH" enthalten ist.
Im Speziellen werden mit Deiner Definition auch Ciphren zugelassen, die auf DH-Schlüsseltausch setzen. Dahingehend liefert das DSM - aufgrund seines Apache 2.2.29 - immer noch eine Beschränkung in der möglichen Länge der DH-Parameter, die auf 1024bit limitiert wird. Ein längerer Schlüssel (der heutzutage mit einer Länge von 2048bit oder gar 4096bit erzeugt wird) bringt also keine weitere Sicherheit, das Niveau wird auf 1024bit-DH begrenzt (was Google dann mit einer unschönen Meldung quittiert). Die Bewertung bei ssllabs.com wird daher auch kurzerhand abgewertet auf unter 'C', glaube ich.

Im Apache 2.4.x ist das schon seit einiger Zeit korrigiert, dort lassen sich auch eigene/generische DH-Parameter bis zu 4096bit nutzen. Und für den Apache ab 2.2.30 ist das jüngst auch backportiert worden (ich habe Synology eindringlich darauf hingewiesen, zeitnah den Apache allein aus diesen Sicherheitsaspekten heraus zu aktualisieren, mindestens auf den 2.2.31, der im Juli released wurde - schauen wir mal, die erste Antwort aus Fernost war ermutigend).
Solange Du mit dem 2.2.29 leben musst, bleibt Dir nur, DHE auszuschließen (und natürlich auch ECDH, was kein Forward Secrecy liefert) - dann bleibt PFS nur mit ECDHE. Eine hinreichend gute Sammlung, in der PFS am höchsten priorisiert wird, erhälst Du mit

SSLCipherSuite EECDH+AESGCM:AES+EECDH:+ECDHE-RSA-AES256-SHA:+ECDHE-RSA-AES128-SHA:RSA+AESGCM:RSA+AES:RSA+CAMELLIA:+AES256-SHA:+AES128-SHA:!EXPORT:!eNULL:!aNULL:!DES:!3DES:!RC4:!RC2:!MD5:!IDEA:!SEED:!EDH:!aECDH:!aECDSA:!kECDHe:!SRP:!PSK

Dabei werden noch ein paar andere Dinge berücksichtigt, die man nicht vergessen sollte, wenn man auf ein hohes Niveau Wert legt: Ciphren mit preshared key werden ausgeschlossen (PSK-...) sowie auch SRP-Ciphren, Export und noch ein paar Kleinigkeiten. Zudem liefert die obige Zeile eine Priorisierung von GCM-Verschlüsselungen und einen SHA2-Hash für die Nachrichtenauthentifikation. Sie läßt nachgeordnet einen RSA-Schlüsseltausch noch zu mit AES/Camellia-Verschlüsselung (der zwar kein PFS bietet, aber aus Kompatibilitätsgründen manchmal hilfreich ist):

ECDHE-RSA-AES256-GCM-SHA384
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-RSA-AES256-SHA384
ECDHE-RSA-AES128-SHA256
ECDHE-RSA-AES256-SHA
ECDHE-RSA-AES128-SHA
AES256-GCM-SHA384
AES128-GCM-SHA256
AES256-SHA256
AES128-SHA256
CAMELLIA256-SHA
CAMELLIA128-SHA
AES256-SHA
AES128-SHA

Ist RSA-Schlüsseltausch nicht notwendig/gewollt, kann man die auch herausnehmen, dann bleiben nur die ECDHE-... übrig, die allesamt unkritisches PFS liefern:

SSLCipherSuite EECDH+AESGCM:AES+EECDH:+ECDHE-RSA-AES256-SHA:+ECDHE-RSA-AES128-SHA:!EXPORT:!eNULL:!aNULL:!DES:!3DES:!RC4:!RC2:!MD5:!IDEA:!SEED:!EDH:!aECDH:!aECD
SA:!kECDHe:!SRP:!PSK

 

[ssdnvv]

Die Leerzeichen waren C&P-Fehler, hatte das korrekt in der Konfigurationsdatei drinnen (ansonsten quittiert die Software auch den Dienst).

Habe nur Android 5.x/Windows 7 Clients, von daher muss ich mit der Kompatibilität nicht sonderlich rücksichtsvoll sein.

Die Verschlüsselung ist unter Firefox mit deiner letzten Code-Zeile jetzt nur noch 128bit AES. Wie kann ich es denn einrichten, so dass nur 256bit verschlüsselt wird? Ein einfaches Entfernen von

+ECDHE-RSA-AES128-SHA:

führt (nach dem obligatorischen Neustart von httpd-sys/-user) nicht zum Ziel.

 

[Frogman]

Die AES128 brauchen Dir keine Sorge bereiten. Schau oben in die Liste - dort findest Du an zweiter Position den ECDHE-RSA-AES128-GCM-SHA256 (der von den meisten Servern auf der Welt priorisiert wird). Der wird hier verwendet mit dem FF (SHA384 unterstützt FF nicht). Es geht dabei um die Priorisierung von GCM über CBC, was gewisse Gründe hat. Das Niveau von AES128 ist dabei nicht wirklich schlechter als mit AES256, außerdem ist es etwas schneller.

EDIT:
Willst Du tatsächlich nur AES256 zulassen, nimm

SSLCipherSuite EECDH+AESGCM:AES+EECDH:!AES128:!EXPORT:!eNULL:!aNULL:!DES:!3DES:!RC4:!RC2:!MD5:!IDEA:!SEED:!EDH:!aECDH:!aECDSA:!kECDHe:!SRP:!PSK

das liefert

ECDHE-RSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-SHA384
ECDHE-RSA-AES256-SHA

 

[ssdnvv]

Recht herzlichen Dank für deine Hilfe und deine Erklärungen

 

[jahlives]

@Frogman

... das Niveau wird auf 1024bit-DH begrenzt (was Google dann mit einer unschönen Meldung quittiert).

wäre mir neu dass Chrome DH Paramter >=1024 anmotzt. Klar ist 1024bit nicht sehr zukunftsicher, aber alle Browserhersteller haben nur DH Parameter < 1024 ausgesperrt. Chrome motzt nur bei weniger als 1024bit. Ich vermute bei ssdnv wurde allenfalls eine Export Chipher verwendet und die motzt jeder Browser an, am DH Parameter mit 1024bit kann es imho nicht liegen. Sonst könnte Chrome praktisch keine HTTPS Webseiten mehr aufrufen ;-)

 

[Frogman]

wäre mir neu dass Chrome DH Paramter >=1024 anmotzt.

Du meinst " < =1024"? Ich habe gerade noch einmal nachgeschaut, nutze Chrome selbst nicht... Erst ab Chrome 45 werden DH-Parameter von mindestens 1024bit gefordert, dann wäre das " < " zumindest neu (und die Diskussion zu 1024bit läuft noch - eventuell soll wohl zugunsten ECDHE verzichtet werden). Es stimmt zwar, dass in der Definition von ssdnv keine Export-Ciphren ausgeschlossen waren, aber ob das zu dieser Meldung führt, wenn die irgendwo unten in der Liste stehen, weiß ich nicht, ausgewählt war die wohl eher nicht, wenn ganz oben die ECDH-Suite stand.

 

[jahlives]

nö ich meinte schon >=1024
Dass kleinere DH Parameter verweigert werden, ist mir als eingefleischter Chromeianer sehr bewusst ;-)
Es ist den Browsern egal ob vor Export noch was kommt. Wird Export angeboten sollte die Verbindung verweigert werden, denn eine Downgrade Attacke via MitM auf Export wäre dann möglich. Und da Export in diesem Fall nicht explizit ausgeschlossen war hat sich Chrome ganz pflichtbewusst und korrekt quergelegt.
Das Problem bei ssdnv dürfte ein häufiges Missverständnis sein: zwar beinhaltet LOW sehr wohl 56 und 40 bit Verschlüsselungen, ABER Exportchiphren sind explizit davon ausgenommen!

LOW
"low" encryption cipher suites, currently those using 64 or 56 bit encryption algorithms but excluding export cipher suites.

 

[Frogman]

...Es ist den Browsern egal ob vor Export noch was kommt. Wird Export angeboten sollte die Verbindung verweigert werden, denn eine Downgrade Attacke via MitM auf Export wäre dann möglich.

Ok, das stimmt, dann wird das wohl der Grund für die Meldung gewesen sein.. Allerdings ist bei ssdnvv sicher keine Export-Cipher verwendet worden, wie Du oben in Erwägung gezogen hattest