Logjam Attack /weakness in Diffie-Hellman key exchange

Hallo,

obwohl in den letzten Patchleveln bei UCS dankenswerterweise schon generell auf veraltete “Export”-Verschlüsselungsverfahren verzichtet wird, und bei einem 1024er Key das Risiko nicht enorm hoch ist, möchte ich trotzdem mal nachfragen, ob der UCS im Auslieferungszustand ab Version 4.0-2 wie unter https://weakdh.org/sysadmin.html beschrieben vorkonfiguriert, bzw. ob dies überhaupt praktikabel umsetzbar (keine Überraschungen mit Abhängigkeiten) ist.

Ein kurzer Test eines UCS 4.0-2 bringt folgendes Ergebnis:


Mit freundlichen Grüßen,
TP

[quote=“The Preacher”]Hallo,

obwohl in den letzten Patchleveln bei UCS dankenswerterweise schon generell auf veraltete “Export”-Verschlüsselungsverfahren verzichtet wird, und bei einem 1024er Key das Risiko nicht enorm hoch ist, möchte ich trotzdem mal nachfragen, ob der UCS im Auslieferungszustand ab Version 4.0-2 wie unter https://weakdh.org/sysadmin.html beschrieben vorkonfiguriert, bzw. ob dies überhaupt praktikabel umsetzbar (keine Überraschungen mit Abhängigkeiten) ist.[/quote]

Hi Du Prediger,

Ich bin nicht Univention, glaube aber fast sicher das Dein Wunsch so nicht erfüllbar ist. Der Grund: Konfigurieren von DH-Parametern ist überhaupt erst ab Apache 2.4.7 möglich, ab 2.4.8 dann auch einigermaßen bequem als eigene Konfigurationsvariable. UCS 4.0-2 setzt ja auf Debian7 und damit auf Apache 2.2.x. Ich glaube wegen zu viel Querabhängigkeiten nicht das Univention einen Backport des 2.4 Apachen auf eine Debian7-Basis macht. Wir müssen also wohl auf die Debian8-Variante des UCS warten nehme ich mal ganz stark an.

Gegen Logjam kannst Du jetzt schon einiges machen. Der Austausch von DH-Parametern gegen eigene ist ja nur eine Komponente. Vorarbeit: Dank der Updates in errata.univention.de/ucs/4.0/103.html wegen [bug]37566[/bug] ist es jetzt möglich die verwendete ciphersuite festzulegen.

Bis vor einigen Tagen stand diese Variable bei mir auf folgenden Eintrag:

~# ucr get apache2/ssl/ciphersuite kEECDH+ECDSA:kEECDH:kEDH:HIGH:+SHA:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!DSS:!PSK:!SRP:!kECDH:!CAMELLIA:!RC4
…und natürlich ganz wichtig:

~# ucr get apache2/ssl/honorcipherorder On
sowie:

~# ucr search apache2/ssl/compression apache2/ssl/compression: <empty> If this option is enabled compression on the SSL level is enabled. If the variable is unset, compression is disabled. The use of SSL compression is discouraged for security reasons (CRIME protocol attack)
Damit sind folgende Ciphersuites supported vom Server:

ECDHE-RSA-AES256-GCM-SHA384 ECDHE-RSA-AES256-SHA384 ECDHE-RSA-AES256-SHA DHE-RSA-AES256-GCM-SHA384 DHE-RSA-AES256-SHA256 DHE-RSA-AES256-SHA AES256-GCM-SHA384 AES256-SHA256 AES256-SHA ECDHE-RSA-AES128-GCM-SHA256 ECDHE-RSA-AES128-SHA256 ECDHE-RSA-AES128-SHA DHE-RSA-AES128-GCM-SHA256 DHE-RSA-AES128-SHA256 DHE-RSA-AES128-SHA DHE-RSA-SEED-SHA AES128-GCM-SHA256 AES128-SHA256 AES128-SHA

Tja und dann kam Logjam… Das zugrundeliegende Problem bei Logjam ist vereinfacht die Möglichkeit einer Downgrade Attacke auf die “DHE-*” ciphers. Das ist insofern richtig blöde, weil diese bis vor kurzen wegen PF bevorzugt eingesetzt wurden. Aber Abhilfe ist bei UCS jetzt sehr einfach, Du musst die betroffenen schwachen Cipher einfach verbieten. Entweder als lange lange Liste, oder schlicht als “!EDH” zusammengefasst.

Das folgende Beispiel verhindert Logjam Attacken, ist copy&paste fähig, und muss als root auf dem Server ausgeführt werden: (einfach auf “ALLES AUSWÄHLEN” klicken und auf der Konsole einfügen)

[code]ucr set apache2/ssl/ciphersuite=‘kEECDH+ECDSA:kEECDH:kEDH:HIGH:+SHA:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!DSS:!PSK:!SRP:!kECDH:!CAMELLIA:!RC4:!EDH’
apache2ctl -t
service apache2 restart

[/code]

Danach noch den Apache neu starten.

~# service apache2 restart [ ok ] Restarting web server: apache2 ... waiting .

Mit dieser cipherliste unterstützt der Server noch folgende ciphers:

ECDHE-RSA-AES256-GCM-SHA384 ECDHE-RSA-AES256-SHA384 ECDHE-RSA-AES256-SHA AES256-GCM-SHA384 AES256-SHA256 AES256-SHA ECDHE-RSA-AES128-GCM-SHA256 ECDHE-RSA-AES128-SHA256 ECDHE-RSA-AES128-SHA AES128-GCM-SHA256 AES128-SHA256 AES128-SHA
Und natürlich ganz wichtig für das “gehobene Management”: Dein UCS-Server bekommt beim Test auf ssllabs.com/ssltest/ das beruhigende grüne “A” zurück, und der Test auf weakdh.org kommt im hübschen blau…

Hoffe das hilft.

Gruß Lutz

Hallo,
ich wurde vom Prediger wohl zum großen Zuhörer “degradiert” - vielen Dank für diese super-ausführliche Beschreibung und Anleitung. Damit kann ich echt was anfangen. Sobald ich wieder mal im Büro bin werde ich das ausführlich testen und mich zurückmelden.
Wie bereits geschrieben - die Vorarbeit wurde seitens Univention ja schon geleistet; demgemäß könnte UCS diese Werte zukünftig auch als Standard eingetragen haben, oder spricht etwas dagegen?
MBG,
TP

Hallo,
Das ist mit unserer Entwicklung und dem Security Team bereits in Klärung (Ich wollte eigentlich erst etwas schreiben wenn ich da genaueres weiß). Wir nehmen das durchaus ernst.

Gruß,
Jens Thorp-Hansen

Kann man das Problem auch unter UCS 3.2 beheben?

Welche Version/errata-level wäre dafür nötig?

Darf ein Backup/Slave/Member-Server eine höhere Minor-Version haben? (sprich z.B. 3.2-6., während der Master 3.2-3 hat?)

LG,
Roland.

Die Enhancement-Bugs hierzu beziehen sich auf UCS 4.
Du kannst ja mal schauen, ob sich irgendwo Anleitungen finden, die sich mit der Apache-Version aus Squeeze im Kontext der ECHDE-Cipher beschäftigen. Ich kann mir vorstellen, dass dies schwierig wird.

Ansonsten sollte nach meiner Erinnerung der Master immer das aktuellste System sein. Das ist bestimmt auch irgendwo dokumentiert.

Hallo Herr Gsell,
Wir werden die SSLCipher Konfigurierbarkeit via UCR aus UCS 4.0 auch nach UCS 3.2 zurückportieren. Details finden Sie hier [bug]38632[/bug].

Mit freundlichem Gruß,
Jens Thorp-Hansen

Nur zur Info: Das UCS 3.2 Erratum wurde inzwischen released: http://errata.software-univention.de/ucs/3.2/345.html.

Mastodon