Es geht tatsächlich. Man kann Telegram auch ohne Google-Push Token nutzen. NextPush, Nagram, Mercurygram und Nextcloud helfen dabei.
Eine verschlüsselte Nachricht nützt wenig, wenn man den Empfänger über den Push-Dienst identifizieren kann. Der Dienst sorgt dafür, dass man auf dem Smartphone eine Benachrichtigung erhält, obwohl die App gar nicht aktiv ist. Im ersten Schritt verschickt jemand eine Mitteilung. Telegram veranlasst in der Folge eine Benachrichtigung. Der externe Push-Dienst transportiert die Daten zum Smartphone des Adressaten. Am Ende der Transportkette sieht man auf dem Sperrbildschirm beispielsweise die Mitteilung: „Neue Nachricht bei Telegram“.
Das FBI hat bereits gezeigt, wie einfach die Identifikation des Empfängers trotz der aktiven Ende-zu-Ende-Verschlüsselung und der Nutzung von Pseudonymen funktionieren kann. Anstatt sich um den Messenger zu kümmern, forderten die Ermittler bei Google Informationen zu einem Push-Token an. Die Daten führten sie über die Betreibergesellschaft von Teleguard schließlich zum gesuchten Nutzer.
Gerade wenn Telegram nicht nur für öffentliche Kanäle, sondern auch für vertrauliche Gespräche oder journalistische Kontakte genutzt wird, sollte man die Nutzung von Drittanbietern vermeiden. Mit NextPush und einer eigenen Nextcloud kann man Google aus der Push-Zustellung entfernen. Das funktioniert auch unter GrapheneOS und anderen Android-Systemen, die ohne Google Play Services auskommen.
Wie das FBI Messenger-Nutzer über Push-Tokens identifizierte
Im Februar 2024 berichtete die „Washington Post“ über eine Ermittlungsmethode, bei der Push-Benachrichtigungen zur Identifizierung von Personen genutzt wurden. Die Journalisten deckten mehr als 130 Durchsuchungsbeschlüsse und gerichtliche Anordnungen auf, in denen entsprechende Daten angefordert wurden oder bei denen Push-Tokens eine Rolle spielten.
Das einst neuartige Vorgehen betraf die Swisscows AG, die den Schweizer Messenger TeleGuard bereitstellt. Der Anbieter wirbt bis heute mit verschlüsselter Kommunikation und der Speicherung möglichst weniger Nutzerdaten. Das stimmt soweit auch. Dennoch gelang es dem FBI auf diese Weise, einen Verdächtigen zu identifizieren.
Die Ermittler erhielten einen Push-Token, den TeleGuard für Benachrichtigungen an das Smartphone des Nutzers verwendete. Mit den Daten des Token fragten sie bei Google nach den zugehörigen Informationen. Google LLC lieferte unter anderem verknüpfte Konten und IP-Adressen. Eines der Konten führte schließlich zum Verdächtigen.
Das Entscheidende daran: Niemand musste dafür die Verschlüsselung von TeleGuard knacken. Die benötigten Informationen besaß Google auf ihren Servern. Sie mussten sie nach Eingang des „exigent request“, also einer dringenden Anfrage des FBI-Mitarbeiters, preisgeben.
Auch Apple stellt man immer wieder Behördenanfragen zu Push-Tokens zu. Über die geänderte Vorgehensweise haben wir auf Tarnkappe.info bereits berichtet.
Unter Android werden Benachrichtigungen häufig über den Dienst Firebase Cloud Messaging (FCM) abgewickelt. Jede registrierte App-Instanz erhält einen Token, über den Google das richtige Gerät erreichen kann. FCM & Co. erhalten zwar keinen Klarnamen, sie können sie aber mit anderen gespeicherten Informationen verknüpfen.
Für Ärzte, Anwälte, Gewerkschaftsvertreter, Informanten, Journalisten und andere Personen, die vertrauliche Kontakte schützen müssen, ist dies ein unnötiges Risiko. Die Inhalte der Nachrichten müssen nicht einmal bekannt sein. Schon die Daten rund um ihre Zustellung können für eine Zuordnung ausreichend sein.
Mercurygram und Nagram statt der offiziellen Telegram-App
Die offizielle Telegram-App erlaubt keine freie Auswahl eines Unified-Push-Anbieters. Dafür benötigen wir einen alternativen Client wie Mercurygram. Unified-Push-Anbieter (sogenannte Distributoren und Server) ermöglichen den Empfang von Push-Benachrichtigungen unter Android und Linux, ohne auf die Google Play Services oder andere proprietäre Push-Dienste angewiesen zu sein.
Die App Mercurygram ist ursprünglich aus Telegram-FOSS hervorgegangen und wird inzwischen eigenständig weiterentwickelt. Während von Telegram-FOSS schon länger keine neuen Releases mehr veröffentlicht wurden, bearbeiten die Mercurygram-Entwickler aktuelle Telegram-Versionen und ergänzen sie um die Änderungen für den Betrieb ohne Google-Dienste. Der Client unterstützt Unified Push und erlaubt die Verwendung eines eigenen Web Push-Gateways.
Nagram unterstützt ebenfalls Unified Push und Web Push. Dort ist bereits ein öffentliches Gateway hinterlegt. Im Quellcode ist dafür derzeit die Adresse https://p2p.hoyolab.pp.ua/ hinterlegt. Ein eigener AESGCM-Proxy wie dieser hier, ist damit nicht zwingend erforderlich.
Der Hintergrund ist das ältere Format für verschlüsselte Push-Benachrichtigungen von Telegram. UnifiedPush kann diese nicht unverändert weiterleiten, da dabei Informationen zur Entschlüsselung verloren gehen würden. Das Gateway passt die Daten entsprechend an. Die Nachrichten selbst kann es dabei jedoch nicht entschlüsseln.
Der voreingestellte Server von Telegram erspart zwar die Installation, dafür ist jedoch ein weiterer Betreiber an der Zustellung beteiligt. Dieser kann unter anderem Verbindungsdaten und die verwendeten Push-Endpunkte einsehen. Wer das vermeiden möchte, betreibt halt den AESGCM-Proxy selbst.
Auch andere Telegram-Forks wie Forkgram und Momogram bieten UnifiedPush-Funktionen. Allerdings beherrscht nicht jede Version die hierfür erforderliche WebPush-Weiterleitung. Wir beschränken uns deshalb auf Mercurygram und Nagram.
Die Benachrichtigungen gelangen vom Gateway zur eigenen Nextcloud. Auf dem Smartphone übernimmt NextPush die Zustellung an den Telegram-Client. Ob das Gateway selbst betrieben wird oder Nagrams vorhandener Server genutzt wird, ist eigentlich egal.
NextPush auf der eigenen Nextcloud einrichten
Eine vorhandene Nextcloud auf einem NAS, Mini-PC oder in einer virtuellen Maschine reicht schon aus. Über den Nextcloud-App-Store wird zunächst die Erweiterung „UnifiedPush Provider” installiert, die dort unter dem Namen „uppush” angeboten wird.
Für die Erweiterung wird Redis benötigt. Das ist bei vielen Nextcloud-Installationen ohnehin schon der Fall. Falls nicht, muss der Dienst vorher eingerichtet werden.
Anschließend installieren wir auf dem Android-Smartphone NextPush. Die Anwendung ist direkt bei F-Droid verfügbar, der Quellcode liegt auf Codeberg.
NextPush verbindet sich mit dem eigenen Nextcloud-Konto. Wenn die offizielle Nextcloud-App bereits installiert ist, kann man sich damit anmelden. Alternativ kann man bei den Sicherheitseinstellungen der Nextcloud ein eigenes App-Passwort erzeugt werden.
Danach kann NextPush Benachrichtigungen für Nagram und Mercurygram empfangen. Dafür muss Android der Software die Benachrichtigungsberechtigung erteilen und die Hintergrundaktivität erlauben. Eine zu strenge Akkuoptimierung kann die Zustellung sonst verhindern.
Bei einer Nextcloud hinter Nginx, HAProxy oder einem anderen Reverse-Proxy sollte man darauf achten, dass dieser die Verbindung zu NextPush nicht ständig unterbricht oder Benachrichtigungen zurückhält. Die Entwickler haben dazu entsprechende Hinweise veröffentlicht.
Nextcloud mit DynDNS und Let’s Encrypt veröffentlichen
Wenn die Nextcloud bereits über eine öffentliche HTTPS-Adresse erreichbar ist, kann die vorhandene Konfiguration weiterverwendet werden.
Bei einem Heimanschluss mit öffentlicher IP-Adresse genügt DynDNS. Dieser Dienst aktualisiert die Domain automatisch, sobald sich die IP-Adresse ändert. Ein Reverse-Proxy nimmt die HTTPS-Anfragen entgegen und leitet sie an die Nextcloud weiter.
Dafür eignen sich Serverprogramme wie Nginx, HAProxy oder caddy. Letzteres verwaltet die benötigten Let’s-Encrypt-Zertifikate auch automatisch.
Läuft die Nextcloud beispielsweise lokal auf Port 8092, könnte die caddy-Konfiguration wie folgt aussehen:
cloud.example.org {
reverse_proxy 127.0.0.1:8092 {
flush_interval -1
}
}
Bei Docker oder einer separaten Virtual Machine (VM) muss man die interne Adresse entsprechend anpassen. Für die automatische Zertifikatsausstellung muss der Server außerdem erreichbar sein. Nextcloud muss zudem die öffentliche Domain kennen. Diese wird unter „trusted_domains” eingetragen. Falls ein Reverse-Proxy vorgeschaltet ist, können Anpassungen bei „trusted_proxies” und den HTTPS-Einstellungen notwendig sein. Bei Anschlüssen hinter CGNAT hilft eine gewöhnliche IPv4-Portfreigabe nicht weiter. Dafür kann man ein VPS oder Tailscale Funnel verwenden.
Nextcloud zu Hause über HAProxy und Tailscale anbinden
Wie Plex und die übrigen Dienste läuft die eigene Nextcloud auf meiner eigenen Hardware zu Hause. Für den Zugriff aus dem Internet nutze ich einen VPS mit HAProxy. Dieser nimmt die HTTPS-Anfragen entgegen und leitet sie über Tailscale an meine heimischen Server weiter. Der Vorteil: Portfreigaben am Router sind dafür nicht erforderlich.
Eine eigene Domain ist ebenfalls nicht zwingend nötig. Mit nip.io bzw. sslip.io kann ich die öffentliche IP-Adresse meines VPS direkt verwenden. Bei der Beispiel-IP 203.0.113.10 wären das beispielsweise cloud.203-0-113-10.sslip.io für Nextcloud und push.203-0-113-10.sslip.io für meinen AES-GCM-Proxy.
Beide Adressen führen zum VPS. HAProxy verteilt die Anfragen über Tailscale an die jeweiligen Dienste zu Hause. Die HTTPS-Verbindung wird auf dem VPS abgesichert. Die Zertifikate von Let’s Encrypt lassen sich beispielsweise mit Certbot oder acme.sh (ZeroSSL) beschaffen und in HAProxy einbinden. SSLip.io übernimmt lediglich die DNS-Auflösung.
Daheim läuft dieser Aufbau bereits für meinen Medienserver Plex. Auch NextPush funktioniert darüber problemlos. Während Nextcloud und der AESGCM-Proxy auf dem Heimserver bleiben, übernimmt der VPS den öffentlichen Zugang.
HAProxy habe ich zusätzlich mit meinem noch in Entwicklung befindliche aber auf Codebasis bereits fertigen Clawforge abgesichert. Damit überwache ich verdächtige Zugriffe und andere Sicherheitsereignisse. Das Projekt hatten wir bereits auf Tarnkappe.info vorgestellt.
Ohne VPS funktioniert es mit Tailscale Funnel
Eine Alternative ist Tailscale Funnel. Damit lassen sich lokale Dienste über eine öffentliche HTTPS-Adresse erreichbar machen, ohne dass am Router Ports geöffnet werden müssen. Auch CGNAT stellt dabei kein Hindernis dar. Auch über Funnel haben wir bereits ausführlich berichtet.
Das Ganze funktioniert aber nur mit einer lauffähigen Tailscale-Installation mit aktivierten HTTPS-Zertifikaten und der entsprechenden Funnel-Freigabe.
Ist Nextcloud auf dem Tailscale-Rechner lokal auf Port 8092 erreichbar, genügt bei der Verwendung von Linux folgender Befehl:
sudo tailscale funnel --bg --https=443
http://127.0.0.1:8092Anschließend ist die Nextcloud über eine öffentliche ts.net-Adresse erreichbar. Tailscale kümmert sich um die Zertifikate, sodass DynDNS und die Portfreigaben entfallen. Die neue Domain muss man gegebenenfalls noch unter „trusted_domains” eintragen.
Tailscale Serve darf allerdings nicht mit Funnel verwechselt werden. „Serve” stellt Dienste nur innerhalb des eigenen Tailnets bereit. Funnel macht sie aus dem Internet erreichbar. Um die Telegram-Benachrichtigungen empfangen zu können, benötigen wir den öffentlichen Zugang.
Dadurch wird allerdings auch die Nextcloud-Weboberfläche aus dem Internet erreichbar. Ein vorgeschalteter Reverse-Proxy kann den Zugriff auf die benötigten Funktionen beschränken. Dabei müssen sämtliche von NextPush verwendeten Adressen weiterhin erreichbar bleiben.
Bei Funnel bleibt man halt von Tailscale abhängig. Wer bereits einen eigenen VPS mit HAProxy betreibt, kann die Dienste stattdessen über das Tailnet anbinden.
Den aesgcm-Proxy selbst betreiben
Das öffentliche Gateway von Nagram erspart die Installation eines eigenen Proxys. Wer seine Push-Daten jedoch selbst verwalten möchte, sollte sie nicht über ein fremdes Gateway schicken. Datenschutz bedeutet auch, dass man so wenig Arbeit wie Daten wie irgendmöglich an Drittanbieter abgibt.
Für dieses Vorgehen empfehle ich meinen öffentlich verfügbaren Fork des ursprünglichen AESGCM-Proxys von Mercurygram. Ich habe ihn um einen Healthcheck und optionale Prometheus-Metriken erweitert. Damit lässt sich die Erreichbarkeit kontrollieren und feststellen, ob bei der Weiterleitung Fehler auftreten.
Die Erweiterungen befinden sich derzeit im Feature-Branch „feat/healthcheck”. Im Standardbranch „main” sind sie noch nicht enthalten.
Unter Linux mit installiertem Docker laden wir den entsprechenden Branch (Entwicklungszweig bei GitHub etc.) herunter und erstellen daraus das Container-Image:
git clone -b feat/healthcheck
https://github.com/lesecuritae/aesgcm-proxy.git
cd aesgcm-proxy
docker build -f Containerfile
-t aesgcm-proxy:healthcheckAnschließend starten wir den Container wie folgt:
docker run -d
--name aesgcm-proxy
--restart unless-stopped
-p 127.0.0.1:8001:8001
aesgcm-proxy:healthcheckDamit läuft der Proxy zunächst nur lokal auf Port 8001. Das reicht bereits aus, um einen Reverse-Proxy auf demselben Rechner zu betreiben.
Beim vorliegenden Aufbau mit HAProxy auf dem VPS muss der Container zusätzlich über Tailscale erreichbar sein. Wenn Tailscale direkt auf dem Linux-Rechner mit Docker installiert ist, kann man dafür die Tailscale-IP verwenden.
Tailscale-IP ermitteln
Zunächst ermitteln wir die Tailscale-IP mit folgendem Befehl:
tailscale ip -4Danach starten wir den Container mit einer zusätzlichen Bindung an diese Adresse. Bei einer Neuinstallation kann dafür direkt folgender Befehl verwendet werden. Läuft bereits ein Container mit dem Namen „aesgcm-proxy”, muss man diesen vorher stoppen und entfernen.
Und das geht so:
TAILSCALE_IP="$(tailscale ip -4)"
docker run -d
--name aesgcm-proxy
--restart unless-stopped
-p 127.0.0.1:8001:8001
-p "${TAILSCALE_IP}:8001:8001"
aesgcm-proxy:healthcheck
Der Dienst ist somit sowohl lokal als auch über die Tailscale-IP des Heimservers erreichbar. Docker veröffentlicht den Port jedoch nicht auf allen Netzwerkschnittstellen. Den Zugriff innerhalb des Tailnets sollte man über die Tailscale-Zugriffsregeln auf den VPS beschränken.
Auf dem VPS ergänzen wir die Weiterleitung zum Heimserver im vorhandenen HTTPS-Frontend von HAProxy.
Für unsere Beispieladresse könnte das folgendermaßen aussehen:
# Im vorhandenen HTTPS-Frontend:
use_backend aesgcm_home if { req.hdr(host) -i push.203-0-113-10.sslip.io }
# Neuer Backend-Abschnitt:
backend aesgcm_home
mode http
http-request deny deny_status 403 if { path -i /metrics }
server aesgcm 100.101.102.103:8001 checkEin Beispiel ist die Adresse 100.101.102.103. In diese Adresse muss die tatsächliche Tailscale-IP des Heimservers eingetragen werden. Die Regel wird in das bereits vorhandene HTTPS-Frontend eingebaut, wobei HAProxy das Zertifikat für den öffentlichen Hostnamen verwendet.
Über diese Verbindung erreicht HAProxy den AESGCM-Proxy innerhalb der eigenen vier Wände. Der Verkehr zwischen VPS und Heimserver läuft verschlüsselt durch Tailscale. Am heimischen Router muss weiterhin kein Port geöffnet werden.
Mein Fork bietet unter /healthz einen eigenen Healthcheck. Ob der Dienst antwortet, lässt sich direkt auf dem Heimserver prüfen.
curl -i http://127.0.0.1:8001/healthzBei erfolgreicher Prüfung antwortet der Online-Dienst mit HTTP 200 und „ok”. Auch vom VPS aus kann man die Erreichbarkeit über die Tailscale-IP tesn. HAProxy nutzt bei Bedarf den Endpunkt für seine Überwachung.
Zusätzlich können mit ENABLE_METRICS=1 Prometheus-Metriken aktiviert werden. Diese erfassen unter anderem erfolgreiche Weiterleitungen und Netzwerkfehler. Der dafür vorgesehene Endpunkt /metrics besitzt keine eigene Anmeldung und darf deshalb nicht öffentlich erreichbar sein. Das ist wichtig. In der Beispielkonfiguration von HAProxy ist dieser Pfad ausdrücklich gesperrt.
Ein erfolgreicher Healthcheck bedeutet jedoch nicht, dass die Benachrichtigung bereits auf dem Smartphone angekommen ist. Dies muss man auf jeden Fall durch Versand einer Testnachricht kontrollieren.
Nagram und Mercurygram mit NextPush verbinden
Nachdem NextPush mit Nextcloud verbunden wurde, kümmern wir uns als nächstes um die Einrichtung der Push-Zustellung im Telegram-Client.
Bei Mercurygram findet man die UnifiedPush-Verwaltung unter
„Settings” → „Mercurygram” → „Notifications” → „UnifiedPush”.
Dort wählt man NextPush als Distributor aus und trägt bei Verwendung eines eigenen AESGCM-Proxys dessen öffentliche HTTPS-Adresse ein. Das könnte beispielsweise https://push.example.org/ oder die eigene sslip.io-Adresse sein.
Nagram verwendet standardmäßig das bereits hinterlegte öffentliche Gateway. Wer stattdessen seinen eigenen Proxy nutzen möchte, muss die Adresse in den Einstellungen ersetzen. Die Menüpunkte können sich je nach Version unterscheiden.
Den Pfad „/aesgcm” muss man nicht selbst ergänzen. Der Client erzeugt die benötigte Adresse bei der Registrierung.
Nach erfolgreicher Einrichtung sollten Nagram bzw. Mercurygram in NextPush als registrierte Anwendungen erscheinen. Eine Nachricht von einem zweiten Telegram-Konto zeigt, ob die Zustellung auch bei geschlossenem Messenger funktioniert.
Erscheint keine Benachrichtigung, sollte zunächst die Verbindung von NextPush zur Nextcloud und anschließend die Registrierung des Telegram-Clients kontrolliert werden. Beim eigenen AESGCM-Proxy helfen zusätzlich die Container-Logs.
docker logs --tail 100 aesgcm-proxyMercurygram zeigt außerdem Informationen zu eingegangenen und verarbeiteten Unified-Push-Benachrichtigungen an. Dafür hält man den ausgewählten Distributor in den Einstellungen länger gedrückt.
Google bleibt draußen, Telegram nicht
Wenn NextPush und die eigene Nextcloud genutzt werden, benötigt die entsprechend eingerichtete Telegram-App keinen FCM-Push-Token mehr. Damit wirft man Google als Datenquelle über Bord, mit deren Hilfe Behörden bereits Nutzer anderer Messenger identifiziert haben.
Ein eigener AESGCM-Proxy beseitigt zusätzlich die Abhängigkeit von einem fremden Gateway. Die beteiligten Server können dennoch Verbindungsdaten protokollieren. Deshalb sollte man die Logs der eigenen Nextcloud und des Reverse-Proxys mit viel Umsicht behandeln. Egal ob sie daheim oder woanders anfallen, so gilt weiterhin: Die besten Daten sind keine! Bitte daran denken.
Das Prozedere sorgt aber nicht dafür, dass die Kommunikation von Telegram anonym oder automatisch Ende-zu-Ende-verschlüsselt übertragen wird. Für die Ende-zu-Ende-Verschlüsselung gibt es bei Telegram die separat gestarteten geheimen Einzelchats. Diese bindet Telegram jedoch an die jeweiligen Geräte, weswegen man sie nicht plattfomrübergreifend synchronisieren kann. Mehr Informationen dazu findet man online bei den FAQs von Telegram.
Bei besonders sensiblen Informationen sollte man überlegen, ob nicht ein Messenger mit standardmäßiger Ende-zu-Ende-Verschlüsselung die bessere Wahl ist. In dem Fall könnte man zum Beispiel Signal oder Threema einsetzen.
Die Causa TeleGuard zeigte eindrucksvoll, wie viel ein einzelner Push-Token zur Identifizierung eines vermeintlich anonymen Messengernutzers beitragen kann. Stellt sich somit abschließend die Frage: Warum sollte man Google diese Daten übermitteln, wenn es auch anders geht?
Hinweis: Wer Probleme bei der Umsetzung der Anleitung hat, kann sich gerne in unserem Forum oder bei unserer Signal- und Telegram-Gruppe melden.
