Sichere Tunnel mit stunnel

Datenverkehr abzufangen und auszuwerten ist nicht schwer. Die Gefahr, dass Datenverkehr überwacht wird , ist beim privaten und gut bekannten Netzen überschaubar. In öffentlichen Netzen sieht das schon anders aus. Grundsätzlich sollte man allen Netzwerken, die man nicht selber administriert, wenig Vertrauen schenken. Das betrifft vor allem öffentliche WLAN Netze, Mobilfunknetze etc. Dementsprechend vorsichtig sollte man bei Verbindungen über diese Netzwerke sein. Es gibt diverse Mittel und Wege seine Datenkommunikation in solchen potenziell unsicheren Netzwerken zu schützen. Exemplarisch zu nennen ist das verschlüsselte VPN. Ein VPN ist generalisierter einsatzbar, da der gesamte Verkehr darüber geschickt und verschlüsselt werden kann. Ein SSL Tunnel, wie ich ihn hier vorstelle, ist da spezieller, ist aber einfacher einzurichten. In beiden Fällen benötigt man einen vertrauenswürdigen Endpunkt, an dem der Datenverkehr den Tunnel verlässt. Wer über ein unsicheres Netz surfen möchte, der sollte nach Möglichkeit nur Seiten mit HTTPS Unterstützung aufrufen. Die üblichen Verdächtigen, wie z.B. Online Banking, Webmail, Online Händler etc. bieten i.d.R. HTTPS an. Ebenso viele andere Seiten, aber eben nicht alle. Man muss immer daran denken https://... statt http://... einzugeben. Alternativ kann man dafür Browser Extensions, wie z.B. HTTPS Everywhere, nutzen.

Ich verwende seit einigen Jahren stunnel für den Aufbau eines verschlüsselten Tunnels durch unsichere Netze. Über einen solchen Tunnel lassen sich im Prinzip alle Arten von Datenverkehr schleusen. Zentraler Unterschied zu einem VPN: stunnel baut Tunnel pro Applikation auf. Für jede Anwendung bzw. jede Art von Verkehr muss ich einen eigenen Tunnel konfigurieren. stunnel agiert dabei als Wrapper zwischen Client und Server. stunnel nimmt Anfragen entgegen und schickt diese über einen verschlüsselten Tunnel zum Endpunkt. Dort verlässt der Verkehr den Tunnel und wird an den Client weitergeleitet. So sieht das Verfahren schematisch dargestellt aus:

Was brauche ich dafür?

- einen Rootserver mit Linux
- stunnel und Squid auf dem Rootserver
- stunnel auf dem Client (hier Windows)

Die Konfiguration von stunnel ist mehr als einfach und spiegelt den schematischen Aufbau wieder. Auf dem Client (hier Windows) sieht die Konfiguration wie folgt aus:

cert = blazilla-de-web.pem
socket = l:TCP_NODELAY=1
socket = r:TCP_NODELAY=1
client = yes
[Tunnel.Web]
accept=127.0.0.1:8080
connect=x.x.x.x:443

Der erste Eintrag gibt das zu nutzende Zertifikat an. stunnel bringt ein Zertifikat mit. Ich empfehle ein eigenes Zertifikat zu nutzen. Diese kann man käuflich erwerben, oder man nutzt eine eigene CA dafür.  Die beiden Zeilen, die mit "socket" beginnen, dienen dem Performancetuning. Anschließend wird stunnel noch mitgeteilt, dass es sich um einen Client handelt. Danch kommt die Definition des eigentlichen Tunnels. Die Konfiguration auf dem Server ist etwas aufwendiger, da hier zwei Applikationen ineinander greifen müssen. Beginnen wir mit der serverseitigen Konfiguration von stunnel:

cert = /etc/stunnel/blazilla-de-web.pem
CAfile = /etc/CA/ca.crt
sslVersion = all
options = NO_SSLv2
setuid = nobody
setgid = nobody
pid = /var/run/stunnel4/stunnel4.pid 
output = /var/log/stunnel4.log
debug = 4
syslog = no
socket = l:TCP_NODELAY=1
socket = r:TCP_NODELAY=1
verify = 2
[Tunnel.Web]
accept = x.x.x.x:443
connect = 127.0.0.1:8080

Mit "verify=2" lasse ich die Serverkomponente von stunnel das Zertifikat des Clients prüfen. Ist es valide, dann wird der Tunnel zugelassen. Andernfalls wird die Verbindung nicht zugelassen. Dazu verwendet die stunnel das CA Zertifikat und prüft das vom Client gelieferte Zertifikat. Keine 100%ige Sicherheit, aber etwas mehr als ein Feigenblatt. Daher nutze ich auch eine eigene CA. stunnel kann aber problemlos mit dem mitgelieferten Zertifikat genutzt werden. Die Anfragen werden dann vom Squid Proxy angenommen und verarbeitet. Aus logischer Sicht sind die Daten ab dem Eintritt in den Squid Proxy unverschlüsselt (sofern es sich nicht um nativen HTTPS Datenverkehr handelt). Der Proxy ist nur über 127.0.0.1 (localhost) erreichbar. Eine Authentifizierung findet nicht statt. Der Proxy dient nicht nur als Cache, sondern über den "Umweg" Proxy muss ich nur einen Tunnel konfigurieren. So kann ich den Datenverkehr aller Anwendungen, die in der Lage sind einen Proxy zu nutzen, über diesen einen Tunnel schicken. Die squid.conf ist sehr überschaubar gehalten, die interessanten Zeilen gibt es hier:

acl localhost src 127.0.0.1
http_access allow localhost
http_access deny all
icp_access deny all
htcp_access deny all
http_port 127.0.0.1:8080

Der Proxy lauscht nur auf 127.0.0.1 (localhost) und nimmt nur davon Anfragen entgegen. Um das Gesamtkonstrukt zu nutzen trage ich in meinem Browser einfach 127.0.0.1:8080 (siehe stunnel.conf des Clients) als Proxy ein. Alles was ein Überwacher sieht, ist eine Verbindung über 443/tcp zwischen zwei Rechnern. Was über diese Verbindung übertragen wird, sieht ein Überwacher nicht. Damit bin ich ein wenig sicherer in unsicheren Netzen unterwegs.

EDIT: Ich möchte an dieser Stelle zwei Ergänzungen einfügen, die Marko als Kommentar zu diesem Artikel abgegeben hat. Tunnel werden pro Port einer Applikation konfiguriert, nicht pro Applikation. Markos Ergänzung ist die technisch korrekte Aussage. Die zweite Ergänzung betrifft die Konfiguration der Client-Applikation. Mache ich hier Fehler, so geht der Verkehr möglicherweise nicht durch den Tunnel. Bei einem VPN habe ich andere Möglichkeiten (lokales Routing etc.) um den Verkehr zwangsweise durch einen VPN Tunnel zu leiten.