OMG des Tages: Fulldisclosure ML bietet kein TLS an

Nicht das man es brauchen würde, aber in 2019 darf man doch von einer Securityliste erwarten, daß deren Mailserver TLS kann, oder? Nicht so bei NMAP.

seclists.org Mailserver bietet kein TLS an

Gerade wollte ich das Duplicator Pro Advisory an die  FullDisclosure Mailingliste schicken, da mault doch glatt mein Mailserver, daß er die Mail nicht schicken könnte, weil der Empfänger TLS verweigert. Ein OMG war die Folge:

CheckTLS Confidence Factor for „fulldisclosure@seclists.org“: 0

MX ServerPrefAnswerConnectHELOTLSCertSecureFrom
ack.nmap.org
[45.33.49.119:25]
0OK
(69ms)
OK
(151ms)
OK
(68ms)
FAILFAILFAILOK
(357ms)

2019-09-27 21:23:52 1iDvqI-0005NU-Mw == fulldisclosure@seclists.org R=dnslookup T=remote_smtp defer (-38) H=ack.nmap.org [45.33.49.119]: a TLS session is required, but the server did not offer TLS support

Jetzt braucht man natürlich keine Verschlüsslung, wenn eh an eine öffentliche Mailingliste Veröffentlichungen schickt, aber da laufen auch private Mailinglisten drüber z.b. über Bugs in NMAP und die sollten ja wohl verschlüsselt ankommen, oder?

Es kommt mir so bekannt vor…

Besonders prekär für die Admins des NMAP Mailservers ist der Umstand, daß deren Mailserver sehr wohl TLS beim Senden von Emails kann, sonst kämen die Emails nicht bei uns an:

2019-09-26 08:54:08 1iDNfD-00060F-Mj <= fulldisclosure-bounces@seclists.org H=ack.nmap.org [45.33.49.119] P=esmtps X=TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256 CV=no S=21878 id=6e00195f-664f-1d1c-0fb6-1333992ad574@sec-consult.com

Die große Ähnlichkeit zum BSI CERT-Bund Mailserver macht es natürlich nicht besser: BSI aktualisiert Mailserver auf TLS 1.2.. ABER .

Ich seh schon, mit dem TLS Gate habe ich noch auf Jahre jede Menge Spaß fürs Blog 😀

Hinweis: Duplicator Pro <= 1.3.14 hat eine fiese IFDC Schwachstelle. Bitte updaten!

Linux – Cannot find device „tun0“

Ihr wollt z.B. mit SSH ein VPN und dazu einen Tunnel aufbauen, könnt aber nicht, weil Ihr diese Fehlermeldung bekommt: Cannot find device „tun0“ ? Ja, na dann auf ins neue Netstackventure!

Tunneldevice mit Linux nutzen

Ihr erinnert Euch noch an den Artikel: SSH VPN mit den iproute2 Tools ? Da haben wir ein SSH VPN aus dem Hut gezaubert und mußten dazu mit Tunneln arbeiten. Da hat sich einiges getan, deswegen müssen wir uns leider erneut damit befassen.

Schritt 1 und 2 sind klar, ein TUN Modul laden und Device erzeugen, aber was ist das…?? :

[root@backup ~]# modprobe tun
[root@backup ~]# ip link set tun0 up;
Cannot find device "tun0"

Cannot find device „tun0““ ist ein echter Kopfschmerzenerzeuger, weil so unnötig. Also das Modul „tun“ ist wie der Name nahelegt, für Tunneldevices zuständig. Es sollte eigentlich ein Tunneldevice tun0 erzeugen, tuts aber nicht und mit normalen Fedora Bordmitteln ist das auch nicht so einfach machbar.

Ihr braucht das Paket „tunctl“ ( dnf install tunctl ) und müßt Euch erstmal ein tundevice bauen:

tunctl -t tun0

Wie man sieht, ist das nicht schwer. Jetzt, wo das Gerät persistent gemacht wurde, seht Ihr an der Ausgabe von dem Befehl oben, klappt das dann auch mit dem „ip link set tun0 up“ und Ihr könnt der Anleitung aus SSH VPN mit den iproute2 Tools weiter folgen. Ihr müßt nur dran denken, daß Ihr das auch bei Euch auf dem Client PC macht und nicht nur auf dem Server.

Eine Bewertung, wieso das nicht mehr defaultmäßig bei Fedora dabei ist, verkneif ich mir, es wird merkwürdige Gründe haben 🙂

Wieso DoH nicht gut für die Privatsphäre des User ist.

Mozilla will ja ab sofort in den USA DoH als Testballon starten. Der Rest der Welt soll später folgen. Ziel der Aktion ist es, daß DNS Anfragen nicht mehr von DNS-Servern wie Bind beantwortet werden, sondern, daß Webserver die DNS Informationen für den anfragenden Clienten per HTTPS beantworten. Bleibt die Frage, was und woher tunnelt er die Daten?

„Wäre es nicht die Wirklichkeit, es wäre ein Bestseller“

Ganz kurz umrissen, wird Firefox per HTTPS  die Cloudflare DoH-Webserver fragen, die holen sich DNS Antworten dann vom Cloudflare DNS-Servern und der von den korrekten  DNS-Servern. In der Endstufe war geplant, daß die besuchten Webserver die DNS Anfragen selbst beantworten, so daß wieder eine dezentrale Struktur entsteht.

Mozilla möchte damit erreichen, daß DNS Anfragen nicht mehr im Klartext durchs Netz gehen, weil ein Angreifer die bisherige DNS Information mit einer MITM-Attacke angreifen kann ( Man-in-the-Middle ). Nobel, aber sollte DNSSEC nicht genau das Problem lösen?

Und wer sagt uns, daß Cloudflare die Daten nicht manipuliert? Millionen von DNS-Webanfragen  würden bei Cloudflare durchgehen und wären so leichteste Beute für einen, der nicht will, daß Domain X erreichbar ist, oder Inhalt Y hat.

Wer schützt uns vor Zensur?

Das DNS System, denn es gibt Millionen DNS Server und Caches aus denen ich mir die Informationen zu einer Domain ziehen kann, inklusive der Autoritären-DNS des Domaininhabers.

Wie jetzt, Eurer Provider blockt externe DNS und erlaubt Euch nur seine eigenen DNS-Caches zu benutzen?

Lest das hier: UDP Traffic per SSH tunneln

Und wie sieht es mit dem Datenschutz aus?

Firefox sendet jetzt private Informationen in einem Ausmaß an ein amerikanisches Unternehmen, daß daraus leicht Profile bilden kann, und der Datenschutz sieht zu? Glaube ich kaum.

Was wollte Mozilla doch gleich mit DoH schützen?

Die Privatsphäre, ach ja, kommen wir mal dazu. Korrekt ist, daß ein DNS Betreiber in den Logfiles, so er denn welche erstellt, nachsehen kann, welche IP welche Domain hat auflösen wollen. Cloudflare kann das auch, niemand hindert sie daran. D.b. für die Privatsphäre ist es mit Cloudflare als derzeit einzigem DoH Betreiber, noch schlechter bestellt, als jetzt.

Derzeit kann ich mir aussuchen, welchen der vielen DNS Server ich frage, oder ob ich mir vielleicht gleich selbst einen eigenen DNS Cache hinstelle, der nur für mich arbeitet. Mit DoH geht das nicht mehr, außer ich betreibe einen DoH Server. Mangels Masse, eher unrealistisch derzeit.

Wie man seine eigenen DNS Anfragen auf möglichst viele DNS Server verteilt um bei keinem der DNS Betreiber ein sinnvolles Profil zu hinterlassen, findet Ihr in diesem früheren Beitrag von mir : Linux – DNS-DeTracking mit nscd

Fazit

DoH ist derzeit die leibhaftige Vision einen dystopische Zukunft, in der alle User bei einem einzigen Anbieter sind, so wie in den Terranauten, alle beim Energiekonzern Energie beziehen, vom Lebensmittelkonzern ernährt werden und auch ansonsten von Monopolen beherrscht werden. DoH ist im jetzigen Zustand nur eins: nicht akzeptabel.

Eine (von vielen) Alternative

DNS-Anfragen per TLS manipulationssicher zu machen, ist ok. Aber, wozu eigentlich der HTTP Overhead? Reicht es nicht, wenn Bind einen TLS Port bereitstellen würde und der zuerst gefragt wird? Das hätte zur Folge, daß der Server durch den SNI im TLS auch domainbasierte Zertifikate benutzen kann, also auch beweisen könnte, daß er er ist und nicht ein MITM-Angreifer.

Zugegeben, der Overhead dabei wäre aufgrund der möglichen Schlüssellängen ziemlich heftig, aber dafür könnte man z.b. kleinere, mit dem Zertifikat des Domaininhabers signierte, DNS Zertifikate einsetzen. Lets Encrypt könnte das z.B. gleich mit erzeugen und ausliefern, wenn das Hauptzertifikat erzeugt wird.

DNS-Caches könnte man dann gleich daran erkennen, daß sie ein Zert anbieten, daß nicht zum Domainnamen paßt. Anhand der bekannten Root–Zertifikate könnte man auch gleich die Ketten verifizieren. Es ist etablierte Technik, es gibt etablierte Bibliotheken, systemische Schwachstellen sind bekannt, und durch die kürzeren Zerts wäre der Performanceeinbruch nicht so stark. Würde man zudem mehrere DNS Anfragen in einer TCP Sesssion durchführen, so denn sinnvoll möglich, würde der Overhead weiter sinken.

Es gibt also Methoden, die eine derzeit zentrale Instanz wie Cloudflare nicht benötigen, warum also  dann DoH durchziehen?  In einer dystopischen Zukunft wären die Gründe wie immer: Machtgeilheit, Geldgier und, daß eine Gruppe von wackeren Helden den Schurken in einem effektvollen Kampf schlagen kann.

In dem Sinn: „Avengers, Assemble!“