Prosody: XMPP over HTTPS
In öffentlichen Hotspots oder sonstigen limitierten Netzwerken ist oft nur der Webserver Port 80 und 443 erlaubt. Aus diesem Grund könnte es für den einen oder anderen Admin eines XMPP Dienstes von Interesse sein XMPP over HTTPS (XEP-0368) für Nutzer in solchen Netzwerken anzubieten.
In dieser Anleitung erkläre ich, wie auf einem bereits laufenden Debian 9 (Stretch) Server mit XMPP und Webserver eine HTTPS Weiche (sslh) zu konfigurieren ist.
Punkt 1: Installation des Pakets
Das Paket in Version 1.18 gibt es unter Debian 9 ohne weitere Repo’s hinzufügen zu müssen.
1 2 | apt update apt install sslh |
Punkt 2: Webserver Listen-Adresse anpassen
Wir änderen das Listen-Interface des Apachen wie folgt ab. (Für Nginx ebenfalls einfach umzusetzen)
1 | Listen 127.0.0.1:443 |
Evtl. ist es nötig in den einzelnen vHosts ebenfalls die IP-Adresse für HTTPS auf 127.0.0.1 im Ordner /etc/apache2/sites-available/ abzuändern!
Punkt 3: Aktivieren des legacy SSL Ports unter Prosody
Prosody muss nun noch erlaubt werden auf dem alten SSL Port 5223 zu lauschen. Wir fügen folgende Zeile hinzu.
1 2 | # Alle vHosts können entweder in ein SSL Zertifikat, oder aufgeteilt werden. (siehe Kommentare) legacy_ssl_ports = 5223 |
Punkt 4: sslh Daemon anpassen
Wir erlauben sslh beim Booten zu starten und fügen unsere künftige Konfiguration hinzu.
1 2 3 4 | [..] RUN=yes [..] DAEMON_OPTS="-F /etc/sslh/sslh.cfg" |
Punkt 5: sslh Konfiguration anlegen
Der Ordner /etc/sslh/ muss angelegt werden.
1 | mkdir /etc/sslh/ |
Jetzt kann die Konfigurationsdatei erzeugt und gespeichert werden. (Zeile 14 bitte anpassen!)
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 | verbose: false; foreground: false; inetd: false; numeric: false; transparent: false; timeout: 2; user: "sslh"; pidfile: "/run/sslh/sslh.pid"; # Change hostname with your external address name. Note: It should not be resolving to 127.0.0.1 listen: ( { host: "xmpp.domain.de or IP"; port: "443"; } ); protocols: ( { name: "tls"; host: "localhost"; port: "5223"; alpn_protocols: [ "xmpp-client" ]; log_level: 0;}, # catch anything else TLS { name: "tls"; host: "localhost"; port: "443";}, { name: "xmpp"; host: "localhost"; port: "5222"; }, { name: "timeout"; host: "localhost"; port: "443";} ); on-timeout: "timeout"; |
Punkt 6: Wir starten die Dienste neu
1 | systemctl restart prosody.service apache2.service sslh.service |
…und prüfen ob die Umstellungen erfolgt sind. Die Dienste sollten nun auf diesen IPs + Ports laufen.
1 2 3 4 | # netstat -ntpl | grep -E "5223|443" tcp 0 0 62.xx.xx.xx:443 0.0.0.0:* LISTEN 23026/sslh tcp 0 0 127.0.0.1:443 0.0.0.0:* LISTEN 16618/apache2 tcp 0 0 0.0.0.0:5223 0.0.0.0:* LISTEN 25435/lua5.1 |
Punkt 7: DNS Records
Damit limitierte Nutzer nun ohne Änderung an der Client-Konfiguration sich zum XMPP Dienst verbinden können, erstellen wir unsere SRV Records im Nameserver wie folgt.
Sortiert nach Priorität: 5222/xmpp, 5223/tls, 443/xmpp, 443/tls:
1 2 3 4 | _xmpp-client._tcp.xmpp.domain.de. 3600 IN SRV 5 1 5222 xmpp.domain.de. _xmpps-client._tcp.xmpp.domain.de. 3600 IN SRV 10 1 5223 xmpp.domain.de. _xmpp-client._tcp.xmpp.domain.de. 3600 IN SRV 15 1 443 xmpp.domain.de. _xmpps-client._tcp.xmpp.domain.de. 3600 IN SRV 20 1 443 xmpp.domain.de. |
Punkt 8: Prüfen der Verbindung
Mit openssl prüfen wir auf der Konsole ob eine HTTPS Verbindung möglich ist.
1 | openssl s_client -connect xmpp.domain.de:443 -alpn xmpp-client -servername domain.de |
>_ Update 21.05.2018
Punkt 9: Transparent Proxy
Möchte man im Webserver Logfile dann doch die Client IP-Adressen sehen und nicht 127.0.0.1, müssen folgende Anpassungen vorgenommen werden.
Wir setzen zuerst den transparent auf true und als User wählen wir den bereits angelegten Namen sslh.
1 2 3 4 5 6 7 8 9 10 | verbose: false; foreground: false; inetd: false; numeric: false; transparent: true; timeout: 2; user: "sslh"; pidfile: "/run/sslh/sslh.pid"; [..] |
Nun erlauben wir dem System auf localhost zu routen. Diese Zeilen fügen wir in /etc/sysctl.conf an.
1 2 3 | # sslh transparent proxy net.ipv4.conf.all.route_localnet = 1 net.ipv4.conf.default.route_localnet = 1 |
Wir übernehmen wir die Änderungen.
1 | sysctl -p |
Nun prüfen wir ob diese beiden Pakete auf dem System bereits installiert sind.
1 | apt install iproute2 iptables |
Zu guter Letzt benötigen wir diese iptables Konfigurationen. Wir erstellen hierzu eine Systemd Unit welche ein kleines Bash-Script beim Booten ausführt. Alternativ kann auch /etc/rc.local oder ein eigenes Firewall-Script verwendet werden.
Systemd Unit erstellen.
1 2 3 4 5 6 7 8 9 10 | [Unit] Description=iptables rules for sslh transparent mode After=network.target [Service] Type=oneshot ExecStart=/usr/local/bin/sslh-transparent.sh [Install] WantedBy=multi-user.target |
Bash-Script sslh-transparent.sh anlegen.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 | #!/bin/bash # DROP martian packets as they would have been if route_localnet was zero # Note: packets not leaving the server aren't affected by this, thus sslh will still work iptables -t raw -A PREROUTING ! -i lo -d 127.0.0.0/8 -j DROP iptables -t mangle -A POSTROUTING ! -o lo -s 127.0.0.0/8 -j DROP # Mark all connections made by ssl for special treatment (here sslh is run as user "sslh") iptables -t nat -A OUTPUT -m owner --uid-owner sslh -p tcp --tcp-flags FIN,SYN,RST,ACK SYN -j CONNMARK --set-xmark 0x01/0x0f # Outgoing packets that should go to sslh instead have to be rerouted, so mark them accordingly (copying over the connection mark) iptables -t mangle -A OUTPUT ! -o lo -p tcp -m connmark --mark 0x01/0x0f -j CONNMARK --restore-mark --mask 0x0f # Configure routing for those marked packets ip rule add fwmark 0x1 lookup 100 ip route add local 0.0.0.0/0 dev lo table 100 |
Das Script ausführbar machen.
1 | chmod +x /usr/local/bin/sslh-transparent.sh |
Die Systemd Unit aktivieren und starten.
1 2 | systemctl enable sslh-transparent.service systemctl start sslh-transparent.service |
Nachdem die Regeln angewendet wurden, kann sslh nun im Transparent-Modus neugestartet werden.
Wichtig: In Zeile 7 der Konfiguration /etc/sslh/sslh.cfg muss der Benutzer sslh stehen, ansonsten greifen die iptables Regeln nicht!
1 | systemctl restart sslh.service |
Im Webserver Logfile sind nun wieder wie gewohnt IP-Adressen zu sehen.
Hier schon eine gekürzte Version, da meine Webserver bereits DSGVO konform arbeiten. Wie man IP-Adressen kürzt zeige ich in diesem Tutorial!
1 | 63.143.0.0 - - [21/May/2018:09:26:07 +0200] ... |
0
Nur der Vollständigkeithalber: Theoretisch können auch mehrere Zertifikate benutzt werden. Dazu legt man mehrere legacy ports an. Zum Beispiel 5223, 5224, 5225 usw. Jeder Port bekommt dann sein eigenes Zertifikat.
Erklärt ist das in der Prosody docu: https://prosody.im/doc/ports Das Beispiel für http_ssl { … } lässt sich auf lässt sich auf legacy_ssl_ssl { [5223] = {…}, [5224] = {…}} transferieren.
Per sslh werden dann die verschiedenen domains auf die verschiedenen Ports gelenkt.
sehr guter Tipp, danke Daniel!
Weiter ist es auch noch möglich ein Interface festzulegen, falls mehrere IP-Adressen verwendet werden sollen -> legacy_ssl_interfaces
Noch 2 kleine Tipps für Prosody Versionen ab 0.10: Automatic location & Let’s Encrypt
Wie handlest du denn die Anfragen, die zum Beispiel über den port 5218 für den http_upload rein kommen?
Du kannst den http_upload Port natürlich auch über diese Weiche auf Port 443 laufen lassen. Dazu müsstest du einen entsprechenden vHost in deinem Webserver einrichten. SSLH leitet den http_upload Traffic wie normalen Webtraffic um.
Ich nutze dazu https://modules.prosody.im/mod_http_upload_external.html und eine Subdomain die via HTTPS Port erreichbar ist.
Kurzes Feedback meinerseits: Ich habe mir einfach einen reverse proxy mit nginx für /upload und /register_web erstellt. Dann kann der https-port in prosody deaktiviert werden und es muss noch http_external_url festgelegt werden.
Diese Variante spart ein Modul und eine Subdomain.