Hallo KaaLUGs,

wie ich auf Heise lesen musste, hat man einen Weg gefunden den Diffie Hellman Keyexchange soweit zu schwächen, das man ihn besser nicht mehr verwenden sollte.
Da so ziemlich alle verschlüsselten Protokolle auch DH benutzen (Teil des TLS/SSL), sind diese davon betroffen:
SSH, IMMAPS, HTTPS...

Zudem ist es durch eine Man in the Middel Attacke möglich Server und Client durch einen Eingriff auf eine kurze Schlüssellänge zu zwängen. Auch das sollte abgeschaltet werden. Das dies möglich ist, ist ein Überbleibsel der US Exportbeschränkungen für Kryptographie - ein Schelm wer böses dabei denkt.

Wer ein verschlüsseltes Protokoll verwendet sollte unbedingt hier www.weakdh.org nachlesen wie man seine verschlüsselten Protokolle anpassen muss.

Liebe Grüße,
KlaRen

Für sshd scheint nach einiger Recherche möglich mit:

KexAlgorithms Diese E-Mail-Adresse ist vor Spambots geschützt! Zur Anzeige muss JavaScript eingeschaltet sein!

in /etc/ssh/sshd.conf
den Key exchange Algorithmus auf ein sicheres Verfahren (Elyptic curve) festzulegen. Keine Ahnung ob es clients gibt, die damit nicht zurecht kommen.

Hi,

ja, stimmt SSH kann man das Diffie-Hellmann wegkonfigurieren, zumindest bei openssh geht das. War auch auf der Website weakdh.org (mein link von oben) beschrieben.

Bleibt aber so ziemlich alles andere...
HTTPS, IMAPS, Jabber, SMTPS, openVPN mit Zertifikaten, online Banking.... halt alles was auf TLS aufbaut.

Aber das ist der Lauf der Dinge. Neue mathematische Verfahren sind gefragt, die dann noch schwerer zu knacken sind als Logarithmen von Primzahlpaaren und Elliptische Kurven.. und die alten scheiden immer mehr aus. Wird ja auch hoffentlich keiner auf die Idee kommen DES oder RC4 zum Verschlüsseln zu verwenden.

Hier hat es nur eine sensible Stelle des TLS erwischt... die asymmetrische Verschlüsselung um den symmetrischen Schlüssel für die Transportverschlüsselung zu übertragen. Wer den Transportschlüssel hat, kann alles entschlüsseln und mitlesen, egal wie gut die symmetrische Verschlüsselung ist. Da nutzt dann auch AES256 nix mehr.
Aber Abilfe ist unterwegs.. und die NSA hat demnächst eine Hintertür weniger.

Zusatz: Ganz paranoide sollten nicht nur die DH Parameter mit mindestens 2048 Bit neu berechnen sondern auch gleich die Zertifikate samt Schlüssel wechseln - wer weiß wer den schon alles mitgelesen hat.

Liebe Grüße,
KlaRen

Hi,

hab gerade festgestellt, das man mit dem Parameter:


in der sshd_config sich auch die Windoofs dieser Welt aussperrt.
Putty (ssh client unter Windows) in der stabilen Version kann dieses Verfahren nicht und stoppt den Verbindungsaufbau.
Das nightly build von der Entwickler Seite , kann es aber.

Zu empfehlen ist die Einstellung dennoch. Es hat bei mir die Loginversuche aus China & Co drastisch reduziert.
Die curve25519 ist da wohl auch noch nicht angekommen:
May 23 19:31:18 maurice sshd[17436]: Received disconnect from 36.249.63.110: 11: Bye Bye [preauth]

Liebe Grüße,
KlaRen

Danke für die Info,

musste auch feststellen, das Serverauditor nicht damit klarkommt. Da ich bisher keine vergleichbar brauchbare App für Android gefunden habe hab ich diffie-hellman-group14-sha1 wieder eingeschaltet.

Ja, sieht so aus als ob der Wald-und-Wiesen SSH client die eliptic curve 25519 nicht unterstützt.
Auch mein Juice SSH, das ich auf Android verwende kann es nicht und SSH Term Pro unter iOS ebenso nicht.

Habe es gerade auch nochmal mit den drei nist eliptic curves
ecdh-sha2-nistp256
ecdh-sha2-nistp384
ecdh-sha2-nistp521
und JuiceSSH ausprobiert.. gehen auch alle nicht.

Hmm, ja das macht SSH wirklich sicherer... nur nicht mehr ganz so universell

Liebe Grüße,
KlaRen

bin eben über dieses Firefox addon gestolpert.
Scheint brauchbar zu sein:

addons.mozilla.org/en-US/firefox/addon/disable-dhe/

für Chromium geht diese Anleitung:

security.stackexchange.com/questions/90046/securing-chrome-against-logjam-on-windows