Monthly Archives: August 2021

OpenSSH 8.7 verfügbar

Posted on by

Kurze Ansage von OpenSSH: RSA/SHA1 Signing Algorithmen werden in Kürze abgeschaltet.

OpenSSH 8.7 verfügbar

Weil der Angriff auf einen RSA-SHA1 Hash bereits für unter 50.000 $US zu haben ist, hat sich die OpenSSH Gemeinde entschlossen, diesen Signing-Algorithmus in der nächsten Release abzuschalten. Als Alternative wird rsa-sha2-256/512 empfohlen, oder gleich der Umstieg auf ecdsa-basierte Signaturalgorithmen.

Jetzt werden diese Algorithmen ja nicht gleich aus OpenSSH entfernt, sondern erstmal nur abgeschaltet. Falls mal also ein Problem damit haben sollte, auf alte Server drauf zu kommen, die seit langem keine Updates mehr gesehen haben, kann man es einfach wieder einschalten. Ein kleiner Test kann Euch jetzt bereits zeigen, ob Ihr davon betroffen seid:

ssh -oHostKeyAlgorithms=-ssh-rsa user@host

Ich habe das bei mir mal getan und konnte selbst auf einem Android 4 SSH Server von Anno 2016, keine Probleme feststellen. Sorgen muß man sich also kaum welche machen.

Das Ende von SCP

Das Ende von SCP dagegen rückt immer näher. Zur Zeit werden an SFTP Änderungen vorgenommen, die es erlauben, Daten von einem Server direkt zum anderen Server zu kopieren, so wie das mit scp auch möglich ist. Alternativ würden ja Dinge wie – ssh root@server1 „sftp file root@server2:/path/“ – auch funktionieren, auch wenn sie nicht ganz so elegant wären 😉

Die anderen Änderungen sind eher sehr speziell und werden Euch nicht direkt betreffen.

lwn.net – OpenSSH 8.7 released

Pinephone: Phosh und Pipewireupdates

Posted on by

Moin,

endlich mal wieder News vom Pinephone für Fedora, auch wenn es nur kleine News sind.

Pinephone: Phosh und Pipewireupdates

Mit dem neuesten Phoshupdate 0.13.0-1 geht auch endlich das Taschenlampenicon im Phosh Panel, da wo man WLAN Bluetooth usw ein- und ausschaltet. Eine Funktion, die so trivial war, daß ein 5 Zeiler in Bash die Sache genauso gut erledigen konnte. Es hat ja gefühlt nur ein Jahr gedauert, bis jemand endlich den Platzhaltercode durch die echte Funktion ersetzt hat. Weil ich mich sonst zu sehr aufrege, kommen wir zu einem anderen Thema des Pinephones:

Pipewire 0.33.3

Das Pipewireupdate von 0.33.2 auf 0.33.3 hat es leider in sich, denn danach geht erstmal kein Sound mehr und der übliche Reboot machts nur noch schlimmer. Ich kann jedem nur raten, dies Update nicht einzuspielen. Wenn Ihr es schon drauf habt, dann macht das Downgrade auf 0.33.2 : dnf downgrade pipewire*0.33.2*

Der Befehl funktioniert z.B. im DNF Cache -> /var/cache/dnf/rawhide-???????????/packages , sofern man die Cachefunktion im DNF aktiviert hat -> /etc/dnf/dnf.conf .

Alternativ muß man sich die RPM Files vom Koji Repo ziehen:

https://koji.fedoraproject.org/koji/packageinfo?packageID=24555

Die Notlösungen, auf andere Profile umzustellen, damit es wenigstens noch klingelt, kann ich nicht empfehlen. Das ist sehr unzuverlässig und auch definitiv keine gute Lösung.

(Schon aufgefallen? Unsere 3 Schlagworte fangen alle mit P an .. Pinephone, Pipewire und Phosh … 😉 )

An die IT der Stadt Braunschweig in Sachen MAILSERVER

Posted on by

Im Gegensatz zum letzten Lokalbeitrag über Lebensmittel bei Aldi Nord, kommt heute ein weniger ekliges Thema dran … Woher weiß man, daß man mit dem Mailserver der Stadt Braunschweig spricht?

An die IT der Stadt Braunschweig in Sachen MAILSERVER

Liebe IT-Verantworlichen der Stadt Braunschweig,

wie wir Euch 2018 schon einmal mitgeteilt haben, sind Eure SSL-Zertifikate im Mailserver nichts wert. Glauben Sie nicht? Bitte schön:

$ openssl s_client --connect mailin02.braunschweig.de:25 -starttls smtp -verify_hostname mailin02.braunschweig.de
CONNECTED(00000003)
depth=0 C = DE, ST = Niedersachsen, L = Braunschweig, O = Stadt Braunschweig, OU = IuK, CN = mailin02.braunschweig.de
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 C = DE, ST = Niedersachsen, L = Braunschweig, O = Stadt Braunschweig, OU = IuK, CN = mailin02.braunschweig.de
verify error:num=21:unable to verify the first certificate
verify return:1
depth=0 C = DE, ST = Niedersachsen, L = Braunschweig, O = Stadt Braunschweig, OU = IuK, CN = mailin02.braunschweig.de
verify return:1
---
Certificate chain
0 s:C = DE, ST = Niedersachsen, L = Braunschweig, O = Stadt Braunschweig, OU = IuK, CN = mailin02.braunschweig.de
i:C = DE, ST = Niedersachsen, L = Braunschweig, O = Stadt Braunschweig, OU = IuK, CN = BSSUBCA02
---

Was bedeutet die Ausgabe?

Das jemand ein Zertifikat auf „mailin02.braunschweig.de“ ausgestellt hat und anstatt dies von einer anerkannten Autorität (CA) beglaubigen zu lassen, es mit einem anderen selbst gebauten Zertifikat und dessen Schlüssel unterschrieben hat. Das macht natürlich aus dem ersten Zertifikat mailin02.braunschweig.de auch kein anerkanntes Zertifikat, sondern nur ein weiteres Zert, dem man nicht vertrauen kann.

Das Emails bei der Stadt Braunschweig trotzdem eingehen, liegt einfach daran, daß derartige Fehler sooft vorkommen, daß wer ernsthaft die Autorität eines empfangenden Mailserver prüft, kaum noch Emails rausbekommt. Besser macht die Erkenntnis den Fall natürlich auch nicht, es bleibt ein Setupfehler.

Anders läge der Fall, wenn das Zert mit dem Kürzel BSSUBCA02 selbst von einer bekannten CA verifiziert und beglaubigt wäre. Das kann man aber nicht prüfen, weil das dafür nötige Zert nicht mitgeliefert wird. Pech.

Es bliebt also dabei, diesem Server kann man nicht glauben, daß er wirklich die Stadt Braunschweig repräsentiert.

Weiß hier A nicht, was B tut?

Wer sich mal die Webseite unter Braunschweig.de näher ansieht, findet dort ein Zert für „*.braunschweig.de“, ein sogenanntes Wildcard-Zertifikat. Dies ist für alle beliebigen Domainnamen gültig, auch für „mailin02.braunschweig.de„. Wieso man das dann nicht für den Mailserver nimmt, kann ich nicht beurteilen. Das Wildcard Zert ist nicht eingeschränkt auf das Web ( was gehen würde ), es kann also überall eingesetzt werden.

Basierend auf der Erfahrung mit der Stadt Wolfenbüttel ( gleich hier um die Ecke ), würde ich mich jetzt aus dem Fenster lehnen und behaupten, daß das IT-Managementsystem auf Windowsbasis, daß die Stadt einsetzen wird um deren Firewall und Mailserver zu verwalten, den Admins nur die Innenseite des Netzes anzeigt, aber nicht, was außen wirklich los ist. Ich vermute, intern wird schon seit einiger Zeit ein korrektes Zert angezeigt und das uns gezeigte Mailserverzert ist bloß ein Fragment eines Testsetups von früher.

Das „Root CA 2“ Zert der Stadt Braunschweig, ist scheinbar von 2016 und das „mailin02.braunschweig.de“ von 2017, aber mit einer Gültigkeit von 10 Jahren. Dies ist ein typisches Testsetup, denn normale Zertifikate werden nach 1-2 Jahren getauscht.