An die IT der Stadt Braunschweig in Sachen MAILSERVER

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 worden. 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 Windows basiert, welches 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.

Linux Am Dienstag – Nachlese 3.8.

Was für ein verrückter Abschluss des gestrigen Vortragsabends 😀 Ein Filesystem, das Daten nicht auf einem Cloudserver speichert, sondern nur im Draht und der Netzwerkkarte zu dem Cloudserver. Wahnsinn! Und weil das nicht genug war, gibt es nächste Woche noch oben eins drauf: ein verschlüsseltes Filesystem auf dem Internetfilesystem drauf 😀

Linux Am Dienstag – Nachlese 3.8.

Für Alle die nicht dabei waren, gestern ging es um Dateisysteme, was drin ist und was man abgefahrenes damit machen kann.

Zuerst gab es einen Vortrag, was wo in einem Linuxfilesystem drin ist. Den könnt Ihr hier downloaden: LUG-2021-Linux-Dateisystem-101-v2

Dann haben wir uns ein Zip Filesystem auf FUSE Basis angesehen:

fuse-zip ./Download/Archivname.zip mntpoint/

Damit ist es möglich mit allen Programmen direkt Dateien aus einem Zip Archiv zu bearbeiten und direkt wieder zu speichern, ohne dafür extra ein Zip-Tool bemühen zu müssen. Dies vereinfacht den Zugriff darauf.

Der nächste Punkt war dann schon etwas ungewöhnlicher: Live Transcoding von MP3 Files

Das FUSE MP3-Filesystem „mp3fs“ kann z.b. FLAC Files „on-access“ in MP3 Files umwandeln:

mp3fs ~/Musik/flacs/  mntpoint/

Bei Mounten kann man diverse Optionen angeben, z.b. die Bitrate fürs Encoding, diverse Strategien.

Hier ein Beispiel wie das dann im Dateimanager aussieht:

Beim Zugriff auf die rechte Seite wird das Flac File von Links kurz kodiert und dann startet die Wiedergabe als MP3. Bis zu diesem Zeitpunkt gibt es das Mp3 File gar nicht. Natürlich hängt die Dauer der Kodierung auf vom PC ab, auf dem dies stattfindet 😉

Danach kam der feuchte Traum eines jeden Scriptkids : PingFS

Ein Filesystem, daß die Daten wortwörtlich im Netz speichert, OHNE Speicherplatz auf einem Server zu benötigen. Im Vortrag zum „Blackops of DNS“ Gedächtnisevent für Dan Kaminski vor ein paar Wochen hatte ich ja mal diverse Techniken gezeigt, wie man Datentransfers verheimlichen kann, u.a. auch den Datentransport per Ping. Das PingFS hat den Ansatz genutzt und speichert die Dateien in Ping-Paketen die zwischen den Servern hin und her geschoben werden. Die Speicherung der Daten erfolgt streng genommen als Bandbreite im Netz 😀

Da man die Pakete nur als Root verschicken kann, kann nur Root dies Filesystem mounten. Nutzer können es allerdings danach auch einsetzen, wenn Sie passende Zugriffsrechte haben.

Im Schritt 1 legt man eine möglichst lange Liste mit Servern als Textdatei an, die für das Netz benutzt werden sollen. Das können Domainnamen oder auch Ips sein, spielt keine Rolle.

Schritt 2 startet das Filesystem:

pingfs -t 5 hosts.txt /mnt/

Speichert man nun eine Datei im /mnt/ wird diese per Ping an die anderen Server übertragen. PingFS zeigt dabei die aktuellen Pakete pro Sekunde an, die dazu benötigt werden.

Verliert der PC den Strom, den Internetanschluss oder unmounted Root /mnt/ sind die Daten weg. Es schwirren für einige ms noch Pakete durchs Netz, aber das hört schnell auf.

Was mich noch interessieren würde ist, ob die anderen Server diese Pakete erkennen und als eigenes Filesystem zur Verfügung stellen können. Damit hätte man ein sprichwörtliches Netzwerklaufwerk 😉

Nächste Woche sichern wir dann PingFS mit einer Verschlüsselung ab, weil derzeit ist das noch Klartext 😉

Am Ende des Abends haben wir uns im 2,5h Stammtisch noch Pop!Os von System76 angesehen, das wirklich ausgesprochen flott unterwegs ist, und mit einer netten Ausstattung kommt. Leider funktionierte Fondo da nicht, was schade war.

Firefox: wie man nur noch Passwörter der eigentlichen Webseite sieht

Moin, Moin,

im Zuge des Bugtrackings für das Erscheinen der Passwortbox bei nicht Loginfeldern, kam auch endlich eine Lösung für dem Umstand ans Licht, daß meine Passwortbox einen halben Kilometer lang ist 🙂

Firefox: wie man nur noch Passwörter der eigentlichen Webseite sieht

Ich betreue ja einen Cluster und muß mich auf vielen Webseiten einloggen, da sammelt der Firefox natürlich eine Menge von Logindaten für Subdomains von uns und unseren Servern. Die Standardeinstellungen für Firefox zeigen in der PasswortBox alle Logindaten für die Hauptseite und alle Subdomains davon an.

Wenn man jetzt son Servercluster mit Subdomains adressiert: han1.domain.de han2.domain.de etc. etc. , dann bietet Firefox auf domain.de auch han1 und han2 und han… an. Für uns ist das wenig hilfreich, weil wir Logindaten nicht recyceln, also für jeden Login wirklich neue Daten verwenden, daher wird uns sehr viel angezeigt, daß wir nicht brauchen.

Dem Problem kann man jetzt elegant abhelfen, einfach in der about:config diesen Wert auf „Falsch“ setzen:

signon.includeOtherSubdomainsInLookup

Wer auf verschiedenen Subdomains die gleichen Zugangsdaten benutzt, so daß das Feature Sinn machen würde, der verdient es IMHO nicht besser, als das die Daten im nächsten großen Datenleck landen 😀