Perfect Forward Secrecy - Synology DS?

[drago]

Dem kann ich mich nur anschließen. /etc/httpd/conf/httpd.conf noch ergänzt und jetzt auch ein A+

Danke
Peter

Den Pfad gibt es bei mir garnicht, ich habe es unter /usr/syno/apache/conf/extra/httpd-alt-port-ssl-setting.conf sowie
/usr/syno/apache/conf/extra/httpd-ssl.conf-common eingepflegt. Funktioniert einwandfrei.

 

[Frogman]

Den Pfad gibt es bei mir garnicht, ich habe es unter /usr/syno/apache/conf/extra/httpd-alt-port-ssl-setting.conf sowie
/usr/syno/apache/conf/extra/httpd-ssl.conf-common eingepflegt.

Das liegt daran, dass im DSM-5.0 die Konfigs nun unter /etc/httpd/conf liegen und nicht mehr (wie bei Dir unter DSM <= 4.3) unter /usr/syno/apache/conf

Aber die Dateien, wo Du das einträgst, sind schon ok - da liegen auch alle andere SSL-bezogenen Einstellungen.

 

[drago]

Alles klar.

Ihr müsst die Modifikationen für die Syno Anwender etwas nachvollziehbarer erläutern, z.B. um welche DSM Version es sich dabei handelt, wo der Code entsprechend eingepflegt wird.

So erspart man sich die ständigen nachfragen.

 

[Frogman]

Ihr müsst die Modifikationen für die Syno Anwender etwas nachvollziehbarer erläutern, z.B. um welche DSM Version es sich dabei handelt, wo der Code entsprechend eingepflegt wird.

Für einen Wiki-Eintrag würde ich Dir ja zustimmen - doch nicht unbedingt hier im Forum. Da es sich hier nicht um Standardeinstellungen handelt, sollte ein Interessierter schon auch wissen, was er tut - und auch in der Lage und willens sein, sich über notwendige Details selbst zu informieren.
Und ansonsten - wie Du oben siehst - wird auf Nachfrage immer auch gerne geantwortet

 

[Thruhiker]

Qually SSL Labs A+

Also bei mir hat die Änderung (Header add Strict-Transport-Security "max-age=15768000") in "/etc/httpd/conf/httpd.conf" auch funktioniert (Danke!).
Nach einem Neustart der DS ist die Zeile aber weg.
Hab die Zeile jetzt in "httpd.conf-user" und "httpd.conf-sys" eingefügt, da bleibt sie.
__________________

Für Forward Secrecy muss man nebenbei nicht unbedingt die einzelnen Suiten aufführen, zumal diese sich bei einem openssl update teilweise ändern, es reicht die folgende Variante in /etc/httpd/conf/extra/httpd-ssl.conf-common:

SSLHonorCipherOrder on
SSLCipherSuite ECDHH:HIGH:MEDIUM:!RC4:!aNULL:!eNULL:!LOW:!DES:!3DES

Wenn einem die leider durch Apache 2.2 auf 1024Bit begrenzte DH Schlüssellänge nicht reicht kann man da ebenfalls ein ! vorsetzen. Führt zu 90% bei "Key Exchange", aber 3 alten Browsern weniger die FS unterstützen.

 

[jahlives]

ich würde die Ciphren explizit definieren und keine Kategorien verwenden. Nur so kannst du die genaue Reihenfolge festlegen. Auch bietest du sonst zu viele Ciphren an welche nicht PFS können. Das könnte man dann theoretisch mit einem MitM-Angriff ausnutzen und die genutzte Chiphre runterhandeln

 

[Thruhiker]

Mit der genauen Reihenfolge hast du sicher recht. Ich sehe allerdings nicht, dass ich mit den Kategorien, wie ich sie aufgeführt habe, "schwache" Ciphren zulassen würde, insofern kann man die DS nicht besonders weit herunterhandeln. Und zum MitM-Angriff: ist der nicht generell die größte Schwachstelle im Diffie-Hellman?

Wenn man möchte kann man durch die Kategorisierung ja auch einfach nur FS Ciphren zulassen:
SSLHonorCipherOrder on
SSLCipherSuite ECDHH:HIGH:MEDIUM:!RC4:!aNULL:!eNULL:!LOW:!DES:!3DES:!kRSA

Mann muss halt wie mit der expliziten Bennung darauf achten was man genau zulässt und was man ausschließt.

 

[jahlives]

Ich sehe allerdings nicht, dass ich mit den Kategorien, wie ich sie aufgeführt habe, "schwache" Ciphren zulassen würde, insofern kann man die DS nicht besonders weit herunterhandeln.

ich habe nicht gesagt "schwach" sondern "nicht PFS können"
Man (NSA und Co&Kg) könnte dann deine Verbindung zum Server mittels MitM auf eine No-PFS-Chiphre runterhandeln

 

[Thruhiker]

? Du wirst sicher besser in der Materie stecken als ich. Ich dachte zur Verhinderung eines MitM habe ich meinen privaten Schlüssel sowie das Zertifikat? Sonst lässt sich PFS damit doch generell brechen?

 

[jahlives]

Das SSL Protokoll lässt es zu, dass sich Server und Client auf eine Ciphre einigen. Wenn der Server zwar priorisiert PFS Chiphren bevorzugt, aber noch viele andere Ciphren (auch ohne PFS) bietet, dann kannst du nicht sicher sein, dass nur PFS verwendet wird. Der Client könnte ja immer sagen "kann ich ned gibt mal die nächste". In deinem Fall bis zu Ciphren von MEDIUM.
Gerade in Zeiten von Heartbleed wo man davon ausgehen muss, dass auch private Schlüssel kompromittiert worden sein könnten, sollte man mit Non-PFS aufpassen.
Ein theoretisches Beispiel: dein Server Key wurde kompromittiert. Du baust eine Verbindung zum Server (https) auf. Der Bösewicht fängt die Pakete ab und kann sie lesen, weil er ja den Schlüssel hat. Er kann sie manipulieren z.B. "hei ich kann nur diese Ciphren" und dann an den Server weiterschicken. So könnte man deine Verbindung MitM-like auf no-PFS runterhandeln.

Wie gesagt eher theoretisch, aber wäre mit entsprechendem Aufwand sicher irgendwie möglich. Bietet dein Server jedoch keine no-PFS Ciphren an, sind dem Runterhandeln enge Grenzen gesteckt. Das Prinzip an PFS ist, dass für die eigentlichen Übertragung der Daten ein weiterer temporärer Schlüssel ausgehandelt wird. Der geht aber NIEMALS über die Leitung, auf dieses Geheimnis können sich Server und Client einigen ohne es übertragen zu müssen. Die einzigen Infos welche Server und Client dafür austauschen müssen sind NICHT geheim. Das ist die Eleganz des Diffie-Hellman Schlüsseltausches
Erst mit "nur PFS Chiphren" kannst du (recht) sicher sein, dass du nichtmal auf das Stehlen der privaten Schlüssel anfällig bist

 

[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. Und wenn man es mit einem Rechenzentrum drauf anlegt ist ein DH mit 1024Bit (leider ist ja mit Apache 2.2 kein DH2048 möglich) doch eigendlich einfacher zu knacken als ein MEDIUM - vorrausgesetzt man hat den privaten Schlüssel nicht, oder liege ich da falsch?
Naja bleibt eigendlich nur Lediglich ECDH übrig und damit kickt man ja dann doch ein paar mehr Browser raus.
Schlüssel und PWs hab ich natürlich getauscht.

 

[Frogman]

...Wie gesagt eher theoretisch, aber wäre mit entsprechendem Aufwand sicher irgendwie möglich. ...

Stichwort SSL-Proxy... ist auch nicht ganz so selten, wie man sich wünschen würde, gerade weil ja heutzutage damit zu rechnen ist, dass Unberechtigte mit einer Root-CA kooperieren.

 

[Frogman]

Naja bleibt eigendlich nur Lediglich ECDH übrig und damit kickt man ja dann doch ein paar mehr Browser raus....

Bietet aber kein PFS

 

[Thruhiker]

Biete aber kein PFS

Warum soll Elliptic curve Diffie–Hellman kein PFS sein?

 

[Thruhiker]

[...] gerade weil ja heutzutage damit zu rechnen ist, dass Unberechtigte mit einer Root-CA kooperieren.

Jetzt wirds verwirrend, die CA hat doch meinen privaten Schlüssel nie gesehen ...
Irgendwo hängt es bei mir :/

 

[Frogman]

Warum soll Elliptic curve Diffie–Hellman kein PFS sein?

Weil es auf das "E" ankommt, was für Ephemeral steht. Das bedeutet, dass Du PFS nur für die ephemeren Varianten bekommst, das heißt DHE und ECDHE.
Bei ECDH werden lediglich elliptische Kurven bei der Verschlüsselung verwendet, was einen Performancevorteil liefert. Der verwendete Schlüssel ist aber fix (bei den ephemeren Varianten wird ja gerade der immer erneuert).

 

[Frogman]

Jetzt wirds verwirrend, die CA hat doch meinen privaten Schlüssel nie gesehen ...

Bei der SSL-Man-in-the-Middle-Attacke geht es ja nur darum, dass der Angreifer sich mit einem SSL-Proxy dazwischen setzt mit einem Zertifikat, was von einer Root-CA ebenfalls auf den Server ausgestellt wurde. Damit ist er in der Lage, bspw. die Kommunikationsparameter zu manipulieren (zB. über das Herunterhandeln der Cipher), zum anderen kann er auch Inhalte mitlesen und verändern. Um den Angriff auszuschließen, könntest Du bspw. auch die Fingerprints der Zertifikate vergleichen.

 

[jahlives]

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.

Und wenn man es mit einem Rechenzentrum drauf anlegt ist ein DH mit 1024Bit (leider ist ja mit Apache 2.2 kein DH2048 möglich) doch eigendlich einfacher zu knacken als ein MEDIUM - vorrausgesetzt man hat den privaten Schlüssel nicht, oder liege ich da falsch?

ein Angriff auf DH setzt voraus, dass man den privaten Schlüssel schon hat. Sonst wird man keine Chance haben

 

[Thruhiker]

Weil es auf das "E" ankommt, was für Ephemeral steht. Das bedeutet, dass Du PFS nur für die ephemeren Varianten bekommst, das heißt DHE und ECDHE.
Bei ECDH werden lediglich elliptische Kurven bei der Verschlüsselung verwendet, was einen Performancevorteil liefert. Der verwendete Schlüssel ist aber fix (bei den ephemeren Varianten wird ja gerade der immer erneuert).

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. Wie auch bei Qualys angezeigt.

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.

Dann lügt Wikipedia
Da wird beschrieben wie durch einen MitM die kommunikation mitgelesen werden kann. Oder ich habs falsch verstanden.

und: "Someone with access to the server's private key can, of course, perform an active man in the middle attack and impersonate the server. However, they can do that only when the communication is taking place." 1)

ein Angriff auf DH setzt voraus, dass man den privaten Schlüssel schon hat. Sonst wird man keine Chance haben

Nein, ein Angriff setzt nicht den Key vorraus, sonst könnte man auch die anderen Verschlüsselungen nur mit dem privaten Schlüssel knacken. Es ist nur ein imenser Rechenaufwand. Insofern ist es wichtig wie lang der Schlüssel ist.

"It's also sometimes called perfect forward secrecy, but, because it is possible to decrypt the communication by breaking the session keys, it's clearly not perfect." 1)

Entschuldigt, dass ich hier anscheinend arg auf der Leitung stehe.
Wenn jemand mir vorgaukelt wer wäre der Server den ich ansprechen will und ich kriege es nicht mit (selbst ein CA Zertifikat) dann übermittle ich ihm ja beim Einloggen mein Passwort und damit ist es alles essig weil dann kann er ja selbst in meinen Server.
Wenn er das PW nicht lesen kann weil es korrekt für meinen Server verschlüsselt wurde hat er wenig Chance mitzulesen bzw meine bereits verschlüsselte Anfrage zu verändern.

1) Siehe: Qualys

 

[jahlives]

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