Logjam-Attacke: Kompromittierung von SSL-Verschlüsselung

  • Ab sofort steht euch hier im Forum die neue Add-on Verwaltung zur Verfügung – eine zentrale Plattform für alles rund um Erweiterungen und Add-ons für den DSM.

    Damit haben wir einen Ort, an dem Lösungen von Nutzern mit der Community geteilt werden können. Über die Team Funktion können Projekte auch gemeinsam gepflegt werden.

    Was die Add-on Verwaltung kann und wie es funktioniert findet Ihr hier

    Hier geht es zu den Add-ons

Status
Für weitere Antworten geschlossen.

Frogman

Benutzer
Registriert
01. Sep. 2012
Beiträge
17.485
Reaktionspunkte
9
Punkte
414
Und wieder einmal zieht eine Lücke Kreise (Logjam-Attacke), die SSL-verschlüsselte Kommunikation betrifft. Aktuell geht es um eine Schwäche in dem Austausch der Schlüssel zu Beginn der symmetrisch verschlüsselten Kommunikation. Das dabei verwendete Verfahren nennt man nach den beiden Entdeckern Diffie-Hellman. Die Schwäche geht auf Zeiten zurück, als die USA den Export von starker Kryptografie verboten hatte, so dass dafür extra eine Klasse von EXPORT-Chiffren geschaffen wurde, die in ihrer Schlüsseltiefe beschränkt waren. Hier sind das also DH-Gruppen mit 512 Bit, auf die man unter gewissen Umständen heruntergestuft werden kann, so dass eine vermeintlich sichere SSL-Kommunikation in Minutenschnelle dekodiert werden kann.

Um dem zu umgehen, gibt es - neben Updates für die verwendeten Browser, Emailprogramme usw. - für den Betrieb eines Servers mit SSL-Implementierung folgende 3 genannte Punkte:
  1. Serverseitiges Verbot von EXPORT-Chiffren durch einen Eintrag von !EXPORT in die Auflistung zugelassener Chiffren.
  2. Nutzung des DH-Schlüsseltauschs auf Basis elliptischer Kurven, das sind die Varianten ECDHE-...
  3. Verwendung einer neugenerierten exklusiven DH-Gruppe mit 2048 Bit.

Den ersten Punkt nimmt uns im Regelfall Synology schon ab, weil EXPORT-Chiffren per default ausgeschlossen sein sollten - falls nicht, ergänzt man das recht einfach in der Datei /etc/httpd/conf/extra/httpd-ssl.conf-cipher , indem eine Rangfolge von Chiffren definiert und dabei (am besten nur unter Verwendung der Gruppe HIGH) die Auswahl !EXPORT ergänzt wird:

Code:
SSLHonorCipherOrder on
SSLProtocol all -SSLv2 -SSLv3
SSLCipherSuite HIGH:[COLOR=#b22222]!EXPORT[/COLOR]:!eNULL:!aNULL:!DES:!RC4:!RC2:!MD5:!IDEA:!SEED:+AES128:+AES256:+CAMELLIA:!3DES:+kEECDH:+kRSA:!EDH:!aECDH:!aECDSA:!kECDHe:!SRP:!PSK
Die Auswahl oben ist diejenige, die ich aktuell verwende, sie kann aber natürlich nach eigenen Vorlieben angepasst werden.
Meine Auswahl priorisiert dann auch gleich die ECDHS-Chiffren, die Perfect Forward Secrecy (PFS) liefern und für die hier erwähnte Attacke nicht anfällig sind.

Der Punkt 3 erfordert dann etwas mehr Handarbeit - ist allerdings auch nicht unbedingt notwendig. Synology verwendet bereits eine DH-Gruppe mit 1024 Bit, bspw. auch im VPN Server, was aktuell keinen Anlass zur Sorge bereitet. Der Apache verwendet üblicherweise eine DH-Gruppe, die der Schlüssellänge entspricht, im Regelfall also mindestens 1024 Bit.
Wer hier nachlegen möchte, kann dort nachlesen. Übrigens kann man unter dem Link auch seinen Server im Hinblick auf die Schwäche prüfen.
 
Auf gut deutsch DSM 5.2 Update 1 ist nicht betroffen??? :o
 
Danke für die guten Tipps!
Es ist nicht für jeden machbar, dass hier geschriebene umzusetzen.
Kannst du das Synology schreiben, dass Synology einen DH key mit 2048 bit zukünftig generieren soll. Wird ECDHE schon verwendet? Wenn nein, dass auch Synology schreiben.
Ich bin leider in dem Thema nicht so tief drin, aber https://www.ssllabs.com/ssltest/ sieht auf meiner NAS (mit aktueller DSM 5.2) grauenhaft aus.
 
Auf gut deutsch DSM 5.2 Update 1 ist nicht betroffen??? :o
So pauschal ist das nicht zu sagen. Der bisher genutzte (ältere) Apache hat hier leider eine unangenehme Eigenschaften, dass er nämlich nicht 1024 Bit-Gruppen nutzt, wenn DHE zugelassen wird. Ich hab das jetzt noch nicht im Details mit der 5.2 angeschaut, doch da wird ja wohl abhängig vom Modell auch noch ein älterer Apache verwendet.
 
Danke für die guten Tipps!
Es ist nicht für jeden machbar, dass hier geschriebene umzusetzen.
Kannst du das Synology schreiben, dass Synology einen DH key mit 2048 bit zukünftig generieren soll. Wird ECDHE schon verwendet? Wenn nein, dass auch Synology schreiben.
Ich bin leider in dem Thema nicht so tief drin, aber https://www.ssllabs.com/ssltest/ sieht auf meiner NAS (mit aktueller DSM 5.2) grauenhaft aus.


Von mir auch nicht wirklich zu übersetzen! :-( vll ist es ja auch schon in Update 1 gefixt????

Hatte mit dem Update keine Probleme.....

Was ist denn diese "Willkommensnachricht" im Bereich "Login" für wen wird das anzeigt? Und was soll es bringen? Nicht das ich mich nicht darüber freuen würde das meine Synology so lieb zu mir ist.... ;):o :D
 
Kannst du das Synology schreiben, dass Synology einen DH key mit 2048 bit zukünftig generieren soll..
Ist schon gestern passiert :) - auch erneut mit der dringlichen Aufforderung, pauschal den Apache auf einen aktuelleren Stand zu heben (2.4.x).
Wird ECDHE schon verwendet? Wenn nein, dass auch Synology schreiben.
ECDHE sind ja in der OpennSSL-Implementierung enthalten, leider nicht priorisiert. Ich habe das bei mir angepaßt (und diese Variante auch an Synology vor Wochen empfohlen). Allein damit bekommst Du ein recht gutes Ergebnis im Servertest mit praktisch durchgängiger PFS, trotz weitgehender Kompatiblität.
 
@Frogman: wunderbar. habe ich auch schon vor mindestens 1 Jahr vorgeschlagen endlich auf Apache 2.4.x zu gehen. Leider noch nix passiert.
 
...(und diese Variante auch an Synology vor Wochen empfohlen).
Genauer gesagt habe ich Synology vorgeschlagen, neben einer guten Standardeinstellungen ein GUI-Tool zu ergänzen, mit dem man sich seine "Kompatiblität" bzw. gewünschten Verschlüsselungen zusammenklicken kann, ohne dass man mühsam auf der Konsole (ach, da haben wir ja wieder das Reizthema für die "Mausschieber" unter den Usern ;)) in den SSL-Konfigs herumwühlen muss. Angesichts der dynamischen Entwicklung von Sicherheitslücken und notwendigen Anpassungen an Verschlüsselungsoptionen sollte auch ein durchschnittlicher User seine DS vernünftig und intuitiv nach seinem Bedarf absichern können, ohne dass er Krypto-Handbücher wälzen muss.
 
So habe Synology jetzt auch geschrieben zu reagieren.
 
Good News! This site is safe from the Logjam attack. It supports ECDHE, and does not use DHE.

22-05-_2015_10-21-16.jpg

Ist das jetzt gut, oder schlecht :confused:
 
Na, wie soll man denn 'Good news' falsch verstehen? :D - ECDHE ist gut, allgemein ohnehin (wegen Forward Secrecy), aber auch im Speziellen auf die Logjam-Lücke. Am besten wäre es, wenn neben DHE auch solche Dinge wie RC4, SHA1 usw. ausgeschlossen sind, aber das ist dann schon auf hohem Niveau.
 
Da hast Du recht, aber Good News und dann eine Zeile darunter No und Not haben mich ein wenig verunsichert. Aber jetzt hast Du mich ja aufgeklärt. Danke Schön.
 
Allein an SHA1 nicht. Die Abstufung auf 'B' erfolgt - wie ja auch direkt geschrieben wird - wegen einer unvollständigen Zertifikatskette.
 
Status
Für weitere Antworten geschlossen.
 

Kaffeautomat

Wenn du das Forum hilfreich findest oder uns unterstützen möchtest, dann gib uns doch einfach einen Kaffee aus.

Als Dankeschön schalten wir deinen Account werbefrei.

:coffee:

Hier gehts zum Kaffeeautomat