Author Archives: marius

Vodafone: falsche SSL-Cipher behindern Mailserver

Posted on by

Aus der Rubrik SSL-Fail haben wir heute die Domain „kabelmail.de“. Jetzt fragt Ihr Euch natürlich, was Vodafone damit zu tun hat, oder?

Vodafone: falsche SSL-Cipher behindern Mailserver

Der Teil ist weniger spannend als man vermuten könnte:

# dig +short mx kabelmail.de
100 mx01.xworks.net.

Die Domain xworks.net gehört zu Vodafone. Das Problem selbst ist der Windowswelt weiter verbreitet, da es nicht der erste Fall eines Großunternehmens ist, daß seine Mailserver nicht unter Kontrolle hat 😉 Jetzt schauen wir uns aber erst einmal an, was überhaupt los ist.

Der nachfolgende Auszug ist stark auf das Wesentliche verkürzt, gebt den Befehl einfach selbst ein, wenn Ihr alles sehen möchtet:

# openssl s_client -connect mx01.xworks.net:25 -starttls smtp
CONNECTED(00000003)
…
Peer signing digest: SHA512
Server Temp Key: DH, 1024 bits
—
SSL handshake has read 5195 bytes and written 513 bytes
Verification: OK
—
New, SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 4096 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : DHE-RSA-AES256-SHA
…

Jetzt muß man wissen, das Cipher immer Kinder ihrer Zeit sind, meint, die kann man einer Protokollgeneration zuordnen. „DHE-RSA-AES256-SHA“ ist ein SSLv3/TLS1 Cipher, weswegen OpenSSL hier auch SSLv3 anzeigt, obwohl TLS1.2 gesprochen werden soll.

Hat man jetzt einen Server, der kein SSLv3, TLS1.0 TLS1.1 mehr erlaubt, weil das komplett gebrochen ist und de facto kein „Stand der Technik“ mehr ist, kann man sich leicht ausmalen, was mit einer SSLv3 Verbindung passiert, die eigentlich TLS 1.2 sein müßte 🙂 Genau, sie kommt nicht zu Stande:

2021-01-09 11:22:10 1kxoMm-0002bp-LI == XXXXXXXXXXXXXXXXXXXXx@kabelmail.de <XXXXXXXXXXXXX@kabelmail.de> R=dnslookup T=remote_smtp defer (-37) H=mx01.xworks.net [31.25.48.11]: TLS session: (SSL_connect): error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure

Den TLS Handshake einer Verbindung kann man sich so vorstellen:

Client: Hallo Server, ich würde gern TLS mit Dir sprechen, hier sind meine möglichen Cipher…..
Server: Hallo Client, nett, ich könnte das hier anbieten: Cipherliste des Servers
Client: Klasse, dann nehmen wir den ersten aus Deiner Liste, den ich auch kann.. Wie wärs mit .. „ECDHE-RSA-AES256-GCM-SHA384:256“

„ECDHE-RSA-AES256-GCM-SHA384:256“ gehört zur TLS 1.2 Ära ist also was halbwegs aktuelles.

Die Cipherliste ist so definiert, daß der „beste“ aka. „highest“ Cipher vorn als erstes steht. Das machen Client und Server beide so, der erste gemeinsame Cipher der Reihenfolge von „bester“ -> „schlechtester“ Cipher  wird dann benutzt.

Die Ursache

Ursache des SSLv3 Problems bei Windows Mailservern ist jetzt genau die selten gepflegte Cipherliste, die bei der Installation anno 1995 auf die Platte gemeisselt und seitdem kaum aktualisiert wurde. Ich seh hier natürlich Microsoft in der Pflicht, aber hey, ein Mailserveradmin sollte das wissen und checken. Die Ursache ist also bekannt, die Lösung trivial: einfach diese Liste aktualisieren und gut.

Die Ursache ist also bekannt, wieso jetzt den Artikel? 🙂

Ja, wieso eigentlich, beim Großunternehmen ENBW hat es damals doch auch sofort geklappt, eine Email und ein erstaunter „Was zum Geier ist das?“ Rückruf später, konnte man dem ENBW Mailserver wieder Emails senden 🙂

Am 9.1. wurde der Vodafone Support :

TECHNIK: Falsche Cipher Reihenfolge beim Mailserver von kabelmail.de

Moin,

Wenn man DSGVO konform Emails an Kunden von Ihnen schicken möchte, funktioniert dies nicht,
da der SMTP-Server von kabelmail.de => mx01.xworks.net die falsche Reihenfolge der SSL-Cipher konfiguriert hat.

Das kann man selbst ganz einfach mit openssl feststellen:
… die Openssl Anweisung von oben…
Wie man leicht erkennen kann, wird ein SSLv3 Cipher ausgehandelt, weil Ihr Server den als „besten“ Cipher im Cipheroffer anbietet.

Keine Panik, das passiert vielen M$ Kunden und läßt sich ganz einfach lösen:

Drehen Sie die Reihenfolge der Cipher in der Mailserverconfig einfach um und packen Sie die TLS 1.3 und 1.2 Cipher nach vorn in der Liste.

Eine automatische Antwort vom Ticketsystem war auch umgehend da. Am 12.1. kam dann diese Email von Support von Vodafone:

Lieber Vodafone-Kunde,
wir haben Ihre Nachricht an unsere Experten für Ihr Anliegen weitergeleitet.
Die Kollegen antworten Ihnen in Kürze oder rufen Sie zurück. Haben Sie bitte noch ein klein wenig Geduld – vielen Dank.
Hatten Sie mehr als ein Anliegen, antworten wir Ihnen separat.
Freundliche Grüße
Ihr Vodafone-Team

 

Am 14.1. kam dann diese Email von einer anderen Abteilung des Supports:

Sehr geehrte Damen und Herren,

damit wir Ihnen schnell helfen können, brauchen wir noch Infos von Ihnen:

– Ihre Kundennummer
– Was funktioniert nicht?
– Seit wann funktioniert es nicht?

Rufen Sie uns am besten an. Oder antworten Sie auf diese E-Mail.

Freundliche Grüße
Ihr Vodafone-Team

meine Antwort:

Am 14.01.21 um 16:31 schrieb Technischer Kundenservice:

Sehr geehrte Damen und Herren,

damit wir Ihnen schnell helfen können, brauchen wir noch Infos von Ihnen:
– Ihre Kundennummer
Keine Kundenbeziehung.

– Was funktioniert nicht?

Siehe Ticket: Man kann Euch DSGVO Konform keine Emails senden, weil der SSLv3 Cipher benutzt wird, statt dem TLS1.2+ .

– Seit wann funktioniert es nicht?

Seit Jahren, mir gehts nur langsam so auf den Senkel, daß ich Sie informiert habe.

Die alte Leier, man hälts ne Zeitlang aus, merkt dann, daß der andere nie was ändern wird und tritt ihm dann in den Hintern 😉 Irgendwie hatte ich mich aber undeutlich ausgedrückt, denn es kam eine weitere Email:

Sehr geehrte Damen und Herren,

damit wir Ihnen schnell helfen können, brauchen wir noch Infos von Ihnen:

– Ihre Kundennummer

Rufen Sie uns am besten an. Oder antworten Sie auf diese E-Mail.

Freundliche Grüße
Ihr Vodafone-Team

meine Antwort:

Sehr geehrte Damen und Herren,

wir haben keine Kundenbeziehung und nicht Sie helfen mir, sondern ich helfe gerade Ihnen.

Alles was Sie wissen müssen, steht bereits im Original Ticket drin, Sie müssen es nur an die zuständigen Admins weiterleiten.

Seitdem herrscht Schweigen im Walde und auch das Problem wurde noch nicht behoben. 14 Tage sind eigentlich genug Zeit um eine Liste von Ciphern zu aktualisieren, also kommt Ihr jetzt schon in den Genuss der Story 🙂 Die ich Euch natürlich nur deswegen ins Blog stelle, weil die Ursache klein, die Wirkung groß und die Lösung trivial ist 😀 und natürlich weil es Vodafone ist 😉

Unter Linux braucht man sich da im Normalfall eigentlich keine Gedanken machen, da OpenSSL so eine Cipherliste bereitstellt, die mit jedem Update automatisch aktualisiert wird. Man kann es natürlich auch selbst im Mailserver eintragen, wenn man da noch härter sein will, ist aber eigentlich nicht nötig. Man könnte ja auch mal auf ältere Mailserver stoßen, die nicht den aller neusten Cipher bereit haben.

Falls jemand von Vodafone zufällig diesen Artikel findet, Sie suchen das hier: „6618829#5df0179#“ 😉

CoronaChroniken: Zeit für ein Update

Posted on by

Liebe Maskierte,

seit Montag dürfen wir ja nur noch mit medizinischen Masken/FFP2+ Masken in die Läden gehen. Da muß die Frage berechtigt sein, ob man das Recht auf Broterwerb, und damit letztlich das Grundrecht auf Leben, überhaupt derart einschränken darf.

CoronaChroniken: Zeit für ein Update

Im Wettstreit „Wer überbietet wen mit dem härtesten Unsinn“ überbieten sich nicht nur die Bundesländer, sondern auch ganze Staaten. Ganz vorn dabei ist die Achse Bundesrepublik-Österreich, die auch schon vor Corona nach dem Motto handelte : „Was die können, können wir härter, egal wie idiotisch es ist.“

Newsticker: Corona Maßnahmen – Verwaltungsgerichtshof kippt 15-Kilometerregel in Bayern

Aber kommen wir zur gesiebten Luft zurück, über die sich die Nicht-knackies seit Jahrhunderten lustig gemacht haben, aber die aktuellen Kanckies jetzt nur mild belächeln können, denn die können weiterhin ungehindert tief Luft holen, wie mir die Justizvollzugsanstalt Braunschweig gerade eben bestätigt hat.

Schauen wir uns mal die Entwicklung der Graphen an:

ACHTUNG: die letzten 3 Wochen der Hospitalisierten und Verstorbenen werden noch starke Nachmeldungen erfahren.

Wenn man sich den Trend der letzten 3 Wochen ansieht, dann ist klar: Die Welle ist durch.

Wieso man jetzt noch Verschärfungen durchzieht, ist nicht mit Zahlen begründbar. Das Frau Merkel es mit Ihren Entscheidungen eher ohne Faktenbasis hält, hatte sie in der jüngsten Bundespressekonferenz selbst auf Nachfrage von Thilo Jung erklärt. Sie hält es lieber politisch, denn faktisch: Youtubevideo

Schauen wir uns das mal mit allen Zeitmarken an:

Einführung der Maskenpflichten im April: Kurve geht vorher schon runter

Einführung der Lockdown im November: Kurve flacht vorher schon stark ab

Einführung der FFP-Maskenpflichten im Januar ( keine Linie, weil erst gestern ): Kurve geht vorher schon runter

Wie man durch einen Vergleich der Kurven vom März mit dem November sieht, stimmt etwas ganz gewaltig nicht mit den Neuinfizierten Zahlen des RKI. Wo die Hospitalisierten und Verstorbenen fast schon exakt gleich verlaufen ( immer an die 12,3 Tage Versatz denken, die zwischen Einlieferung und versterben im Durchschnitt liegen ), da macht die Kurve der Neuinfizierten eine wilde Reise.

Vermutlich sieht es in echt so aus:

Ich brauche auch mal ein eigenes Grafiktablet für sowas 🙂

Achtung: Den Graphen vom RKI liegen nur Wochenzahlen zugrunde, die sind daher ungenau! Wohingegen die Neuinfiziertenzahlen täglich bekannt gegeben werden.

Nehmen wir mal an, daß …

Bitte daran denken, das ist reine Spekulation von mir, auch wenn es passend klingt, muß es nicht stimmen.

die rosa Kurve die wahrscheinliche Kurve ist, dann können wir daraus ableiten, daß vor dem Lockdown Anfang November die Trendwende eingeläutet war. Eine einfache Erklärung wäre, daß das exponentielle Wachstum am Anfang einer Welle, daraus resultiert, daß es noch keinen Widerstand in der Zielgruppe gibt, auf die der Erreger trifft. Sobald die ersten die Infektion bekämpft haben, können sie diese nicht mehr weitergeben und der Bremseffekt setzt ein. Das wird dann am Ende als Herdenimmunität bezeichnet.

Da wir derzeit 83 Millionen Menschen sind, aber nur 2 Millionen „offiziell“(*) das Virus hatten und fügen wir noch eine 1:10 Dunkelziffer hinzu, war die Menge der Menschen, die das Virus überhaupt nur bekommen konnten: 22 Millionen, also rund ~25% der Bevölkerung. Das ergäbe eine Immunitätsrate von ~75% in der Bevölkerung.

Wie könnte die Neuinfektionskurve des RKI zustande gekommen sein?

Werft mal einen Blick hierauf: https://pavelmayer.de/covid/risks/

Herr Mayer, assoziiert mit dem CCC, wertet da die Rohdaten vom RKI aus und bestimmt u.a. auch eine „Ignoriert“ Spalte. Da tauchen für einzelne Landkreise teilweise 30% „Meldungsverluste“ auf. Das ist in Summe ungefähr das, was unter dem rosa Graphen fehlt um den aufzufüllen. (spekulative Behauptung!)

Damit würde der angeblich durch den „Lockdown“ ausgelöste Deckeleffekt nicht existieren und vermutlich auf eine Überlastung des Meldesystems zurückzuführen sein. Diese Spekulationen gab es Ende November schon im Netz, wenn Ihr Euch erinnern wollt.

Als dann die Neuinfektionszahlen im Dezember wegen der immer stärker werdenden Herdenimmunitätseffekte zurückgingen, konnte das Meldesystem wieder mithalten und den Verzug auch ein bisschen ausgleichen. Das dürfte die zweite, kleinere Spitze in dem Neuinfektionsgraphen erklären. Danach deckt sich die Kurve wieder mit dem natürlichen Verlauf, wie schon im April.

Was wir jetzt also sehen, ist das Ende der Welle, die jetzt wieder langsam auslaufen wird.

Wir halten fest: Keine der durch die Regierung getroffenen Maßnahmen hatte wahrscheinlich einen Effekt. Das die Impfungen bereits Effekte zeigen könnten, liegt an der Zielgruppe der 22 Millionen selbst, denn die ist fast deckungsgleich mit der Risikogruppe. Impft man dort, ist der Effekt besonders stark. Das werden wir aber nicht mehr sehen können, denn es müßte eine beschleunigte, und daher unnatürliche, Abflachung der Kurve geben. Nur wenn das im Graphen zusehen ist, hatte die Impfung einen nachweislich Effekt. Die nächsten 4-8 Wochen werden es zeigen.

Ob die Impfung überhaupt noch nötig war/ist, kann bezweifelt werden. Ich spreche hier nur auf die Gesamtbevölkerung bezogen, nicht auf das Individualrisiko jedes einzelnen. Für die Patienten der Risikogruppen, ist natürlich von Vorteil sich zu impfen.

Ab hier wieder faktisch belegt 😉

Das das R unter 1 liegen muß, damit die Kurve abfällt, ist Euch ja und schon hinlänglich bekannt:

Ich denke daher, daß die verschärfte Maskenpflicht mal wieder eine Laue im faktenlosen Entscheidungsprozess unserer Kanzlerin ist und man die getrost ignorieren kann, genau wie unsinnige Ausgangssperren in der Nacht.

Pinephone: Updates für Mesa, Vulkan und Phosh

Posted on by

Kleines Update für alle Pinehpone-Fans und Pannenliebhaber 😀

Pinephone: Updates für Mesa, Vulkan und Phosh

Zunächst kann man die Mesa Pakete wieder in die normale Aktualisierung aufnehmen, die Probleme die sie verursacht haben sind vom Tisch. Das betrifft auch den Mesa-Vulkantreiber.

In die Kategorie „Wer nachschaut ist selbst schuld“ kann man auch das Phosh 0.8.0 Update einordnen. Ich habe doch glatt den Fehler gemacht und Hoffnung gehegt, daß es seit 0.6.0 besser geworden wäre. Tja.

Natürlich gab es Detailverbesserungen, aber davon merkt man nichts. Im Gegenteil, weil es diese Verbesserungen gab, kam es zu kuriosen Fehlern 🙂

Da hätten wir:

Da jetzt die TextScaling-Einstellungen der Original Gnomeshell benutzt werden, wurden alle Texte auch in Phosh größer. Das betraf allerdings nicht nur die Desktoptexte z.b. der Icons und die der Apps, sondern auch den Unlockerscreen. Was dabei rausgekommen ist, seht Ihr auf dem Bild.

Natürlich betrifft dies auch den Zahlenblock zum Entsperren 😉

Und Ihr seht hier noch die glimpfliche Variante, weil, wenn das Handy im Landscapemodus läuft und dann in den Lockscreen wechselt, könnt Ihr Euch dann denken was passiert?

Ja, der Lockscreen wechselt nicht in den Portraymodus, so das man nicht mal mehr das Handy entsperren kann, weil die dafür nötigen Flächen und Buttons nicht mehr innerhalb des Bildschirm liegen. ARGS!!!

Dabei sind das vielleicht 3 Zeilen Code extra :

int orientation = display.getOrientation();
display.setOrientation(DISPLAY_PORTRAYMODE);
lockDevice();
display.setOrientation(orientation);

Mehr ist das nicht. Schon traurig, oder?

Wohl Ihr noch ein ARGS haben?

Ihr erinnert Euch doch daran, daß ich die fehlenden DPI-Scaling Optionen im Bildschirmeinsteller moniert hatte. Das sind die „100%“ „200%“ „300%“ Voreinsteller, damit die Oberflächen lesbar werden, wenn das physikalische Display eine 3k, 4k oder 8k Auflösung hat. Unter Phosh sind die jetzt da 100% und 200%, aber, wenn man es wagt, da auf 100% zu klicken, dann verändert sich der Bildschirm doch tatsächlich entsprechend.(Bild stammt nicht vom Pinephone)

Jetzt der Knaller: Die Buttons lösen sich dann aber in Luft auf. Es gibt also keinen Weg zurück. Erst nach einem Neustart von Phosh startet es dann wieder mit den bekannten 200%.

Dafür startet aber Gnome-Tweaks nicht mehr .. aber nur unter Phosh nicht, bei Gnome gehts noch normal.

Andere Statusmeldungen zum Pinephone

Es gibt eine neue Call Version und der CallaudioDaemon wurde aktualisiert. Wenn man jetzt die Kopfhöhrer ins die Klinkenbuchse steckt, wird der Ton zwar auch im Kopfhörer abgespielt, aber auch auf dem Lautsprecher. Außerdem muß man selbst noch im Pulseaudio-Lautstärketool das Kopfhörer Device auf „laut“ stellen. Das wird nämlich gemutet und mit Volume 0 gestartet! Das ist aber nicht das schlimmste.

Macht man das, geht das Touchdisplay nicht mehr. Bugreports sind offen 🙁

Tut mir echt leid das so sagen zu müssen, aber das ist Scheiße Leute! In dem Zustand ist das keine Beta, sondern eine tiefe Alpha.

Ich habe außerdem den Verdacht, daß der Cam-Chip in dem Pinephone aus einer nachtaktiven Überwachungskamera stammt. Die Iso kann man soweit aufdrehen, daß das Pine in der Nacht brauchbare Aufnahmen machen kann, nur durchs Restlicht. Die Kamera-LED geht ja auch noch nicht unter Fedora.