Wire statt Signal: Was die Bundesregierung tut und wie man es nachbaut

Ein staatlich gesteu­erter Phishing-Angriff auf Signal-Konten hochrangiger Politiker hat die deutsche Sicherheitsdebatte neu entfacht und Wire als BSI-zertifizierte Alternative in den Fokus gerückt. Ich betrachte hier, warum Behörden und Bundestag auf Wire setzen, wie die Architektur eines selbst gehosteten Wire-Backends aussieht und was dabei in einer typischen Server-Umgebung mit Nginx Proxy Manager, Docker und SSH-Tunnel-Zugang technisch realisierbar ist – und wo die Grenzen liegen. Meine Infrastruktur habe ich bereits beschrieben. Sie liegt diesem Test zugrunde.

Eigener Webserver mit offiziellen Zertifikaten

Der Basis-Artikel für alle folgenden Services, die ich hier demonstrieren werde…

Meister-Tech-BlogMichael Meister

Nach dem großflächigen Signalausfall am 20. Oktober 2025 habe ich mich intensiv mit der Frage beschäftigt, wie sich eine zuverlässige, Ende-zu-Ende-verschlüsselte Kommunikationslösung umsetzen lässt, die selbst gehostet ist und zugleich so dezentral funktioniert, dass der Ausfall eines einzelnen Servers den Nachrichtenaustausch nicht unterbricht.

Beyond Signal: Regaining Control with a Self-Hosted Matrix Server

Recent messenger outages highlight a key weakness. In this guide I demonstrate how to build a selfhosted, resilient chat service.

Meister-Tech-BlogMichael Meister

Der Klöckner-Vorfall: Was wirklich passiert ist

Das Bundesamt für Sicherheit in der Informationstechnik (BSI) warnte vor einem „wahrscheinlich staatlich gesteuerten" Phishing-Angriff über den Messenger Signal. Bundestagspräsidentin Julia Klöckner soll ebenfalls betroffen sein.

Inzwischen gibt es offenbar eine beträchtliche Zahl Betroffener: Zwei Bundesministerinnen, die Bundestagspräsidentin, Bundestagsabgeordnete mehrerer Parteien, NATO-Generäle und Bundeswehr-Angehörige sollen Berichten zufolge Ziele der Angriffe gewesen sein.

Entscheidend für das technische Verständnis ist: Der Angriff nutzt keine Sicherheitslücke aus, sondern das fragilste Element im IT-System: den Menschen. Signal ist weiterhin einer der sichersten für die Allgemeinheit zugänglichen Messengerdienste. Es handelt sich also nicht um ein gebrochenes Verschlüsselungsverfahren, sondern um klassisches Social Engineering. Signal erklärte, „die Verschlüsselung und Infrastruktur von Signal" sei „nicht kompromittiert worden".

Die Angriffstechnik läuft in zwei Varianten ab: Entweder werden Nutzer per gefälschter Support-Nachricht zur Herausgabe ihres Sicherheits-PINs verleitet, oder sie scannen einen QR-Code, der ein fremdes Gerät mit dem eigenen Signal-Konto koppelt. Die Betroffenen behalten zwar ihr Konto, die Angreifer haben aber Zugriff auf alle Chats und Gruppen und können mitlesen.

Warum Wire – und warum gerade jetzt

Die Person, die auf die simpelste Angriffsvariante hereingefallen ist, Bundestagspräsidentin Klöckner, empfiehlt Abgeordneten in einem Schreiben den Wechsel zum BSI-zertifizierten Messenger Wire, um Phishing-Gefahren einzudämmen. Die Bundestagsverwaltung stellt Wire aktiv zur Verfügung, um eine Alternative zu kommerziellen Plattformen wie WhatsApp oder Signal zu etablieren.

Wire (in der für Behörden adaptierten Version „Wire Bund") wurde ab 2022 in der deutschen Bundesverwaltung im Pilotbetrieb eingesetzt und ist seit Dezember 2025 vom Bundesamt für Sicherheit in der Informationstechnik als einziger Messenger für die Nutzung bis zum Geheimhaltungsgrad „Verschlusssachen – nur für den Dienstgebrauch" zugelassen.

Viele Ministerien nutzen Wire zur internen Kommunikation, darunter das Bundesinnenministerium, das Bundesbildungsministerium, das Bundeswirtschaftsministerium sowie das Bundesgesundheitsministerium. Auch in nachgeordneten Behörden kommt Wire zum Einsatz: im BSI, Bundeskartellamt, ITZBund, Bundesverwaltungsamt, Bundeskriminalamt und Bundesamt für Verfassungsschutz.

Die neue Zulassung ist zunächst bis Ende 2028 befristet. Das liegt an den noch fehlenden Post-Quanten-Verfahren, die auch Angriffen durch Quantencomputer standhalten müssen. Kritiker weisen zu Recht darauf hin, dass auch Wire kein Allheilmittel ist: Phishing-Angriffe sind prinzipiell gegen jede Plattform möglich, die auf E-Mail-Adressen als Login basiert.

Ein häufig übersehener Aspekt: Wire verlegte 2019 seinen Hauptsitz in die USA, was damals Fragen zur Datensicherheit aufwarf. Für Behörden ist deshalb der On-Premises-Betrieb auf eigenen Servern zentral – und genau das ist der Vorteil des hier beschriebenen Setups.

Wire-Architektur: Kein einfaches Docker-Image

Wer nach wireapp/wire-server:latest auf Docker Hub sucht, sucht vergeblich. Die Wire-Server-Plattform ist keine monolithische Anwendung, die sich mit einem einzigen Container starten lässt. Das wire-server-Repository auf GitHub listet eine Vielzahl von Microservices auf, die gemeinsam das Backend bilden:

Dazu kommen externe Abhängigkeiten: Cassandra als primäre Datenbank (nicht PostgreSQL!), Redis für ephemere Daten und je nach Setup Elasticsearch für die Suche. Die Images werden nicht über Docker Hub, sondern über quay.io/wire/ bereitgestellt, zum Beispiel quay.io/wire/brig oder quay.io/wire/galley.

Die empfohlene Installationsmethode ist: Wire-Server auf Kubernetes installieren, unter Verwendung der Konfiguration und Anleitungen aus dem wire-server-deploy-Repository. Dies ist die beste Option für einen produktiven Self-Hosting-Betrieb.

Ein simples docker-compose up mit einem All-in-one-Image existiert offiziell nicht. Die docker-compose-Dateien im Repository dienen ausschließlich lokalen Entwicklungs- und Testumgebungen, nicht dem Produktionsbetrieb.

Kubernetes und Helm: Der tatsächliche Deploymentweg

Die offizielle Dokumentation unter docs.wire.com beschreibt ein Deployment über Helm-Charts auf Kubernetes. Wer Wire ernsthaft selbst hosten möchte, benötigt:

• Einen laufenden Kubernetes-Cluster (z.B. via k3s auf einem dedizierten Server oder einem Managed-Cluster bei einem Cloud-Anbieter)
• helm als lokalen Client
• Eine Cassandra-Installation, die Wire ausdrücklich außerhalb von Kubernetes empfiehlt
• DNS-Einträge für mehrere Subdomains (z.B. wire.lab.meister-security.de, federator.wire.lab.meister-security.de)

Das Helm-Chart wire-server aus dem wire-server-deploy-Repository übernimmt die Orchestrierung aller Microservices. Die Konfiguration erfolgt über eine zentrale values.yaml, in der unter anderem die Federation-Domain gesetzt wird:

# Ausschnitt aus values/wire-server/values.yaml
brig:
  config:
    optSettings:
      setFederationDomain: "wire.lab.meister-security.de"
      setFederationStrategy: allowNone  # allowAll | allowDynamic | allowNone
      setFederationDomainConfigsUpdateFreq: 10  # Sekunden

Die Federation-Strategie kennt drei Modi. allowNone entspricht einer leeren Allowlist und ist der sicherste Ausgangspunkt. allowDynamic ermöglicht eine dynamisch verwaltete Allowlist, die in Cassandra gespeichert wird. allowAll ist für Produktionsumgebungen ausdrücklich nicht empfohlen.

Integration in eine NPM-basierte Serverumgebung

Wer bereits meinen Server mit Nginx Proxy Manager, Docker und Let's Encrypt betreibt und Wire in diese Infrastruktur einbinden möchte, kann den Kubernetes-Ingress so konfigurieren, dass er auf Port 443 lauscht und NPM als vorgelagerten Reverse Proxy nutzt. Konzeptionell sieht das so aus:

Internet
  │
  ▼ :443 / :80
Nginx Proxy Manager (Docker, Netz: web)
  │  wire.lab.meister-security.de  →  Kubernetes Ingress (nginz)
  │
  ▼
Kubernetes Ingress / nginz
  ├── brig    (Accounts)
  ├── galley  (Conversations)
  ├── cannon  (WebSockets)
  └── federator (Federation-Ingress :8443 intern)

NPM übernimmt dabei das TLS-Termination und die Let's-Encrypt-Zertifikatsverwaltung. Die Weiterleitung erfolgt per Proxy-Host auf die interne Cluster-IP des Kubernetes-Ingress. Kein weiterer Port als 80 und 443 muss am Host-Firewall geöffnet werden.

Für den Federation-Ingress wird ein DNS-SRV-Record benötigt, damit andere Wire-Backends den eigenen Federator finden:

_wire-server-federator._tcp.wire.lab.meister-security.de. IN SRV 0 10 8443 wire.lab.meister-security.de.

Dieser Port 8443 bleibt intern, da der Federator im Kubernetes-Cluster läuft. Von außen ist er nur dann erreichbar, wenn er explizit über den Ingress oder einen NodePort exponiert wird.

Admin-Zugriffe über SSH-Tunnel

Da keine zusätzlichen Ports nach außen geöffnet werden, erfolgen alle administrativen Zugriffe über SSH-Tunnel. Das gilt für NPM selbst, aber auch für interne Wire-API-Endpunkte:

# NPM-Admin-UI auf Port 81 tunneln
ssh -L 8181:localhost:81 user@example.de
# Anschließend im Browser: http://localhost:8181

# Wire-Backoffice (stern) tunneln, falls im Cluster verfügbar
ssh -L 9000:stern-service.wire.svc.cluster.local:8080 user@example.de

Das stern-Tool ist das offizielle Backoffice-Interface von Wire und bietet eine Swagger-basierte Oberfläche für administrative Aufgaben wie das Anlegen von Teams und Nutzern. Es sollte niemals ohne Authentifizierungsschicht öffentlich zugänglich sein.

Benutzer und Federation verwalten

Die Benutzerverwaltung in Wire kann auf zwei Ebenen erfolgen. Für kleinere Deployments reicht die direkte Registrierung mit E-Mail-Adresse und Passwort, optional beschränkt auf eine bestimmte E-Mail-Domain. Für Enterprise-Setups bietet Wire über den spar-Service eine vollständige SAML-SSO- und SCIM-Integration, mit der Nutzerkonten automatisch aus einem Identity-Provider wie Keycloak oder Microsoft Entra ID bereitgestellt werden.

Die Federation-Allowlist wird nach dem ersten Deployment über die interne REST-API von brig gepflegt. Ab einem bestimmten Release werden Federation-Verbindungen nicht mehr über die values.yaml konfiguriert, sondern ausschließlich über die interne REST-API, wobei die Daten in Cassandra gespeichert werden (allowDynamic-Modus). Die drei Strategien in der Praxis:

# In values/wire-server/values.yaml
brig:
  config:
    optSettings:
      # Keine Federation (Standardwert für neue Instanzen):
      setFederationStrategy: allowNone

      # Nur explizit freigegebene Partner (empfohlen für Produktion):
      # setFederationStrategy: allowDynamic
      # Domains dann per API hinzufügen

      # Offene Federation (nur für Testzwecke):
      # setFederationStrategy: allowAll

Wichtig: Eine einmal gesetzte Federation-Domain (setFederationDomain) darf niemals geändert werden, da sonst bestehende Nutzerkonten und Gespräche inkonsistent werden.

Fazit

Wire ist eine faktisch praxiserprobte und BSI-zertifizierte Alternative zu Signal für behördliche und sicherheitskritische Kommunikation, wobei der entscheidende Sicherheitsgewinn nicht in einer stärkeren Kryptografie liegt, sondern in der vollständigen Datensouveränität durch On-Premises-Betrieb. Ich fand den Aufwand sehr hoch für meine kleine Umgebung und werde für securityrelevante Informationen weiterhin bei Matrix bleiben.