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.

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)

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.

# 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.

[..]
RUN=yes
[..]
DAEMON_OPTS="-F /etc/sslh/sslh.cfg"

Punkt 5: sslh Konfiguration anlegen

Der Ordner /etc/sslh/ muss angelegt werden.

mkdir /etc/sslh/

Jetzt kann die Konfigurationsdatei erzeugt und gespeichert werden. (Zeile 14 bitte anpassen!)

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

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.

# 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:

_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.

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.

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.

# sslh transparent proxy
net.ipv4.conf.all.route_localnet = 1
net.ipv4.conf.default.route_localnet = 1

Wir übernehmen wir die Änderungen.

sysctl -p

Nun prüfen wir ob diese beiden Pakete auf dem System bereits installiert sind.

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.

[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.

#!/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.

chmod +x /usr/local/bin/sslh-transparent.sh

Die Systemd Unit aktivieren und starten.

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!

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!

63.143.0.0 - - [21/May/2018:09:26:07 +0200] ...

 

Dominion

Dominion

Linux Systemadministrator

Das könnte Dich auch interessieren …

5 Antworten

  1. 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.

  2. Avatar agre sagt:

    Wie handlest du denn die Anfragen, die zum Beispiel über den port 5218 für den http_upload rein kommen?

    • Dominion Dominion sagt:

      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.

      • Avatar agre sagt:

        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.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.