Marius Welt

Habt Ihr auch einen „modernen“ PHPMyAdmin installiert, der bei einigen Anzeigen gefühlte Äonen braucht, um den banalen Inhalt der Datenbank anzuzeigen ?

Ja ? Habt Ihr auch schon gedacht, daß es an der DNS Auflösung liegen könnte ?
Ja ? und es hat so gar nichts gebracht ein schnelleres Cache einzustellen ?
Ja ? Na dann schaltet doch mal auf ENGLISCH als PMA Sprache um, Ihr werdet Euch wundern !

Es ist einen :facepalm: wert, denn für jede popplige Seite, sei es per AJAX oder per URL Link, lädt PHP die komplette, wirklich MB große Übersetzung, wenn man Deutsch eingestellt hat. Da hilft auch kein Filecache mehr um das zu beschleunigen!

Wie man sowas findet

Sehen tut man das erst, wenn man mit STRACE den Apachen und die ausgeführten PHP Programme traced.

strace -e open,read -f -p `pidof httpd | sed -e "s/ /,/g"`

Es folgt so etwas, in einer schieren Unzahl von Zugriffen, weil PHP echt groß ist und ne Menge einlesen muß.

[pid 10052] open(„/usr/lib/php/modules/intl.so“, O_RDONLY|O_CLOEXEC) = 3
[pid 10052] read(3, „…………………………….jede Menge Text ………………“, 512) = 512

Das oben ist keiner der verdächtigen Zugriffe, zeigt aber, wie man die READs den Dateien zuordnet. Das Orangerote ist der FILEDESCRIPTOR, kurz FD. Jede Datei die man öffnet als Programm, bekommt einen eindeutigen FD, damit man das als Programm zuordnen kann.

Typisch für PHP und die Übersetzungen sind diese Zeilen :

[pid 9436] lseek(4, 93205, SEEK_SET) = 93205
[pid 9436] lseek(4, 93205, SEEK_SET) = 93205
[pid 9436] read(4, „Database %s has been dropped.\0Database Log\0Database client version:\0Database comment\0Database for user account\0Database level tabs\0Database name\0Database name template\0Database operations\0Database seems to be empty!\0Database server\0Database structure\0Database system or older MySQL server to maximize output compatibility with:\0Database tree separator\0Database used for relations, bookmarks, and PDF features. See [a@http://wiki.phpmyadmin.net/pma/pmadb]pmadb[/a] for complete information. Leave blank for no support. Suggested: [kbd]phpmyadmin[/kbd].\0Database-level tabs\0Database-specific privileges\0Database:\0Databases\0Databases display options.\0Databases statistics\0Databases:\0Date\0Deactivate now\0Deactivate tracking for %s\0Debug SQL\0Dec\0December\0Default\0Default database tab\0Default format; be aware that this list depends on location (database, table) and only SQL is always available.\0Default language\0Default server\0Default server tab\0Default sort order for tables with a primary key.\0Default sorting order\0Default ta“…, 8192) = 8192

Warum PHP 8KB Blöcke einliest, statt min. 64KB wird ewig ein Geheimnis bleiben, scheint aber ein Relikt aus den Anfängen zu sein 🙂

Es gilt, wenn der einzulesende Datenblock, der Blockgröße auf im Filesystem entspricht, dann kann das OS den Datenstrom am effizientesten einlesen. Der Datenzugriff sollte nicht größer als die Blockgröße sein, wobei ganze Mehrfache der Blockgröße ok wären. Wenn jetzt wie bei PHP 8KB eingelesen werden, die Datenblockgröße aber 64 KB ist, braucht das OS schon 8x soviele Filezugriffe nebst Performanceoverhead durch die Lesefunktionen, um den gleichen Inhalt eines Blockes einzulesen. Dazu muß die Platte den Kopf 8x zu dem Datenblock fahren, falls auf einem System noch mehr los ist, als nur dieses einzige Programm. Was man getrost annehmen kann.

Sowas ist einfach ineffizient. Ganz besonders ineffizient, wenn die Datei, die man da einlesen will, mehrere MB groß ist.

Ich hoffe, es hilft Euch ein bisschen bei Euren eigenen Problemen.

Nicht das einer meiner geneigten Leser glaubt, ich hätte zuviel Phantasie oder mir wäre das selbst passiert und ich würde es jetzt in einer netten Story schön reden wollen, vergeßt es, es ist tatsächlich so passiert.

Was ist TLS ?

Um zu verstehen was genau passiert ist, muß ich etwas ausholen, da nicht jeder Leser wissen wird, was TLS genau macht.

Erstmal TLS ist die Transport Layer Verschlüsselung(Security) für Emailserver und Webseiten und hat SSL ( Secure Socket Layer ) abgelöst, weil es a) ein paar Vorteile gegenüber SSL hat und b) nicht komplett gebrochen ist wie SSL. (Ja, SSL ist tod, wer noch SSL 1-3 benutzt, kann es auch abschalten und die Rechenleistung anderweitig nutzen 😉 ).

Wenn ein Mailprogramm einen Mailserver mit TLS Unterstützung kontaktiert, tut er das auf den an sich unverschlüsselten Port 25. Der Mailserver meldet dem sich verbindenden Programm/Client/Server welche Möglichkeiten der Server anbietet, z.B. den Befehl STARTTLS . Finden ein sich verbindendes Programm diesen Befehl, wird es diesen Aufrufen und damit die Verbindung von unverschlüsselt auf verschlüsselt „upgraden“ . Damit man das machen kann, sendet der Mailserver seinen öffentlichen Schlüssel in einem Zertifikat an das verbindende Programm und das baut daraus ein passendes Antwortpaket mit einem Sessionkey, der nur für diese eine Datenübertragung existiert. (Idealerweise)

Authentizität

Dabei wird geprüft, ob sich der Mailserver mit einem gültigen SSL-Zertifikat ausweist. An dieser Stelle wird es nun interessant. Unser Mailserver, kann wie die meisten Server, genau ein Zertifikat benutzen, weil alle Domains auf seiner Hauptipadresse liegen. Für Emails ist das auch nicht tragisch, es geht ja nur um die Verschlüsselung des Transports. Also präsentiert der Mailserver sein gültiges Serverzertifikat, daß auf seinen Hostname ausgestellt ist, denn damit meldet sich der Server und damit weiß man, daß dies Zertifikat zum Host paßt. Soweit, so normal.

Die Experten

Jetzt gibt es Leute, die wollen wissen, ob sie abgehört werden, was ein naheliegendes Interesse ist. Deswegen prüfen sie, ob in dem Zertifikat das Ihnen angeboten wird, auch wirklich der Name des Mailserver drinsteht, mit dem sie sich verbinden wollen. Ist das nämlich nicht der Fall, könnte jemand an der Verbindung rumgespielt haben und sich als Man-in-the-Middle-Angreifer betätigt haben, um die Verbindung zu belauschen. Wenn ich jetzt auf Sicherheit und Authentizität wert lege, müßte ich aufhören und die EMail nicht zustellen, weil „irgendwas stimmt nicht“.

Damit Ihr mir folgen könnt, ein paar Beispiele :

$ dig mx bloggt-in-braunschweig.de
;; ANSWER SECTION:
bloggt-in-braunschweig.de. 21599 IN    MX    10 bloggt-in-braunschweig.de.

Das meint, daß die Emails für BIB.de auf einem Mailserver mit dem Hostnamen „bloggt-in-braunschweig.de“ entgegengenommen werden. Verbindet man sich auf Port 25 dort hin, findet man das vor:

$ nc bloggt-in-braunschweig.de 25
220 s120.resellerdesktop.de ESMTP Exim 4.85_2 Sat, 27 Aug 2016 12:11:04 +0200

das meint, daß sich unser Mailserver mit „s120.resellerdesktop.de“ identifiziert, weil das sein Name ist. Entsprechend präsentiert er ein Zertifikat von s120.resellerdesktop.de . Das ist vollkommen ok so 🙂

Aber genau das ist, was einige Experten als den MITM-Angriff definiert haben, denn die haben erwartet, daß sich der Mailserver mit „bloggt-in-braunschweig.de“ meldet, was er nicht tut, weil er noch hunderte andere Domains beherbergt.

Jetzt der Catch 🙂

Statt jetzt aber die Verbindung zu trennen, wie man es bei einem MITM Angriff erwarten müßte, fällt der Expertenmailserver auf unverschlüsselte Kommunikation zurück und stellt die Email unverschlüsselt auf genau diesem Server zu! Das ist FAIL² . Er hätte auch gleich das Zertifikat nehmen können, denn dann wäre die Email wenigstens verschlüsselt übers Netz gegangen, statt im Klartext.

Logik ist nicht jedermans Sache, wie es scheint 😀

Den Experten helfen…

Wenn man jetzt mit solchen Experten kommunizieren muß, ohne das man unverschlüsselte Emails haben will, kann man natürlich etwas tun, was allerdings mit Nachteilen daher kommt. Für den Augenblick sind diese aber vernachlässigbar.

Das Problem liegt ja in der Erwartungshaltung des sendenden Mailservers, der in unserem Beispiel bloggt-in-braunschweig.de haben wollte, aber s120.resellerdesktop.de bekommen hat. Der Name ist im DNS MX Eintrag hinterlegt, weil man so bei einem Domainumzug auf einen anderen Server lediglich einen Eintrag ändern muß. Der MX zieht quasi automatisch um. Unsere Experten würden aber folgendes gerne sehen :

$ dig mx bloggt-in-braunschweig.de
;; ANSWER SECTION:
bloggt-in-braunschweig.de. 21599 IN    MX    10 s120.resellerdesktop.de

Wenn man also seinen MX auf den „echten“ Namen des Mailserver ändert, sind diese Expertenserver zufrieden und schicken einem ab sofort wieder reguläre TLS verschlüsselte EMails zu.

Man darf nur nicht vergessen, daß man bei einem Domainumzug auch den MX ändert, wenn der neue Mailserver anders heißt. Es ist also auch davon abhängig wie der Provider seine Umgebung betreibt.