Kategorien
Blog

Mail über Tor routen, ein Experiment

Ungestörte Mailkommunikation ist in den letzten Monaten schwierig geworden (d.h. eigentlich war sie das schon vorher aber wir wussten es nicht). Die Inhalte können wir verschlüsseln, aber inzwischen wissen wir, dass die Metadaten für die Überwacher fast genau so interessant sind. Wenn wenigstens beide an einer Kommunikation beteiligte Mailserver TLS nutzen, dann fällt es dem Lauscher schon schwerer, Adressen und Subject:-Zeile mitzulesen, er kann aber immernoch die IP-Verbindung zwischen den beiden Mailservern sehen. Gerade zwischen uns „Power-Usern“ mit eigenen Mailservern lassen sich dadurch praktisch alle persönlichen Verbindungen rekonstruieren.

Was aber, wenn wir diese Verbindung durch Tor schicken? Probieren wir mal aus, ob das überhaupt geht.

Als Ausgangssituation habe ich wie üblich an beiden Enden Debian GNU/Linux-Server mit Postfix als MTA und Tor — alles von Standard-Paketen installiert.

Empfang

Den empfangenden Mailserver als Tor Hidden-Service einzurichten ist einfach. Dazu muss nur ein Verzeichnis angelegt werden:

mkdir hiddenmailserver

… und in der Konfiguration der SMTP-Port freigeschaltet werden:

HiddenServiceDir /var/lib/tor/hiddenmailserver/
HiddenServicePort 25 127.0.0.1:25

Beim nächsten Start des Tor-Dienstes entsteht dann der neue Hidden-Hostname in der Datei hostname im vorher angegebenen Verzeichnis. Nachdem wir den wissen, können wir die Verbindung gleich testen (mit netcat und torsocks, einem Wrapper, der Bibliotheken zur Umleitung der Netzwerkverbindungen über Tor vorlädt):

ponos:~# torsocks nc -t u2bhrnyodeqtmlt2.onion 25
220 nyx.wazong.de ESMTP Postfix (Debian/GNU)
EHLO ich
250-nyx.wazong.de
250-PIPELINING
250-SIZE 102400000
250-VRFY
250-ETRN
250-STARTTLS
250-AUTH PLAIN LOGIN
250-AUTH=PLAIN LOGIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
QUIT
221 2.0.0 Bye
ponos:~#

Funktioniert.

Versand

Wie auch die meisten anderen Mail Transport Agents ist Postfix in der Lage, abhängig von der Zieladresse den Transportkanal zu wechseln. Der Mechanismus stammt von „früher“, als es aus Kostengründen noch üblich war, bestimmte Domains über einen anderen Weg als SMTP mit Mail zu beliefern (z.B. UUCP). Die einzelnen Transportkanäle sind Programme, die in einem Verzeichnis liegen. Wir erzeugen also ein Skript, das den smtp-Transportkanal mit torsocks aufruft:

#!/bin/bash
torsocks /usr/lib/postfix/smtp $@

… und Tragen es als tor-Transportkanal in der /etc/postfix/master.cf ein:

[...]
smtp      unix  -       -       -       -       -       smtp
tor       unix  -       -       -       -       -       tor
[...]

Dann schalten wir in der /etc/postfix/main.cf den Transport-Auswahlmechanismus ein:

[...]
transport_maps = hash:/etc/postfix/transport
[...]

…, schreiben unsere Tor-Konfiguration in die /etc/postfix/transport:

wazong.de tor:[u2bhrnyodeqtmlt2.onion]

…, und laden sie in den Mailserver:

cd /etc/postfix
postmap transport

Zum Test schicken wir eine Mail. Im Logfile des versendenden Mailservers sieht das so aus:

Nov 25 23:29:02 ponos postfix/smtp[20884]: 002A82A43B6: to=<dentaku@wazong.de>, 
                relay=u2bhrnyodeqtmlt2.onion[127.0.69.0]:25, delay=14,
                delays=0.06/0.09/12/1.5, dsn=2.0.0,
                status=sent (250 2.0.0 Ok: queued as 877A97240DF)

… und in den Headern der empfangenen Mail:

Received: from ponos.wazong.lan (localhost [127.0.0.1])                                   
        by nyx.wazong.de (Postfix) with ESMTP id 877A97240DF                              
        for <dentaku@wazong.de>; Mon, 25 Nov 2013 23:29:01 +0100 (CET)

Funktioniert.

Ausblick

All das ist natürlich im Moment nur im Proof-Of-Concept-Stadium. Es skaliert in dieser Form nämlich überhaupt nicht, weil auf jedem teilnehmenden Server alle anderen über Tor erreichbaren Domains in der Transport-Map stehen müssten. Postfix kann aber den Table-Lookup an ein externes Programm auslagern (Stichwort: tcp_table) — und das könnte wieder in einem verteilten System nachsehen, also z.B. nach einem bestimmten TXT-Record im DNS. Diese Abfrage müsste dann natürlich auch durch Tor gehen, weil wir sonst DNS-Leaks riskieren.

Außerdem eignet sich die Methode nicht für komplett anonymes Mailen, weil Informationen über den vorherigen Weg der Mail noch immer in den Headern stehen. Und sie unterläuft einen Teil der üblichen Anti-Spam-Maßnahmen (z.B. Greylisting oder SPF), weil die IP-Adresse des einliefernden Mailservers ja jetzt nicht mehr bekannt ist.

Es gibt also noch einiges an Hausaufgaben zu erledigen. Trotzdem: wenn Ihr Lust habt, baut die Sache nach und schickt eine Mail an mich über u2bhrnyodeqtmlt2.onion.

Kategorien
Blog

Vorratsdatenspeicherung. Wie geht das eigentlich?

Über die juristischen Aspekte der Vorratsdatenspeicherung wurde ja schon regelmäßig an verschiedenen Stellen geschrieben. Wer da noch irgendwelche Informationen braucht, der soll mal da nachlesen.

Ich bin aber nun einmal kein Jurist sondern Techniker, und ich mache mir deshalb ganz andere Gedanken. Deshalb blende ich mal die Frage des Sinns und der Rechtmäßigkeit aus und beschäftige mich nur mit der technischen Machbarkeit.

Welche Daten sollen wir Sammeln:

Nachdem erst Horrormeldungen über die Protokollierung jeder TCP/IP-Verbindung (oder sogar jedes Pakets) kursierten, hat man sich inzwischen auf eine Interpretation geeinigt, in der die gesammelten Daten sehr den ohnehin vorhandenen Logfiles ähneln. Von den Protokollpflichtigen Diensten betreibe ich auf meinem Server nur eMail. Da entstehen bei Versand und Empfang etwa diese Daten (die Mail geht von diesem WordPress-Blog an mich selbst):

Nov  2 17:00:52 charon postfix/pickup[12229]: DEDF9FC443A: uid=33 from=<www-data>
Nov  2 17:00:52 charon postfix/cleanup[14398]: DEDF9FC443A:
   message-id=<1e8ccd8056aded93f095b735e2d1373f@wazong.de>
Nov  2 17:00:52 charon postfix/qmgr[30704]: DEDF9FC443A:
   from=<www-data@wazong.de>, size=1154, nrcpt=1 (queue active)
Nov  2 17:00:52 charon postfix/local[14502]: DEDF9FC443A:
   to=<dentaku@wazong.de>, relay=local, delay=0,
   status=sent (delivered to command: procmail -a "$EXTENSION")
Nov  2 17:00:52 charon postfix/qmgr[30704]: DEDF9FC443A: removed

Beim Abruf diese:

Nov  2 16:08:54 charon imaplogin: LOGIN, user=dentaku, 
   ip=[::ffff:90.186.88.15], protocol=IMAP
[...]
Nov  2 16:45:17 charon imaplogin: LOGOUT, user=dentaku, 
   ip=[::ffff:90.186.88.15], headers=20200, body=2439620

Vergleichen wir das mal mit dem Gesetzesentwurf, wie er auf vorratsdatenspeicherung.de steht:

Anbieter von Diensten der elektronischen Post (E-Mail) speichern

  1. bei Versendung einer Nachricht die Kennung des elektronischen Postfachs und die Internetprotokoll-Adresse des Absenders sowie die Kennung des elektronischen Postfachs jedes Empfängers der Nachricht,
  2. bei Eingang einer Nachricht in einem elektronischen Postfach die Kennung des elektronischen Postfachs des Absenders und des Empfängers der Nachricht sowie die Internetprotokoll-Adresse der absendenden Telekommunikationsanlage,
  3. bei Zugriff auf das elektronische Postfach dessen Kennung und die Internetprotokoll-Adresse des Abrufenden,
  4. die Zeitpunkte der in den Nummern 1 bis 3 genannten Nutzungen des Dienstes nach Datum und Uhrzeit unter Angabe der zugrunde liegenden Zeitzone.

Ja, alles da.

Die Schwierigkeit wäre also eher entweder ein einheitliches Logformat einzuführen (lustig in diesem Zusammenhang, daß ausgerechnet der Webtraffic, für den es mit CLF einen Quasistandard gäbe, nicht bevorratsspeichert werden soll) oder für jedes Logformat einen Parser zu schreiben, der die gewünschten Daten extrahiert.

Platz:

Diverse Artikel haben ja schon größere Bedenken über die Menge der gespeicherten Daten geäußert. Diese Bedenken teile ich nur bedingt: natürlich kostet das alles Geld, die Preise für Speichermedien fallen aber so schnell, daß das keinen Provider in die Pleite treiben wird (kommt schon Leute, wohin speichert denn flickr die ganzen Bilder, selbst für unbezahlte Accounts?). Außerdem speichern die meisten Dienste die Daten ohnehin schon durch die ganz normalen Logfiles (siehe oben). Problematisch wird die Datenmenge erst bei der Auswertung (immer wieder lesenswert dazu: dieses Interview).

Wie kommen die Daten jetzt zu den Strafverfolgern:

Jetzt sind die Daten also vorgehalten, wie kommen die berechtigten Behörden denn jetzt dran? Dafür muß eine neue Serversoftware erstellt werden, an die auf alle Fälle hohe Sicherheitsanforderungen bestehen:

Einerseits darf natürlich nicht irgendein unberechtigter die Daten abrufen, es wird also eine X509/TLS-artige Schlüsselinfrastruktur benötigt. Damit kann sich die Behörde gegenüber dem Logfilesammler (auf Wunsch auch umgekehrt) ausweisen, und die Möglichkeit zur verschlüsselten Übertragung gibt’s bei vielen Implementationen auch gleich noch dazu.

Andererseits soll der Serverbetreiber natürlich möglichst auch nicht merken, daß die Daten eingesehen werden (denn er steckt ja vielleicht mit den bösen Buben unter einer Decke). An dieser Stelle wird es kompliziert, denn wenn auf der Vorratsdatenspeicherungsschnittstelle sonst nie was passiert, dann sieht der Administrator den Zugriff allein schon an den Datenvolumenauswertungen (insbesondere dann, wenn diese auf IP-Port-Basis aufgebrochen sind):

MRTG

Da hilft es nur, die Daten ganz langsam herunterzuladen — aber was ist „langsam“ genau?

Besser ist es, ständig (oder unregelmäßig) auf allen (oder zufälligen) angebundenen Servern Datenverkehr erzeugen, so wie es z.B. TOR macht, das ist aber durch hohe Übertragungskosten recht teuer.

Software:

Was wäre sonst noch zu wünschen?

Da die Logfiles doch eine beträchtliche Datenmenge beinhalten, die in dieser Form nur aufwendig durchsucht werden kann sollten die gewonnenen Daten in einer relationalen Datenbank mit guter Indexmöglichkeit abgelegt werden (sonst sieht der Betreiber die Abfrage an der Prozessorlast statt am Datenverkehr). Das erleichtert auch die Löschunggenau der Daten, deren Aufbewahrungspflicht abgelaufen ist.

Damit die neue Schnittstelle zur Abfrage nicht mit anderen Diensten kollidiert, sollte ihr am besten von der IANA offiziell einen Port zugewiesen werden (vgl. OpenVPN, die früher einfach Port 5000 benutzt haben — jetzt gehört ihnen „hochoffiziell“ Port 1194).

Aus den Problemen mit ELSTER sollte unser Land gelernt haben, daß es nicht gut ist, (Pflicht-)Software nur für ein Betriebssystem bereitzustellen. Wo man einer (achtung, Klischee) Werbeagentur mit reiner Maclandschaft vielleicht noch zumuten kann, sich für die elektronische Umsatzsteuervoranmeldung halt doch einen Windows-PC anzuschaffen, da ist die gesetzliche Zwangsumstellung aller Mail-, RADIUS-, VoIP- und …-Server auf eine einheitliche Plattform (z.B. Windows Server 2008, nur 64bit?) schlicht nicht durchführbar (wobei ich keine Prognosen darüber wage, ob es nicht trotzdem versucht wird). Anderenfalls würden sich die Provider der bösen Buben vielleicht durch möglichst exotische Betriebssysteme aus der Vorratsdatenspeicherungspflicht herausstehlen (z.B. MPE/iX?).

Abhilfe schafft hier nur der Vertrieb im Sourcecode (die Unterstützung von POSIX- und win32-API sollte hier fas alles abdecken) oder ein offengelegtes Protokoll, so daß verschiedene Implementationen von dritten erstellt werden können. In diesen beiden Fällen läßt es sich aber kaum zu verhindern, daß der behördliche Zugriff in der einen oder anderen Version aufgezeichnet wird — ein Dilemma, für das es keinen Ausweg gibt…

Die technisch saubere Lösung:

Es sei denn man dreht die Zugriffsrichtung um und überträgt die Daten ständig sobald sie anfallen. Dieser Trick löst elegant sowohl die Probleme des Speicherplatzes als auch des Mitlesens bei Zugriffen durch die Strafverfolgungsbehörden. Diese Variante fordert allerding uneingeschränktes Vertrauen in die Behörde, die sich dann im Besitz der Daten befindet (wobei der Unterschied zwischen Daten, die sich schon dort befinden und Daten, die bei Bedarf jederzeit abgerufen werden können eigentlich in der Praxis kaum ins Gewicht fällt).

Wir verlassen an dieser Stelle allerdings auch wieder die technischen Aspekte, drum höre ich hier auf.