Fedora wird DoH nicht in Firefox aktivieren

Guten Nachrichten von Fedora. Wie wir so eben einer relevanten Fedora Mailingliste entnehmen konnten, planen die Fedora Entwickler das DoH in Firefox nicht zu aktivieren, wenn es kommt.

DNS over HTTPS in Firefox

Das Thema hat ganz schön für Wellen gesorgt. Ohne mich zu wiederholen, ist die Essenz über DoH, daß es vom Prinzip her ok ist, aber eben durch die Zentralisierung im Firefox auf Cloudflare so nicht akzeptabel ist. Da der Bundesdatenschutz ähnliche Bedenken gezeigt hat, wie sie auch mir und Anderen gekommen sind, würde das in Europa für Mozilla vermutlich nicht besonders gut ausgehen, um nicht zu sagen, daß es ein sehr teures Experiment würde.

Ein Fedora Entwickler bekundete in der ML dann auch, daß es in der Form nicht defaultmäßig aktiviert sein wird. Zieht  man sich aber Firefox von der Mozillaseite direkt, z.b. wegen einer ESR Version, wäre das natürlich anders.

Ich für meinen Teil sage, daß jemand, der am DNS rumspielt, extrem viel Ahnung davon haben sollte, was DNS für alle bedeutet, um sinnvolle Entscheidungen zu treffen. Mozilla und Cloudflare zähle ich jetzt nicht zu dem Kreis, sonst wäre diese Entscheidung so nicht gefallen. Da ich das Thema erst heute in einem 90 Minütigen Vortrag mal von mehreren Seiten beleuchtet habe, kann ich sagen, daß so „simple“ der Dienst auch erscheinen mag, alle nachträglichen Security Erweiterungen sind daran gescheitert. DNS SEC z.b. hat zwar für Vertrauen in das Ergebnis gesorgt, ist aber auch nicht in allen Ecken und Enden der Server und Desktopanwendungen angekommen. Man mag es nicht glauben, aber das Fedora Repo kennt gerade mal eine Handvoll Pakete und die meisten davon sehen aus, als wenn es nur Teile ein und desselben Programms sind.

DNS-over-TLS, was technisch DNS-over-HTTPS sehr nahe kommen wird, ist auch so ein Krisenfall. Die Ursache dafür liegt darin, daß gute Krypto immer bedeutet, daß mehr in Aufwand, Rechenleistung,Zeit und Datengröße investiert werden muß, was es insgesamt teuer und langsam macht. Das wollte Mozilla mit dem Alleingang vermutlich vermeiden, aber dafür die Privatsphäre opfern geht ja mal gar nicht. Aber vielleicht meinten sie das ja auch ironisch, weil die Verschlüsselung sollte ja genau das verbessern, was es faktisch natürlich nicht tut 🙂

Gegen die Idee, daß auch der Inhalt von DNS gegen abhören gesichert ist, spricht außer der Rechenleistung, dem Keymanagement, der Datenblockgröße eigentlich nichts.  Allerdings habe ich so meine Zweifel, ob das in den 1 $US IoT Chips jemals sauber implementiert sein wird.

Bleibt nur zu hoffen, daß das Ziel Encrypted DNS irgendwann mal funktioniert.

Wenn PHP nicht mehr ausgeführt wird

Wenn man einen Linux Webserver betreibt, der normalerweise UTF-8 benutzt, und ein Windowsfan speichert in seinem Lieblingstexteditor die PHP Datei ab, dann kann das voll in die Hose gehen.

Windows UTF-16LE in PHP Skripten

So geschehen bei einem Projekt das ich für Freunde betreue. Eine klitzekleine Anpassung an einem Textblock führte dazu, daß der Windostexteditor der Wahl, statt dem vorgefundenen UTF-8, den Text als Windows Hausformat UTF-16LE abspeicherte.

Merken tut man das daran, daß man ums verrecken alles richtig im Webserver eingestellt hat, aber das PHP als HTML ausgegeben wird. Da wird sogar der PHP Interpreter korrekt aufgerufen, aber nicht mal der kann das Script korrekt als PHP erkennen und gibt es dann einfach als Text aus. Weil es keinen PHP Fehler gibt, ohne PHP auch kein Wunder, gibt es auch keine Fehlermeldung im Apachelogfile dazu.

Ihr könnt die mit vi , Gedit, Fokuswriter oder einem beliebigen anderen Editor aufmachen, keiner von denen wird Euch sagen, daß der Zeichensatz UTF-16LE ist und es klammheimlich genauso wieder abspeichern. Das PHP Script funktioniert dann einfach trotzdem nicht.

Des Rätsels Lösung

Wenn Ihr also mal vor einem Rätsel steht, wieso alle anderen PHP Scripte laufen, nur das eine nicht, könnte Euch das helfen:
1. mit „file filename.php“ den Typ bestimmen:

So müßte es aussehen:

camel.php: PHP script, UTF-8 Unicode (with BOM) text, with CRLF line terminators

So könnte es aussehen:

camel.php: Little-endian UTF-16 Unicode text, with CRLF, CR line terminators

2. So behebt Ihr es:

iconv -c -f UTF16LE -t UTF-8 < camel.php >camel2.php

Danach funktioniert das Script wieder und Ihr könnt dem Schuldigen die Ohren langziehen gehen 😉