Perfect Forward Secrecy - Synology DS?

[Frogman]

Gut, das hab ich glaub ich jetzt verstanden. Allerdings ist ECDH der Kategoriename in mod_ssl für die ECDHE Chiphren - heißt: Da ich nicht die einzelnen Chiphren benenne, sondern Kategorien lande ich dennoch bei ECDHE und damit bei FS. ...

Sagen wir so - Du landest auch bei ECDHE mit FS. Denn daneben sind ebenfalls die ECDH enthalten, und die ohne FS (gib einfach mal auf der Konsole ein openssl ciphers -V ECDH ein). Wenn also der Gegenüber herunterhandelt, weil er vorgibt, kein FS zu können/haben, dann hast Du auch kein FS.
Aus diesem Grund ist es besser - wie jahlives oben ja schon erwähnte - die Ciphern explizit aufzulisten.

Und zu Deiner Frage der Schlüssellängen (also nix größer als 1024bit): gerade dafür sind die elliptischen Kurven gut. DH basiert wie viele andere Algorithmen auch auf der Berechnung diskreter Logarithmen auf einem endlichen Körper - was mathematisch ähnlich dem Faktorisieren ganzer Zahlen ein viel einfacheres Problem darstellt als die diskreten Logarithmen auf Punkten einer elliptischen Kurve. Und gerade letzteres wird bei den ECDHE (und auch ECDH) genutzt. Weil die aber immens schwerer zu berechnen sind, reichen hier für das gleiche Sicherheitsniveau erheblich kürzere Schlüssel (im Vergleich bspw. zu einem 1024bit RSA-Standardschlüssel reicht schon ein 160bit-Schlüssel bei Verwendung von EC).

 

[jahlives]

ssllabs gibt beim Test dieser Ciphren auch immer die Stärke in RSA an

[TABLE="class: reportTable, width: 670"]
[TR="class: tableRow"]
[TD="class: tableLeft"]TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028) ECDH 256 bits (eq. 3072 bits RSA) FS

[/TD]
[/TR]
[/TABLE]

 

[Thruhiker]

OK soweit, aber wenn jemand meinen privaten Schlüssel hat kann er auch Diffie-Hellman per MitM belauschen, nur im Nachhinein kann er eine bereits vorher aufgezeichnete Kommunikation nicht entschlüsseln.

er kann mitlauschen, aber nicht mitlesen ;-) Dann gibt es keinen Klartext ohne die temporären Schlüssel. Und die bekommt man nicht durch Lauschen an Leitungen.

Ne Wikipedia lügt nicht Es steht aber auch ganz klar, dass man Datenpakete verändern können muss. Das geht aber nur wenn man den Schlüssel hat. Darum wenn du so den DH-Exchange angreifen willst, musst du die Verschlüsselung durch den Public/Private Key bereits geknackt haben. Wenn du verschlüsselte Pakete änderst ohne sie vorher entschlüsselt zu haben produzierst du nur Datenschrott

Ja, aber wir haben doch da grad darüber geredet das jemand im Besitz des privaten Schlüssels wär.
Wenn er es nicht ist hat er auch viel Spaß mit der "regulären" Verschlüsselung. Erst wenn er den privaten Schlüssel hat wird es einfach, dann aber auch rückwirkend. Und davor, nur davor schützt PFS, vor der Rückwirkenden entschlüsselung mit Hilfe des privaten Schlüssels, oder?
Denn wenn er ihn hat kann er per MitM dennoch mitlesen.

Sagen wir so - Du landest auch bei ECDHE mit FS. Denn daneben sind ebenfalls die ECDH enthalten, und die ohne FS (gib einfach mal auf der Konsole ein openssl ciphers -V ECDH ein). Wenn also der Gegenüber herunterhandelt, weil er vorgibt, kein FS zu können/haben, dann hast Du auch kein FS.
Aus diesem Grund ist es besser - wie jahlives oben ja schon erwähnte - die Ciphern explizit aufzulisten.

Und zu Deiner Frage der Schlüssellängen (also nix größer als 1024bit): gerade dafür sind die elliptischen Kurven gut. DH basiert wie viele andere Algorithmen auch auf der Berechnung diskreter Logarithmen auf einem endlichen Körper - was mathematisch ähnlich dem Faktorisieren ganzer Zahlen ein viel einfacheres Problem darstellt als die diskreten Logarithmen auf Punkten einer elliptischen Kurve. Und gerade letzteres wird bei den ECDHE (und auch ECDH) genutzt. Weil die aber immens schwerer zu berechnen sind, reichen hier für das gleiche Sicherheitsniveau erheblich kürzere Schlüssel (im Vergleich bspw. zu einem 1024bit RSA-Standardschlüssel reicht schon ein 160bit-Schlüssel bei Verwendung von EC).

Wenn ich als Kategorie ECDH eingebe (in der von mir gewählten Kombination) erhalte ich als nur ECDHE-Ciphren, jedenfalls wenn man den Server nach den verfügbaren Ciphren fragt...

DHE benutzt aber eben keine EC, nur ECDHE benutzt diese, deshalb hab ich ja geschrieben, eigendlich können wir nur ECDHE benutzen.
DHE erzeugt bei Apache 2.2 einen Schlüssel der 1024Bit RSA entspricht und damit recht kurz ist.

Über ECDHE mach ich mir vorerst keine Sorgen.

 

[Frogman]

...DHE benutzt aber eben keine EC, nur ECDHE benutzt diese, deshalb hab ich ja geschrieben, eigendlich können wir nur ECDHE benutzen...

Na eben das hast Du nicht geschrieben - wenn ich Deinen Blick nochmal auf Deinen Post #51 und mein Zitat #53 lenken darf

...Wenn ich als Kategorie ECDH eingebe (in der von mir gewählten Kombination) erhalte ich als nur ECDHE-Ciphren, jedenfalls wenn man den Server nach den verfügbaren Ciphren fragt...

Und auch das stimmt nicht - Deine Auswahl liefert ein

openssl ciphers -V ECDH:DH:HIGH:MEDIUM:!RC4:!aNULL:!eNULL:!LOW:!DES:! 3DES
          0xC0,0x12 - ECDHE-RSA-DES-CBC3-SHA  SSLv3 Kx=ECDH     Au=RSA  Enc=3DES(168) Mac=SHA1
          0xC0,0x08 - ECDHE-ECDSA-DES-CBC3-SHA SSLv3 Kx=ECDH     Au=ECDSA Enc=3DES(168) Mac=SHA1
          0xC0,0x1C - SRP-DSS-3DES-EDE-CBC-SHA SSLv3 Kx=SRP      Au=DSS  Enc=3DES(168) Mac=SHA1
          0xC0,0x1B - SRP-RSA-3DES-EDE-CBC-SHA SSLv3 Kx=SRP      Au=RSA  Enc=3DES(168) Mac=SHA1
          0x00,0x16 - EDH-RSA-DES-CBC3-SHA    SSLv3 Kx=DH       Au=RSA  Enc=3DES(168) Mac=SHA1
          0x00,0x13 - EDH-DSS-DES-CBC3-SHA    SSLv3 Kx=DH       Au=DSS  Enc=3DES(168) Mac=SHA1
          0xC0,0x17 - AECDH-DES-CBC3-SHA      SSLv3 Kx=ECDH     Au=None Enc=3DES(168) Mac=SHA1
          0xC0,0x1A - SRP-3DES-EDE-CBC-SHA    SSLv3 Kx=SRP      Au=None Enc=3DES(168) Mac=SHA1
          0x00,0x1B - ADH-DES-CBC3-SHA        SSLv3 Kx=DH       Au=None Enc=3DES(168) Mac=SHA1
          0xC0,0x0D - ECDH-RSA-DES-CBC3-SHA   SSLv3 Kx=ECDH/RSA Au=ECDH Enc=3DES(168) Mac=SHA1
          0xC0,0x03 - ECDH-ECDSA-DES-CBC3-SHA SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=3DES(168) Mac=SHA1
          0x00,0x0A - DES-CBC3-SHA            SSLv3 Kx=RSA      Au=RSA  Enc=3DES(168) Mac=SHA1
          0x07,0x00,0xC0 - DES-CBC3-MD5            SSLv2 Kx=RSA      Au=RSA  Enc=3DES(168) Mac=MD5
          0x00,0x8B - PSK-3DES-EDE-CBC-SHA    SSLv3 Kx=PSK      Au=PSK  Enc=3DES(168) Mac=SHA1

inklusive ECDH!

 

[Thruhiker]

Na eben das hast Du nicht geschrieben - wenn ich Deinen Blick nochmal auf Deinen Post #51 und mein Zitat #53 lenken darf

Ich dachte wir wareun uns einig, dass ich aus Unwissenheit ECDH und ECDHE gleich gesetzt habe.

Aber ich hab eindeutig davon geschrieben, dass DH (meinte DHE), auf der DS nur 1024Bit unterstützt


Danke nebenbei, ich glaub ich komm der Sache näher

 

[Frogman]

Ich dachte wir wareun uns einig, dass ich aus Unwissenheit ECDH und ECDHE gleich gesetzt habe.

Aber ich hab eindeutig davon geschrieben, dass DH (meinte DHE), auf der DS nur 1024Bit unterstützt

Das mit dem 'einig sein über den Irrtum' ist mir dann wohl irgendwie entgangen, ich find's jedenfalls nicht... und "eindeutig" ist gut, wenn Du etwas anderes meinst als Du schreibst
Anyway, wie oben ja bereits gesagt, das "E" macht einen gehörigen Unterschied.
Und wenn Du eben nur Kategorien nutzt, gibt es auch ECDH ohne "E" (wie ich zuvor im Post #64 aufgelistet habe), und das eben ohne PFS!

Und als Anmerkung: wenn Du PFS nutzt, dann macht auch die Beschränkung auf einen 1024bit-DH-Schlüssel nicht wirklich etwas aus, weil Du den in Echtzeit ohnehin in den nächsten 100 Jahren nicht entschlüsseln kannst.

 

[drago]

Ab der DSM Version 4.2 sind RSA Verschlüsselungen bis zu 4096 bit möglich.

 

[Frogman]

Ab der DSM Version 4.2 sind RSA Verschlüsselungen bis zu 4096 bit möglich.

Das ist nicht ganz richtig - es sind Schlüssellängen bis zu 4096 bit möglich. Doch darum geht es hier nicht, sondern um die Länge der benutzten Verschlüsselung bspw. des Https-Servers.
Auch wenn ein längerer privater Schlüssel vorliegt, kann dieser bei der Nutzung im Webserver abhängig von der verwendeten Cypher verkürzt werden, d.h. der Apache verwendet dann nur einen kürzeren Schlüssel für die Verschlüsselung. Im Falle eines DHE-Keys beträgt die Länge derzeit hardcodiert nur 512 oder 1024 bit, auch wenn der RSA-Key 2048 oder gar 4096 bit hat. Für den Apache 2.4 gibt es einen Patch, der die DH-Parameter auch auf 2024 bit konfigurierbar macht, doch leider läuft der 2.4 noch nicht auf der DS...
@jahlives: da sind wir jetzt wieder bei Godot...

 

[Foniker]

ECDHE bei WebDAV - wie erkennen?

....Um den [Man-in-the-Middle-]Angriff auszuschließen, könntest Du bspw. auch die Fingerprints der Zertifikate vergleichen.

Hallo Frogman, diese Sache interessiert mich in folgendem Zusammenhang: Beim Aufruf meiner per https verfügbaren Diskstation prüfe ich regelmäßig mein Zertifikat im Browser auf das ausgehandelte Protokoll (ECDHE aktiv?) sowie die korrekten Fingerprints (zur Erkennung eines MitM-Angriffs).

Wie aber mache ich das bei einer WebDAV-Verbindung? Bei W7 läuft das Einhängen eines Laufwerkbuchstabens z.B. per NET USE oder auch in der Shell ohne irgendwelche Rückmeldungen, die Rückschlüsse darauf zulassen, wie denn die Verbindung nun zu Stande kam. Bei Zertifikatsfehlern kommen bloß nichtssagende Meldungen, und die Verbindung wird abgelehnt.

Aber auch unter OSX 10.6 ist mir nicht bekannt, wo man da mit einer Fingerprintprüfung ansetzen könnte.

Wäre nett, wenn mir jemand sagen kann, wie das gehen könnte, eine WebDAV-Verbindung nur mit einem bestimmten Zertifikat zuzulassen und die Aushandlung von ECDHE zu erzwingen bzw. wenigstens den Status zu kontrollieren.

DANKE!

 

[jahlives]

Was bringt das prüfen auf Fingerprints im Fall der super netten Heartbeat Lücke? Der Schlüssel wurde geleaked, das Cert gibt es gratis beim Server Somit stimmen dann auch die Fingerprints
Ich will damit nicht sagen, man soll das ned prüfen. Nur sich darauf zu verlassen kann böse ins Auge gehen
Als Bsp: jemand hat über Heartbeat (oder was auch immer sonst noch für Lücken vorhanden sind) den Schlüssel und das Cert und baut einen bösen Server auf. Fingerabdrücke stimmen. Das einzige Kriterium wäre nur noch die IP resp der Hostname

 

[Foniker]

ECDHE und Fingerprintprüfung bei WebDAV - wie?

Was bringt das prüfen auf Fingerprints im Fall der super netten Heartbeat Lücke?

Sorry, jahlives, das ist nicht mein Thema. Heartbleed wurde gepatcht und Zertifikat danach erneuert, ebenso die Passwörter. Es geht mir nicht um Keys, die kompromittiert sind. Man in the Middle benötigt keinen privaten Key. Dieser Angriff zeigt ein gefälschtes aber beglaubigtes Zertifikat vor, das einen falschen Fingerprint hat. Das gilt es zu erkennen unter WebDAV.

 

[Frogman]

...Wie aber mache ich das bei einer WebDAV-Verbindung? Bei W7 läuft das Einhängen eines Laufwerkbuchstabens z.B. per NET USE oder auch in der Shell ohne irgendwelche Rückmeldungen, die Rückschlüsse darauf zulassen, wie denn die Verbindung nun zu Stande kam. ...

Automatisiert kenne ich da auch nichts, da müßtest Du vermutlich improvisieren. Beispielsweise per Skript das Zertifikat herunterladen mit einem

openssl s_client -connect IP-Adresse:443 | sed -ne '/BEGIN CERT/,/END CERT/p'

Auf das heruntergeladene Zertifikat musst Du dann den entsprechenden Fingerprint ausrechnen, also bspw. den SHA1 mit einem

openssl x509 -noout -fingerprint -sha1 -in <zertifikatsname.crt>

, um diesen dann mit einem erwarteten Fingerprint zu vergleichen.
Abhängig von dem Ergebnis kannst Du dann das Laufwerk einbinden oder abbrechen. Ist schon etwas Fummelei...

 

[jahlives]

Man in the Middle benötigt keinen privaten Key.

ein "perfekter" ManInTheMiddle schon. Sonst kannst du den immer anhand der Fingerprints erkennen ;-)

 

[Frogman]

...und die Aushandlung von ECDHE zu erzwingen

Auch so, das kannst Du natürlich dadurch erreichen, dass Du nur die ECDHE anbietest (und dazu eventuell aus Gründen der Kompatibilität die ganzen DHE-RSA, welche zwar round about 5mal langsamer sind, aber eben auch PFS bieten). Details zum Einschränken auf bestimmte Ciphern findest Du ja weiter oben.

PS: Hat zwar mit Deinem Problem nicht zu tun - aber der dovecot auf der DS verwendet übrigens ab einer openssl > 1.0 von Haus aus standardmäßig Ciphern mit PFS, d.h. in diesem Fall DHE, ab v2.2.6 dann auch ECDHE.

 

[Foniker]

...das kannst Du natürlich dadurch erreichen, dass Du nur die ECDHE anbietest ......... Details zum Einschränken auf bestimmte Ciphern findest Du ja weiter oben.

Hmmm.. gibt es denn schon Erfahrungen, ob WebDAV unter W7 das überhaupt kann? Bevor ich mich jetzt verkünstele und am Ende wird die Verbindung einfach nicht aufgebaut.

..ab einer openssl > 1.0 von Haus aus standardmäßig Ciphern mit PFS, d.h. in diesem Fall DHE, ab v2.2.6 dann auch ECDHE.

Unter W7 mit FF28 bekomme ich bei dem DSM5.0 V2 schon eine ECDHE-Verbindung, auch ohne Modifizierungen:


Danke schon mal für die Reaktionen!

 

[Frogman]

Hmmm.. gibt es denn schon Erfahrungen, ob WebDAV unter W7 das überhaupt kann? Bevor ich mich jetzt verkünstele und am Ende wird die Verbindung einfach nicht aufgebaut.

WebDAV hängt in Bezug auf SSL/TLS-Support ja wie der IE am Schannel-Paket (Secure Channel). Das unterstützt für Windows 7 bereits seit Jahren TLS 1.2 (was Du in den Internetoptionen aktivieren kannst) mit den darin verfügbaren Cipher-Suites, u.a. eben auch ECDHE.

 

[Waldschrat]

Ausgesperrt

Hallo liebe Spezialisten.

Ich brauche bitte Hilfe.
Ich habe nach Vorgaben von frogman die Dateien
httpd-alt-port-ssl-setting.conf
sowie
httpd-ssl.conf-common
geändert indem ich die Zeile mit "SSLCipherSuite" ersetzt habe mit

SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-ECDSA-AES256-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-GCM-SHA384:DHE-DSS-AES256-SHA256:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-SHA256:DHE-DSS-AES128-GCM-SHA256:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA:ECDH-RSA-AES256-GCM-SHA384:ECDH-ECDSA-AES256-GCM-SHA384:ECDH-RSA-AES256-SHA384:ECDH-ECDSA-AES256-SHA384:ECDH-RSA-AES128-GCM-SHA256:ECDH-ECDSA-AES128-GCM-SHA256:ECDH-RSA-AES128-SHA256:ECDH-ECDSA-AES128-SHA256:ECDH-RSA-AES256-SHA:ECDH-ECDSA-AES256-SHA:ECDH-RSA-AES128-SHA:ECDH-ECDSA-AES128-SHA:AES256-GCM-SHA384:AES256-SHA256:AES256-SHASSLProtocol all -SSLv2

Nun kann ich ausser der DSM Systemoberfläche keine Webseite mehr erreichen (Owncloud, Piwik, WordPress, Openfire etc.).
Als ich den Apache Webserver mit "httpd -k restart" neustarten wollte hat der gemeckert, dass die Datei "httpd.conf" fehlen würde.
Die habe ich durch "cp httpd.conf-user httpd.conf" wieder hergestellt. Nun lässt sich der Apache zwar wieder starten und stoppen leider nur ohne Erfolg was den Aufruf von Webseiten betrifft.

Leider weiss ich den ursprünglichen Inhalt der Zeilen nicht mehr <schäm>.
Könnt Ihr mir bitte helfen wieder Zugriff zu bekommen?

Ich habe eine DS213+ mit DSM 5.0

 

[Mike0185]

Hätte dir jetzt gern den originalen Inhalt der SSLCipherSuite hier gepostet, aber ich finde den Pfad bei mir nicht zu den dateien... wo liegen die denn bei DSM 5?

 

[Waldschrat]

Vielen Dank!
Unter DSM 5 liegen die Dateien unter dem Pfad
/etc/httpd/conf/extra

 

[Mike0185]

Sieht bei mir unter DSM 5 - 4482 (!) so aus:

httpd-alt-port-ssl-setting.conf

SSLEngine on

SSLCipherSuite HIGH:MEDIUM
SSLProtocol all -SSLv2
SSLCertificateFile /usr/syno/etc/ssl/ssl.crt/server.crt
SSLCertificateKeyFile /usr/syno/etc/ssl/ssl.key/server.key
SSLCertificateChainFile /usr/syno/etc/ssl/ssl.intercrt/server-ca.crt

httpd-ssl.conf-common

SSLRandomSeed startup builtin
SSLRandomSeed connect builtin

AddType application/x-x509-ca-cert  .crt
AddType application/x-pkcs7-crl     .crl

SSLPassPhraseDialog  builtin

SSLSessionCache         "shmcb:/run/httpd/ssl_scache(512000)"
SSLSessionCacheTimeout  300

SSLMutex "file:/run/httpd/ssl_mutex"

SSLCipherSuite HIGH:!EXPORT:!eNULL:!aNULL:!DES:!RC4:!RC2:!IDEA:!SEED:!CAMELLIA:+RSA:+DSA+DH:+AES:+SHA1:+MD5
SSLProtocol all -SSLv2

SSLCertificateFile      "/usr/syno/etc/ssl/ssl.crt/server.crt"
SSLCertificateKeyFile   "/usr/syno/etc/ssl/ssl.key/server.key"

SSLCertificateChainFile /usr/syno/etc/ssl/ssl.intercrt/server-ca.crt

#SSLCACertificatePath "/etc/httpd/conf/ssl.crt"
#SSLCACertificateFile "/etc/httpd/conf/ssl.crt/ca-bundle.crt"

#SSLCARevocationPath "/etc/httpd/conf/ssl.crl"
#SSLCARevocationFile "/etc/httpd/conf/ssl.crl/ca-bundle.crl"