Wie ihr alle wisst, sieht es mit SSL/TLS momentan auf der Fritz!Box bisher nicht gerade rosig aus. Stunnel bietet hier eine einfache Lösung alle Dienste, die selbst nicht dazu in der Lage sind Verbindungen zu verschlüsseln, zu "tunneln" und damit abzusichern.
Weitere Informationen gibt es auf der Stunnel Homepage.
Mit Stunnel kann man beispielsweise den Push-Service, der ja durchaus sehr persönliche Daten verschickt, und die DynDNS Updates per SSL absichern. Aber auch ein sicherer Zugriff von Außen auf Dienste im eigenen Heimnetzwerk kann damit geschaffen werden.
[size=+1]Haftungsausschluss[/size]
Natürlich übernehme ich keinerlei Verwantwortung für Probleme oder Schäden die direkt oder indirekt durch die Modifikation oder die hier enthaltenen Anleitungen enstehen können.
[size=+1]History[/size]
08.07.08
Anleitung für Server-Modus mit Client-Authentifikation.
02.06.08
Dokumentation upgedatet für die neueste Version.
10.01.07 Version 0.1b
- CGI hinzugefügt
- Start- und Konfigurations-Scripte korrigiert und verbessert
- ACHTUNG: habe soeben die Abhängigkeit zur SSL Library (libssl.so) wieder hinzugefügt, weil diese entgegen meiner Annahme doch nicht so ohne weiteres statisch eingelinkt werden. Die statisch gelinkten binaries sind im nächsten Beitrag zu finden.
[size=+1]Installation[/size]
- Voraussetzungen:
ds-mod 0.2.9 (Daniel) / ds-mod 0.2.9_26-12 (Oliver): Hierfür werden spezielle Patches benötigt (siehe Anhänge)
ds-mod 0.2.9_26-13, freetz: Stunnel ist komplett integriert und kann direkt beim Build-Vorgang ausgewählt werden.
[size=+1]Allgemeines[/size]
Stunnel kennt 2 Betriebs-Modi, die wie folgt beschrieben funktionieren. Für weitere Infos bitte die Stunnel Homepage konsultieren
- Client-Modus:
Im Client-Modus werden unverschlüsselte Verbindungen entgegengenommen und per SSL verschlüsselt. Das bedeutet, der Client-Modus setzt voraus, dass der Remote-Dienst den man anspricht SSL versteht.
Die Server-Authentizität wird momentan nicht geprüft (verify Option) ! Dieser Modus kann bspw. eingesetzt werden, um den Push-Service mit TLS/SSL abzusichern, damit E-Mails nicht über eine unverschlüsselte Verbindung verschickt werden.
- Server-Modus:
Im Server-Modus nimmt Stunnel SSL verschlüsselte Verbindungen entgegen und leitet diese dann (lokal) unverschlüsselt weiter. Er eignet sich also bspw. dafür einen verschlüsselten SSL geschützten Zugang von Außen auf die freetz Web-Oberfläche zu ermöglichen.
Verwendet man zusätzlich die Option zur Client-Authentifizierung, kann man eine sichere Zugriffs-Kontrolle realisieren.
[size=+1]Konfiguration[/size]
Damit Stunnel läuft, muss man entsprechende Dienst-Einträge hinzufügen. Unter freetz geht das einfach über die Web-Oberfläche.
Für jeden Dienst den man tunneln will, legt man einen Eintrag an.
Das obige Beispiel zeigt, wie man den Push-Service der Fritz!Box mit TLS absichert, die DynDNS Updates per SSL und die freetz Web-Config von Außen zugreifbar per HTTPS macht. Folgendes ist dabei noch zu beachten:
Push-Service mit TLS:
Der Mail-Server muss in diesem Beispiel SMTP mit TLS unterstützen (STARTTLS).
Bei den Push-Service Einstellungen trägt man dann folgende Daten ein:
Unterstützt der SMTP-Server nur SSL über Port 463, trägt man das entsprechend ein und lässt den "protocol" Eintrag weg.
DynDNS Updates mit HTTPS:
Für DynDNS Updates über HTTP trägt man folgende Einstellungen ein:
Die Update-URL kann sich unter Umständen von Zeit zu Zeit ändern, wenn DynDNS die API ändert. Eine API-Dokumentation gibt es hier.
freetz Web-Config über HTTPS: (Beispiel für den Server-Modus)
Dieses Beispiel zeigt exemplarisch, wie man den Server-Modus verwendet. Im Server-Modus braucht man einen öffentlichen und einen privaten Schlüssel für den Server, damit der Zugriff funktioniert. Diese können mit OpenSSL extern angelegt werden und dann über die Konfigurations-Oberfläche eingetragen werden.
Die Zertifikats-Kette kann für den öffentlichen Schlüssel und die ihm übergeordneten CAs verwendet werden (es sei denn man verwendet Client-Authentifizierung), die man einfach nacheinander einträgt. Bei den Stunnel Dienst-Einträgen kann diese Datei dann mit "/tmp/flash/.stunnel/certs.pem" angesprochen werden.
Analoges gilt für den privaten Schlüssel, der nach dem Speichern unter "/tmp/flash/.stunnel/key.pem" zu finden ist.
Abschließend muss man noch eine Port-Weiterleitung eingerichtet werden, damit der Port 443 in diesem Beispiel von Außen erreichbar ist.
[size=+1]Server-Modus mit Client-Authentifikation[/size]
Durch den Server-Modus mit Client-Authentifikation kann man Dienste die auf TCP basieren sicher von Außen ins eigene LAN tunneln. Ein Beispiel ist die Web-Konfiguration der Fritz!Box oder etwa auch die freetz Konfigurations-Oberfläche.
Wie funktioniert das ?
Verbindet sich ein Client zum Server, wird die Verbindung per SSL verschlüsselt und der Server fordert vom Client ein Zertifikat zur Authentifizierung an (ähnlich einer Passwort-Abfrage). Kann der Client dies nicht liefern, wird die Verbindung automatisch getrennt. Das Verfahren funktioniert also analog zur Public-Key-Authentifizierung bei SSH.
Dieses Verfahren ist deutlich sicherer als die von AVM integrierte "Fernwartung" der Fritz!Box
Schritt für Schritt Anleitung:
0. Wie Oben (Server-Modus ohne Client-Authentifizierung) beschrieben sollte der Server bereits ein Zertifikat samt zugehörigem Private-Key besitzen. Im Gegensatz zum Server-Modus ohne Authentifizierung müssen jedoch beide unter "Einstellungen - Stunnel: Private Key" eingetragen sein, weil die Zertifikat-Kette für die Client-Zertifikate benötigt wird.
1. Private-Key und Zertifikat für den Client erstellen. Dies läuft analog zum Erstellen des Zertifikats für den Server ab. Trotzdem werde ich die Schritte hier noch einmal exemplarisch auflisten:
2. PKCS12 Datei erstellen. PKCS12 Dateien sind Zertifikate im binären Format, die sowohl den Public-Key, Private-Key als auch das Wurzel-Zertifikat enthalten. Die meisten Programme (Firefox, IE, ...) können Dateien in diesem Format problemlos direkt importieren.
3. Dienst-Eintrag für Stunnel unter Freetz erstellen (Einstellungen - Stunnel: services):
Zu beachten ist hier, dass in der Datei "/tmp/flash/.stunnel/key.pem" sowohl der Private- als auch der Public-Key des Servers enthalten sein muss. Die Datei kann über "Einstellungen - Stunnel: Private Key" bearbeitet werden. Gegebenenfalls also den Inhalt aus "Einstellungen - Stunnel: Certificate Chain" verschieben.
Unter "Einstellungen - Stunnel: Certificate Chain" trägt man den Inhalt der Datei "client.crt" ein (nicht den Private-Key des Clients). In dieser Datei landen alle Zertifikate der Clients denen man Zugriff gewähren will.
4. PKCS12 Datei auf dem Client importieren. Bei Firefox kann man das unter "Extras - Einstellungen - Erweitert - Zertifikate anzeigen - Importieren" machen. Dort wählt man dann die erstellte Datei "client-cert.p12" aus.
Macht man diesen Schritt nicht, zeigt einem Firefox folgende Fehlermeldung an, weil ihm das Zertifikat zur Authentifizierung fehlt (u.U. natürlich mit anderer IP/Port):
5. Abschließend muss man stunnel nur noch neu starten und eventuell Port-Weiterleitungen einrichten (VirtualIP oder ar7.cfg), damit der Dienst von Außen erreichbar ist.
Wenn alles geklappt hat und man jetzt versucht eine Verbindung aufzubauen, zeigt z.B. Firefox beim Aufruf der Seite diesen Dialog an:
[size=+1]FAQ[/size]
- Kann man auch Dienste tunneln, die UDP erfordern ?
+ Nein, es wir ausschließlich TCP unterstützt.
- Kann man auf FTP-Server im LAN von Außen im Server-Modus über Stunnel zugreifen ?
+ Nein. FTP erfordert mehrere TCP Ports, was nicht von Stunnel unterstützt wird. Dafür kann man einen dynamischen SSH Tunnel oder eine VPN Lösung verwenden.
- Mir reichen die beiden Zertifikat-Dateien die die Web-Oberfläche anlegt nicht.
+ Selbstverständlich können an beliebiger Stelle (bspw. auf einem USB-Stick) eigene Dateien angelegt werden und der Pfad dann entsprechend in die Stunnel-Config eingetragen werden. Die beiden Dateien, die man über die Web-Oberfläche anlegen kann sind nur zur leichteren Konfiguration vorhanden.
- Wie kann ich die Verbindung zu einem Stunnel Server testen ?
+ OpenSSL bietet direkt die Möglichkeit SSL Verbindungen zu testen mit folgendem Kommando
Binaries für OpenSSL sind hier zu finden.
[size=+1]Was noch zu tun ist[/size]
-
[size=+1]Bekannte Fehler[/size]
- Beim original ds-mod 0.2.9 von Daniel (kernel 2.4) wird der Prozess-Status von stunnel auf der Weboberfläche nicht richtig angezeigt. Das liegt an der älteren Busybox-Version von 1.2.x, die den "-EXIT" Parameter für kill nicht versteht.
[size=+1]Anmerkungen und Hinweise[/size]
- Das stunnel Paket ist seit Version ds-0.2.9_26-13 bereits in das dsmod integriert und muss nicht mehr von Hand eingefügt werden ! Vielen Dank an Oliver.
- Alexander hat eine Anleitung zum HTTPS Zugriff von Außen im dsmod Wiki geschrieben.
---
Weitere Informationen gibt es auf der Stunnel Homepage.
Mit Stunnel kann man beispielsweise den Push-Service, der ja durchaus sehr persönliche Daten verschickt, und die DynDNS Updates per SSL absichern. Aber auch ein sicherer Zugriff von Außen auf Dienste im eigenen Heimnetzwerk kann damit geschaffen werden.
[size=+1]Haftungsausschluss[/size]
Natürlich übernehme ich keinerlei Verwantwortung für Probleme oder Schäden die direkt oder indirekt durch die Modifikation oder die hier enthaltenen Anleitungen enstehen können.
[size=+1]History[/size]
08.07.08
Anleitung für Server-Modus mit Client-Authentifikation.
02.06.08
Dokumentation upgedatet für die neueste Version.
10.01.07 Version 0.1b
- CGI hinzugefügt
- Start- und Konfigurations-Scripte korrigiert und verbessert
- ACHTUNG: habe soeben die Abhängigkeit zur SSL Library (libssl.so) wieder hinzugefügt, weil diese entgegen meiner Annahme doch nicht so ohne weiteres statisch eingelinkt werden. Die statisch gelinkten binaries sind im nächsten Beitrag zu finden.
[size=+1]Installation[/size]
- Voraussetzungen:
ds-mod 0.2.9 (Daniel) / ds-mod 0.2.9_26-12 (Oliver): Hierfür werden spezielle Patches benötigt (siehe Anhänge)
ds-mod 0.2.9_26-13, freetz: Stunnel ist komplett integriert und kann direkt beim Build-Vorgang ausgewählt werden.
[size=+1]Allgemeines[/size]
Stunnel kennt 2 Betriebs-Modi, die wie folgt beschrieben funktionieren. Für weitere Infos bitte die Stunnel Homepage konsultieren
- Client-Modus:
Im Client-Modus werden unverschlüsselte Verbindungen entgegengenommen und per SSL verschlüsselt. Das bedeutet, der Client-Modus setzt voraus, dass der Remote-Dienst den man anspricht SSL versteht.
Die Server-Authentizität wird momentan nicht geprüft (verify Option) ! Dieser Modus kann bspw. eingesetzt werden, um den Push-Service mit TLS/SSL abzusichern, damit E-Mails nicht über eine unverschlüsselte Verbindung verschickt werden.
- Server-Modus:
Im Server-Modus nimmt Stunnel SSL verschlüsselte Verbindungen entgegen und leitet diese dann (lokal) unverschlüsselt weiter. Er eignet sich also bspw. dafür einen verschlüsselten SSL geschützten Zugang von Außen auf die freetz Web-Oberfläche zu ermöglichen.
Verwendet man zusätzlich die Option zur Client-Authentifizierung, kann man eine sichere Zugriffs-Kontrolle realisieren.
[size=+1]Konfiguration[/size]
Damit Stunnel läuft, muss man entsprechende Dienst-Einträge hinzufügen. Unter freetz geht das einfach über die Web-Oberfläche.
Für jeden Dienst den man tunneln will, legt man einen Eintrag an.
Das obige Beispiel zeigt, wie man den Push-Service der Fritz!Box mit TLS absichert, die DynDNS Updates per SSL und die freetz Web-Config von Außen zugreifbar per HTTPS macht. Folgendes ist dabei noch zu beachten:
Push-Service mit TLS:
Der Mail-Server muss in diesem Beispiel SMTP mit TLS unterstützen (STARTTLS).
Bei den Push-Service Einstellungen trägt man dann folgende Daten ein:
Code:
SMTP-Server "Benutzerdefiniert"
Name des SMTP-Servers "127.0.0.1"
DynDNS Updates mit HTTPS:
Für DynDNS Updates über HTTP trägt man folgende Einstellungen ein:
Code:
Dynamic DNS-Anbieter: "Benutzerdefiniert"
Update-URL "http://127.0.0.1:9101/nic/update?system=dyndns&hostname=<domain>&myip=<ipaddr>&wildcard=NOCHG"Die Update-URL kann sich unter Umständen von Zeit zu Zeit ändern, wenn DynDNS die API ändert. Eine API-Dokumentation gibt es hier.
freetz Web-Config über HTTPS: (Beispiel für den Server-Modus)
Dieses Beispiel zeigt exemplarisch, wie man den Server-Modus verwendet. Im Server-Modus braucht man einen öffentlichen und einen privaten Schlüssel für den Server, damit der Zugriff funktioniert. Diese können mit OpenSSL extern angelegt werden und dann über die Konfigurations-Oberfläche eingetragen werden.
Die Zertifikats-Kette kann für den öffentlichen Schlüssel und die ihm übergeordneten CAs verwendet werden (es sei denn man verwendet Client-Authentifizierung), die man einfach nacheinander einträgt. Bei den Stunnel Dienst-Einträgen kann diese Datei dann mit "/tmp/flash/.stunnel/certs.pem" angesprochen werden.
Analoges gilt für den privaten Schlüssel, der nach dem Speichern unter "/tmp/flash/.stunnel/key.pem" zu finden ist.
Abschließend muss man noch eine Port-Weiterleitung eingerichtet werden, damit der Port 443 in diesem Beispiel von Außen erreichbar ist.
[size=+1]Server-Modus mit Client-Authentifikation[/size]
Durch den Server-Modus mit Client-Authentifikation kann man Dienste die auf TCP basieren sicher von Außen ins eigene LAN tunneln. Ein Beispiel ist die Web-Konfiguration der Fritz!Box oder etwa auch die freetz Konfigurations-Oberfläche.
Wie funktioniert das ?
Verbindet sich ein Client zum Server, wird die Verbindung per SSL verschlüsselt und der Server fordert vom Client ein Zertifikat zur Authentifizierung an (ähnlich einer Passwort-Abfrage). Kann der Client dies nicht liefern, wird die Verbindung automatisch getrennt. Das Verfahren funktioniert also analog zur Public-Key-Authentifizierung bei SSH.
Dieses Verfahren ist deutlich sicherer als die von AVM integrierte "Fernwartung" der Fritz!Box
Schritt für Schritt Anleitung:
0. Wie Oben (Server-Modus ohne Client-Authentifizierung) beschrieben sollte der Server bereits ein Zertifikat samt zugehörigem Private-Key besitzen. Im Gegensatz zum Server-Modus ohne Authentifizierung müssen jedoch beide unter "Einstellungen - Stunnel: Private Key" eingetragen sein, weil die Zertifikat-Kette für die Client-Zertifikate benötigt wird.
1. Private-Key und Zertifikat für den Client erstellen. Dies läuft analog zum Erstellen des Zertifikats für den Server ab. Trotzdem werde ich die Schritte hier noch einmal exemplarisch auflisten:
Code:
openssl genrsa -des3 -out client.key 1024
openssl req -new -key client.key -out client.csr
openssl x509 -req -days 365 -in client.csr -signkey client.key -out client.crt2. PKCS12 Datei erstellen. PKCS12 Dateien sind Zertifikate im binären Format, die sowohl den Public-Key, Private-Key als auch das Wurzel-Zertifikat enthalten. Die meisten Programme (Firefox, IE, ...) können Dateien in diesem Format problemlos direkt importieren.
Code:
openssl pkcs12 -export -in client.crt -inkey client.key -name "Freetz Client-Zertifikat" -out client-cert.p123. Dienst-Eintrag für Stunnel unter Freetz erstellen (Einstellungen - Stunnel: services):
Code:
[HTTPS Web-Interface]
client = no
verify = 3
CAfile = /tmp/flash/.stunnel/certs.pem
cert = /tmp/flash/.stunnel/key.pem
key = /tmp/flash/.stunnel/key.pem
accept = 7448
connect = 127.0.0.1:80Zu beachten ist hier, dass in der Datei "/tmp/flash/.stunnel/key.pem" sowohl der Private- als auch der Public-Key des Servers enthalten sein muss. Die Datei kann über "Einstellungen - Stunnel: Private Key" bearbeitet werden. Gegebenenfalls also den Inhalt aus "Einstellungen - Stunnel: Certificate Chain" verschieben.
Unter "Einstellungen - Stunnel: Certificate Chain" trägt man den Inhalt der Datei "client.crt" ein (nicht den Private-Key des Clients). In dieser Datei landen alle Zertifikate der Clients denen man Zugriff gewähren will.
4. PKCS12 Datei auf dem Client importieren. Bei Firefox kann man das unter "Extras - Einstellungen - Erweitert - Zertifikate anzeigen - Importieren" machen. Dort wählt man dann die erstellte Datei "client-cert.p12" aus.
Macht man diesen Schritt nicht, zeigt einem Firefox folgende Fehlermeldung an, weil ihm das Zertifikat zur Authentifizierung fehlt (u.U. natürlich mit anderer IP/Port):
5. Abschließend muss man stunnel nur noch neu starten und eventuell Port-Weiterleitungen einrichten (VirtualIP oder ar7.cfg), damit der Dienst von Außen erreichbar ist.
Wenn alles geklappt hat und man jetzt versucht eine Verbindung aufzubauen, zeigt z.B. Firefox beim Aufruf der Seite diesen Dialog an:
[size=+1]FAQ[/size]
- Kann man auch Dienste tunneln, die UDP erfordern ?
+ Nein, es wir ausschließlich TCP unterstützt.
- Kann man auf FTP-Server im LAN von Außen im Server-Modus über Stunnel zugreifen ?
+ Nein. FTP erfordert mehrere TCP Ports, was nicht von Stunnel unterstützt wird. Dafür kann man einen dynamischen SSH Tunnel oder eine VPN Lösung verwenden.
- Mir reichen die beiden Zertifikat-Dateien die die Web-Oberfläche anlegt nicht.
+ Selbstverständlich können an beliebiger Stelle (bspw. auf einem USB-Stick) eigene Dateien angelegt werden und der Pfad dann entsprechend in die Stunnel-Config eingetragen werden. Die beiden Dateien, die man über die Web-Oberfläche anlegen kann sind nur zur leichteren Konfiguration vorhanden.
- Wie kann ich die Verbindung zu einem Stunnel Server testen ?
+ OpenSSL bietet direkt die Möglichkeit SSL Verbindungen zu testen mit folgendem Kommando
Code:
openssl s_client -connect IP:Port[size=+1]Was noch zu tun ist[/size]
-
[size=+1]Bekannte Fehler[/size]
- Beim original ds-mod 0.2.9 von Daniel (kernel 2.4) wird der Prozess-Status von stunnel auf der Weboberfläche nicht richtig angezeigt. Das liegt an der älteren Busybox-Version von 1.2.x, die den "-EXIT" Parameter für kill nicht versteht.
[size=+1]Anmerkungen und Hinweise[/size]
- Das stunnel Paket ist seit Version ds-0.2.9_26-13 bereits in das dsmod integriert und muss nicht mehr von Hand eingefügt werden ! Vielen Dank an Oliver.
- Alexander hat eine Anleitung zum HTTPS Zugriff von Außen im dsmod Wiki geschrieben.
---
Anhänge
Zuletzt bearbeitet:
