Die Sicherheit des Session-Messengers – Ein Ratgeber

Sicherheitsbewusste Nutzer suchen immer häufiger nach Messenger-Apps, die Privatsphäre ernst nehmen. Vielleicht hast du schon von Signal gehört, dem bekannten sicheren Messenger. Doch es gibt einen Dienst, der noch einen Schritt weiter geht in Richtung Anonymität und Metadaten-Schutz: Session. In diesem Artikel erfährst du, was Session ausmacht, wie die technische Architektur funktioniert und worin sich Session von Signal unterscheidet. Egal ob du wenig Technik-Erfahrung hast oder ein IT-Profi bist – dieser Leitfaden erklärt dir die Sicherheit des Session-Messengers verständlich und ausführlich.

1. Einführung in Session

Was ist Session? – Session ist eine kostenlose, Ende-zu-Ende-verschlüsselte Messenger-App, die speziell auf Vertraulichkeit und Anonymität ausgerichtet ist​. Anders als viele gängige Messenger benötigt Session keine persönlichen Daten für die Registrierung: Weder Telefonnummer noch E-Mail-Adresse werden abgefragt​. Stattdessen erhältst du eine zufällig generierte, 66-stellige alphanumerische ID als deine Session-Kennung​. Dieses Konzept ermöglicht es dir, mit anderen zu chatten, ohne deine Identität preiszugeben.

Wer steckt dahinter? – Entwickelt wird Session von The Oxen Project im Rahmen der gemeinnützigen Session Technology Foundation​ (https://session.foundation). Diese Organisation (ehemals Loki Foundation genannt) hat ihren Sitz seit 2024 in der Schweiz, um außerhalb des Einflussbereichs der Five/Nine-Eyes-Staaten zu agieren​. Die Entwickler wollten einen Messenger schaffen, der technisch auf dem bewährten Signal aufbaut, aber zentralisierungsbedingte Schwachstellen vermeidet. Tatsächlich begann Session ursprünglich als Fork (Abspaltung) des Signal-Messengers. Vieles von Signals starker Verschlüsselungsbasis wurde übernommen, doch Session verfolgt zusätzliche Ziele: höhere Anonymität und Dezentralisierung. Dieses Entwicklerteam – gefördert durch die Loki/Oxen-Stiftung und eine Community von Privacy-Enthusiasten – richtet sich mit Session vor allem an Nutzer, denen Datenschutz und Meta-Daten-Freiheit wichtig sind. Das können z.B. Journalisten, Aktivisten, Whistleblower, aber auch alltägliche Nutzer sein, die ihre Kommunikationsdaten nicht preisgeben wollen.

Für wen ist der Messenger gedacht? – Grundsätzlich für jeden, der sichere Kommunikation möchte, aber insbesondere für diejenigen, die keine Telefonnummer herausgeben können oder möchten. Wenn du zum Beispiel anonym mit jemandem kommunizieren willst, ohne dass eure Telefonnummern oder E-Mail-Adressen verknüpft werden, ist Session ideal. Auch in Ländern mit starker Überwachung oder Zensur kann Session hilfreich sein, da keine zentrale Infrastruktur blockiert oder überwacht werden kann (dazu gleich mehr). Kurz gesagt: Session ist für Privacy-Enthusiasten entwickelt, bleibt aber einfach genug, dass auch weniger technisch Versierte ihn nutzen können.

2. Technische Architektur von Session

Um zu verstehen, warum Session so viel Wert auf Anonymität legt, schauen wir uns die technische Architektur an. Session unterscheidet sich grundlegend von traditionellen Messengern durch seine dezentrale Struktur und die Verwendung von Onion-Routing (Zwiebelrouting).

Dezentrale Infrastruktur – Die meisten Messenger (z.B. WhatsApp oder Signal) betreiben zentrale Server, die Nachrichten vermitteln. Session dagegen nutzt ein dezentralisiertes Netzwerk von sogenannten Service Nodes anstelle eines einzelnen Hauptservers​. Diese Service Nodes sind Server, die weltweit von der Community betrieben werden und über die Nachrichten transportiert werden. Das Besondere: Es gibt keinen zentralen Punkt, an dem alle Daten zusammenlaufen​. Die Service Nodes agieren in einem Peer-to-Peer-Netzwerk, das auf der Oxen-Blockchain basiert​. Vereinfacht bedeutet das: Viele unabhängige Rechner arbeiten zusammen, um den Messenger-Dienst bereitzustellen. Dadurch entsteht keine einzelne Schwachstelle oder Kontrollinstanz, die ein Angreifer ausnutzen könnte – kein „Single Point of Failure“​.

Onion-Routing (Zwiebelrouting) – Die Kommunikation in Session erfolgt über ein dreistufiges Onion-Routing, ähnlich wie im Tor-Netzwerk​. Das heißt, eine gesendete Nachricht wird mit mehreren Schichten von Verschlüsselung verpackt – wie eine Zwiebel mit mehreren Häuten. Sie durchläuft dann drei zufällig ausgewählte Service Nodes im Netzwerk. Jede Node entfernt eine Schicht der Verschlüsselung, um herauszufinden, wohin die Nachricht als Nächstes gesendet werden soll​. Dabei kennt die erste Node nur dich (die Absender-IP) und die zweite Node, die mittlere Node kennt nur die erste und die letzte Node, und die dritte (letzte) Node sieht nur die mittlere Node und den endgültigen Empfänger​. Keine einzelne Node kennt also sowohl Sender als auch Empfänger einer Nachricht – das macht eine Nachverfolgung extrem schwierig​. Deine IP-Adresse bleibt gegenüber dem Empfänger und dem Großteil des Netzwerks verborgen, was einen großen Gewinn an Anonymität bedeutet​.

Service Nodes und Swarms – Die Service Nodes im Oxen-Netzwerk sind nicht nur Relais-Stationen, sondern bieten auch Speicherfunktionen. Sie sind zu sogenannten “Swarms” gruppiert​. Ein Swarm ist im Grunde eine kleine Gruppe von Nodes, die für die Zwischenspeicherung von Nachrichten zuständig ist. Jeder Session-User ist einem bestimmten Swarm zugeordnet, basierend auf seiner Identität (öffentlicher Schlüssel). Wenn du eine Nachricht sendest, wird sie an den Swarm des Empfängers geschickt und dort zwischengepuffert, falls der Empfänger gerade offline ist​. Redundanz: Meist speichern mehrere Nodes im Swarm die Nachricht, sodass kein Datenverlust passiert, wenn eine Node ausfällt​. Sobald der Empfänger online geht, holt er die Nachricht aus dem Swarm ab – wiederum über Onion-Routing, um die Anonymität zu wahren​. Dieses System stellt sicher, dass Session dezentral und ausfallsicher läuft: Es gibt keinen zentralen Server, den man einfach abschalten oder zensieren könnte, und mehrere Knoten garantieren die Zustellung selbst bei Teilausfällen​.

3. Metadatenfreiheit und Anonymität

Ein zentrales Versprechen von Session lautet: “Send Messages, Not Metadata.” Metadaten sind Informationen über deine Kommunikation – zum Beispiel, wer wann mit wem gesprochen hat, von wo und mit welchem Gerät. Solche Daten können oft genauso sensibel sein wie der Inhalt der Nachrichten selbst. Session’s Ansatz ist daher, so wenig Metadaten wie möglich anfallen zu lassen und zu speichern​.

1. Keine Telefonnummer, keine E-Mail – Bereits bei der Registrierung zeigt sich dieser Ansatz: Du musst keine persönlichen Angaben machen. Im Gegensatz zu Signal, das deine Telefonnummer als Identifikator nutzt, bleibt bei Session deine Identität pseudonym (nur die zufällige ID)​. Dadurch fällt eine große Kategorie von Metadaten weg – es gibt keine Nutzerverzeichnisse mit realen Identitäten, keine Verknüpfung mit deinem Telefonbuch, keine Zuordnung zu deiner Person. Du kannst also z.B. einem Fremden deine Session-ID geben, ohne dass dieser daraus auf deine Telefonnummer oder deinen Klarnamen schließen kann.
2. Keine zentrale Metadaten-Speicherung – Da es keinen zentralen Server gibt, der die Nachrichten leitet, werden auch keine Kommunikationsprofile an einem Ort gesammelt. Ein Signal-Server könnte z.B. (theoretisch) nachvollziehen, welche Nutzer wie oft miteinander kommuniziert haben (auch wenn Inhalte verschlüsselt sind). Bei Session ist dies erheblich erschwert: Nachrichtenwege sind zufällig über viele Nodes verteilt, und es wird nichts in einer zentralen Datenbank mitgeschrieben​. Die Service Nodes selbst speichern nur kurzfristig unzugestellte Nachrichten und löschen sie, sobald sie zugestellt sind (Time-to-Live)​. Logs wie “Benutzer A hat um 15:00 mit Benutzer B gesprochen” braucht das System nicht – und was nicht erhoben wird, kann auch nicht gestohlen oder missbraucht werden.
3. IP-Adressen und Standort – Durch das Onion-Routing versteckt Session deine IP-Adresse vor dem Kommunikationspartner und auch vor großen Teilen des Netzwerks. Kein Server, der die Nachricht weiterleitet, sieht zugleich deine IP und die deines Freundes. Damit kann niemand einfach deine geografische Herkunft oder deinen Internetanbieter aus den Verbindungsdaten ablesen. Session selbst gibt an, keine IP-Adressen oder sonstige Gerätedaten zu protokollieren​. Im Unterschied dazu muss man bei klassischen Messengern dem Serverbetreiber vertrauen, dass er IP-Adressen nicht analysiert oder speichert – bei Session ist es architektonisch gelöst.
4. Vermeidbare Metadaten weglassen – Session sammelt keine Geolokationsdaten, Geräteinformationen oder Nutzungsstatistiken, die Rückschlüsse auf dich zulassen​. Selbst die Statusanzeige („online“/„zuletzt gesehen“) ist entweder gar nicht vorhanden oder funktioniert ohne zentrale Speicherung. Wo Signal z.B. zumindest den Zeitpunkt der Kontoerstellung und der letzten Serververbindung als minimale Metadaten vorhalten muss, versucht Session, selbst solche Infos zu eliminieren. Ein Experte nannte das Metadaten-Problem sogar die “Achillesferse” vieler sonst sicherer Messenger und lobte, dass Session hier einen großen Pluspunkt hat​. Natürlich kann auch Session nicht alle Metadaten komplett verhindern – beispielsweise kann dein Internetanbieter sehen, dass du Daten an das Oxen-Netz sendest (aber nicht den Inhalt oder Empfänger). Doch im Vergleich zu üblichen Diensten hinterlässt du mit Session einen weitaus kleineren Daten-Fußabdruck.
5. Anonymität in der Praxis – Was bedeuten diese technischen Maßnahmen für dich als Nutzer? Kurz gesagt: Du kannst Session nutzen, ohne dass jemand (weder der Dienstbetreiber noch ein Lauscher auf der Leitung) leicht herausfinden kann, wer du bist, mit wem du sprichst und wo du dich befindest. Selbst wenn jemand deine Nachrichten abfangen würde, wären sie nur ein Datenwirrwarr dank starker Verschlüsselung. Und selbst die Verbindungsdaten geben kaum Aufschluss. Diese Metadaten-Freiheit macht Session insbesondere für sensible Kommunikationen attraktiv – z.B. für Hinweisgeber, die anonym bleiben möchten, oder für Gespräche, die nicht mit deiner Person verknüpft werden sollen. Du kannst dich also darauf konzentrieren, Nachrichten zu senden, nicht Metadaten – wie der Slogan sagt.

4. Sicherheitsaspekte und Verschlüsselung

Sicherheit ist bei Session zweigleisig umgesetzt: Zum einen über die Architektur (Dezentralisierung, Anonymität – wie oben beschrieben), zum anderen über modernste Verschlüsselungstechniken. In diesem Abschnitt schauen wir uns das Verschlüsselungsmodell genauer an, inklusive der verwendeten Schlüssel (Public/Private Keys, Pre-Keys), der Gruppen-Chats, dem Spam-Schutz durch Proof-of-Work und der Handhabung von Dateianhängen.

Ende-zu-Ende-Verschlüsselung und Schlüsselprinzip

Session setzt durchgehend auf Ende-zu-Ende-Verschlüsselung (E2EE). Das bedeutet, dass nur du und dein Kommunikationspartner den Klartext der Nachrichten lesen können – niemand sonst, auch nicht die Server im Netzwerk​. Um das zu erreichen, benutzt Session ein System aus öffentlichen und privaten Schlüsseln (Public/Private Key Kryptografie).

Jeder Session-Nutzer hat ein Schlüsselpaar:

• Privater Schlüssel: bleibt geheim auf deinem Gerät. Damit kannst du Nachrichten entschlüsseln, die für dich bestimmt sind, und digitale Signaturen erstellen.
• Öffentlicher Schlüssel: wird anderen mitgeteilt (er ist z.B. in deiner Session-ID enthalten). Mit diesem Schlüssel können andere dir Nachrichten verschlüsseln – die dann nur du mit deinem passenden privaten Schlüssel wieder entschlüsseln kannst.

Stell es dir so vor: Dein öffentlicher Schlüssel ist wie ein offenes Schloss, das du jedem geben kannst. Jemand, der dir schreiben will, klickt seine Nachricht in dieses Schloss. Sobald es zugeschnappt ist, kann nur dein privater Schlüssel (den nur du hast) das Schloss wieder öffnen. Dieses Prinzip stellt sicher, dass niemand außer dem vorgesehenen Empfänger eine Nachricht lesen kann, selbst wenn er sie unterwegs abfangen sollte​.

Das Session-Protokoll – Ursprünglich nutzte Session das bekannte Signal-Protokoll (daher der Fork). Doch um besser zu der speziellen Infrastruktur zu passen, wurde das Session-Protokoll entwickelt​. Dieses ist eng verwandt mit Signal’s Verfahren (Double Ratchet Algorithmus, X3DH-Schlüsselaustausch etc.), wurde aber angepasst. Eines der bisherigen Opfer dieser Umstellung ist allerdings ein Sicherheitsmerkmal namens Perfect Forward Secrecy (PFS)​. PFS sorgt normalerweise dafür, dass vergangene Nachrichten selbst dann sicher bleiben, wenn dein langfristiger Schlüssel mal kompromittiert würde. Im aktuellen Session-Protokoll wurde PFS vorerst nicht implementiert​. Die Entwickler betonen zwar, dass dies kein akutes Sicherheitsrisiko darstellt und arbeiten an Verbesserungen, dennoch ist es ein Unterschied zu Signal.

Für dich heißt das: Session-Nachrichten sind sehr stark verschlüsselt, aber theoretisch könnten bei einem vollständigen Geräte-Hack mehr vergangene Nachrichten entschlüsselt werden als es bei Signal der Fall wäre. Deniable Authentication (eine Funktion, die es ermöglicht, im Nachhinein das Versenden einer Nachricht abzustreiten) fehlt ebenfalls derzeit. Diese Punkte sind eher für Krypto-Experten relevant; für die praktische Sicherheit ist Session dennoch hoch einzuschätzen. Wichtig ist: Das grundlegende Prinzip – nur Sender und Empfänger können lesen – bleibt gewährleistet.

Pre-Keys und Erstkontakt (Schlüsselaustausch)

Wie beginnt die sichere Kommunikation zwischen zwei Parteien, die noch nie zuvor gechattet haben? Hier kommen Pre-Keys ins Spiel. Pre-Keys sind sozusagen vorausberechnete, temporäre öffentliche Schlüssel, die ein Nutzer für zukünftige Handshakes bereitstellt. In Session läuft das über das Freundschaftsanfrage-System.

Angenommen, du möchtest jemanden neu anschreiben und hast nur seine Session-ID. Du sendest zunächst eine Freundschaftsanfrage. Diese enthält:

• Eine kurze Einführungsnachricht von dir (z.B. „Hallo, ich bin der und der...“),
• Dein Pre-Key-Bundle (eine Sammlung kryptografischer Schlüssel, einschließlich deines öffentlichen Schlüssels und weiterer temporärer Schlüssel),
• Meta-Informationen wie deinen angezeigten Profilnamen.

Diese Anfrage wird für den öffentlichen Schlüssel des Empfängers verschlüsselt – nur der gewünschte Empfänger kann sie also lesen​. Wenn die Anfrage im Netzwerk ankommt, kann der Empfänger entscheiden, ob er sie annimmt oder ablehnt​.

Nimmt er an, nutzt seine App das Pre-Key-Bundle, um einen sicheren Sitzungsschlüssel zwischen euch beiden aufzubauen​. Ab diesem Moment habt ihr einen gemeinsamen Geheimnisstand (wie bei Signal der Double Ratchet Start) und könnt asynchron verschlüsselte Nachrichten austauschen. Die Freundschaftsanfrage ist also vergleichbar mit dem initialen Handshake: Sie sorgt dafür, dass beide Seiten die nötigen (öffentlichen) Schlüssel des Gegenübers haben, um E2EE Nachrichten zu schicken. Technisch greift Session hier auf ähnliche Methoden wie das Signal-Protokoll (X3DH – Extended Triple Diffie-Hellman) zurück, aber verpackt es in das eigene Netzwerkmodell.

Für dich als Nutzer ist das relativ einfach: Du schickst jemandem deine Session-ID (z.B. als QR-Code oder als Text). Derjenige fügt dich als Kontakt hinzu und sendet die erste Nachricht (die zugleich die Anfrage ist). Du siehst dann eine Kontaktanfrage in Session mit der mitgesendeten Nachricht und kannst sie annehmen. Ab dann chatzt ihr normal – alles Weitere läuft automatisch verschlüsselt im Hintergrund.

Gruppenverschlüsselung (Gruppen-Chats)

Heutzutage sind Gruppen-Chats unverzichtbar. Natürlich sind auch Gruppennachrichten in Session Ende-zu-Ende-verschlüsselt, so dass nur die Teilnehmer der Gruppe die Inhalte lesen können. Session bietet hierbei zwei Arten von Gruppen an:

• Geschlossene Gruppen: Das sind private Gruppen, zu denen man eingeladen wird. Bis vor kurzem lag die Größenbeschränkung bei 10 Personen, inzwischen sind bis zu 100 Teilnehmer möglich​.
• Offene Gruppen: Das sind im Prinzip öffentliche Chats oder Foren, an denen beliebig viele Menschen teilnehmen können (theoretisch unbegrenzt große Gruppen)​. Diese offenen Gruppen erfordern einen speziellen Server (Open Group Server), der die Nachrichten verteilt, aber die Inhalte bleiben trotzdem verschlüsselt.

In einer geschlossenen Gruppe funktioniert die Verschlüsselung ähnlich wie im Einzelchat, nur mit mehreren Empfängern. Praktisch wird jede Nachricht für jeden Gruppenmitglieds-Schlüssel verschlüsselt oder es wird ein gemeinsamer Gruppenschlüssel verwendet, der an alle verteilt wurde – letzteres ist effizienter. Signal z.B. nutzt sogenannte Sender Keys für Gruppen. Session hat hier ursprünglich die Signal-Methodik übernommen; aktuelle Details hängen vom Session-Protokoll ab, aber für dich sichtbar ist nur: Gruppen-Nachrichten tragen ein Schloss-Symbol und sind privat. Kein Außenstehender oder Server kann die Unterhaltungen lesen. Neue Mitglieder einer geschlossenen Gruppe erhalten natürlich nicht den Zugriff auf alte Nachrichten (genauso wie bei Signal), da diese ja mit Schlüsseln verschlüsselt wurden, die sie noch nicht hatten.

Offene Gruppen sind ein Sonderfall: Sie erlauben große Community-Diskussionen. Hier werden Nachrichten auf einem Open Group Server zwischengespeichert, den prinzipiell jeder betreiben kann. Aber auch hier gilt: Der Server kann die Inhalte nicht im Klartext lesen, sofern die offenen Gruppen “geschlossen verschlüsselt” arbeiten​. In der Praxis dienen offene Gruppen oft als Foren oder Broadcast-Channels. Da unser Fokus auf Sicherheit und Privatsphäre liegt, sei nur erwähnt, dass offene Gruppen zwar verschlüsselt sind, aber durch ihre öffentliche Natur weniger anonym (man agiert ja öffentlich). Für private, sichere Absprachen sind daher die geschlossenen Gruppen relevant – und die schützen eure Gruppenchats genauso zuverlässig wie Einzelchats.

Schutz vor Spam: Proof-of-Work

Eine besondere Sicherheitsmaßnahme bei Session ist der Einsatz von Proof-of-Work (PoW), um Spam und Missbrauch zu verhindern. Vielleicht fragst du dich: Was hat Spam mit Sicherheit zu tun? Sehr viel – in einem anonymen Netzwerk ohne zentrale Kontrolle könnte theoretisch jemand massenhaft Anfragen oder Nachrichten an beliebige Session-IDs senden (Spam oder sogar DoS-Angriffe). Um das unrentabel zu machen, nutzt Session einen Trick aus der Kryptografie: Der Absender einer Nachricht muss eine kleine Rechenaufgabe lösen, bevor die Nachricht versendet wird.

Konkret wird beim Versenden einer Nachricht ein sogenannter Nonce-Wert berechnet, der beweist, dass eine gewisse Rechenleistung aufgewendet wurde​. Das ist vergleichbar mit einem sehr vereinfachten „Mining“ – dein Gerät rechnet vielleicht ein paar hundert Millisekunden, um einen passenden Wert zu finden. Dieser Wert kommt in den Nachrichten-Umschlag mit rein, bevor die Nachricht an den Swarm geschickt wird​. Für legitime Nutzer ist das kaum spürbar (eine minimale Verzögerung pro Nachricht), aber für jemanden, der das Netzwerk fluten will, potenziell sehr aufwendig. Denn um 1000 Spamnachrichten zu senden, müsste er 1000 mal diese Rechenarbeit leisten, was die Hardware stark beanspruchen würde.

Diese PoW-Anforderung gilt vor allem im asynchronen Modus – also wenn Nachrichten über die Swarms zwischengespeichert werden (z.B. Erstkontakte oder Offline-Nachrichten)​. 
Interessant: Sobald zwei Nutzer direkt online verbunden sind, schaltet Session auf einen synchronen Modus um. In diesem Fall wird ein direkterer Kanal zwischen den Endgeräten über das Netzwerk aufgebaut (eine Art Peer-to-Peer-Tunnel via Service Nodes), und dann entfällt die PoW-Hürde für die laufende Unterhaltung​. So hat man beim Chatten in Echtzeit keine künstliche Verzögerung. Sollte einer der beiden wieder offline gehen, fällt es zurück auf das asynchrone Verfahren mit PoW, damit die Nachricht wieder im Swarm landen kann​.

Für dich bedeutet das: Spam-Nachrichten von Unbekannten werden unwahrscheinlicher, da es für Bots teuer wird, dich zu bombardieren. Und du selbst merkst vom Proof-of-Work kaum etwas – außer vielleicht, dass Session auf älteren Telefonen minimal mehr Akkuleistung braucht als ein ganz simpler Messenger. Sicherheit und Netzschutz werden hier also innovativ durch ein bisschen Mathematik erreicht.
 

Dateianhänge und Medienversand

Session unterstützt natürlich Dateianhänge (Fotos, Videos, PDFs etc.) und Sprachnachrichten, und verschlüsselt auch diese Ende-zu-Ende​. Allerdings ist die Umsetzung etwas anders als bei einfachen Textnachrichten, da große Dateien das Netzwerk mehr belasten.

Wenn du in Session z.B. ein Bild sendest, passiert folgendes im Hintergrund:

1. Deine App verschlüsselt die Datei lokal mit einem einmaligen Dateischlüssel (z.B. mittels AES-Verschlüsselung).
2. Die verschlüsselte Datei wird nicht direkt an den Empfänger geschickt (das wäre über Onion-Routing von vielen MB etwas langsam). Stattdessen lädt deine App die Datei über Onion-Routing auf einen speziellen Dateiserver hoch.
3. Dieser Dateiserver gibt deiner App einen eindeutigen Link zurück, unter dem der Empfänger die Datei abrufen kann​.
4. Deine App sendet nun im normalen Chat eine Nachricht an den Empfänger, die im Prinzip den Download-Link und den Schlüssel zur Entschlüsselung enthält (natürlich alles wieder in der E2E-Verschlüsselung des Chats eingebettet).
5. Der Empfänger erhält die Nachricht, entnimmt den Link und Schlüssel, und lädt die Datei wiederum über das anonyme Netzwerk vom Dateiserver herunter​. Mit dem mitgelieferten Schlüssel entschlüsselt seine App dann das Bild, sodass es wieder sichtbar wird.

Wichtig zu wissen: Die Datei lagert zwar kurzfristig auf einem Server, aber in komplett verschlüsselter Form – der Server kann mit dem Inhalt nichts anfangen ohne Schlüssel​. Der Standard-Dateiserver wird aktuell von den Session-Entwicklern bereitgestellt (zentral)​. Warum zentral? Große Dateien belasten die dezentralen Service Nodes stark und würden das Blockchain-Netz eventuell ineffizient machen. Deshalb hat man entschieden, Dateiversand erst mal auszulagern, allerdings ohne die Privatsphäre zu opfern (weil der Server nichts entschlüsseln kann).

Die gute Nachricht: Dieser Datei-Server ist Open Source und es ist vorgesehen, dass man künftig eigene Server einbinden kann​. Dann könnte z.B. eine Organisation ihren eigenen Attachment-Server betreiben, oder es könnten mehrere öffentliche geben. Schon jetzt ist der Code offen einsehbar und jeder könnte einen solchen Server aufsetzen​. So bleibt man dem Dezentralisierungs-Prinzip treu, auch wenn momentan aus Praktikabilität eine Komponente zentral gelöst ist.

Für dich als Nutzer ändert das am Bedienkomfort nichts: Du tippst auf die Büroklammer, wählst ein Bild oder PDF – Session kümmert sich um Verschlüsselung und sicheren Transfer im Hintergrund. Anhänge sind somit genauso geschützt wie normale Nachrichten, selbst wenn der Weg übers Netz ein klein wenig anders aussieht.

Hinweis: Aktuell (Stand 2025) arbeitet das Session-Team auch an Sprach- und Videoanrufe über das Netzwerk. Diese Funktionen befinden sich noch in der Beta-Phase (ein Indiz dafür ist eine Nachricht im offiziellen „Session Updates“-Kanal in der App, die die Beta für Voice/Video Calls erwähnt). Da Live-Anrufe sehr geringe Latenz erfordern, ist die Umsetzung über das Oxen-Netzwerk eine technische Herausforderung. Für uns im Kontext Sicherheit bedeutet das: Sobald verfügbar, werden auch Anrufe Ende-zu-Ende-verschlüsselt sein – hier dürfte Session ebenfalls auf bekannte Protokolle (wie WebRTC mit E2E) setzen, vermittelt über die anonymen Service Nodes. Wir werden beobachten, wie sich dieses Feature entwickelt. Bis dahin konzentriert sich dieser Ratgeber auf die bereits etablierten Funktionen (Text, Dateien, Gruppen), in denen Session jetzt schon glänzt.

5. Vergleich mit Signal – Vorteile und Nachteile von Session

Signal ist so etwas wie der Goldstandard unter den sicheren Messengern – daher lohnt sich ein genauer Blick, wie Session im Vergleich zu Signal dasteht. Beide Anwendungen teilen die Philosophie der starken Verschlüsselung, unterscheiden sich aber in Punkten wie Architektur, Datenschutzstrategie, Bedienbarkeit und teils in der Zielgruppe.

Der größte Vorteil von Session liegt im Bereich Datenschutz/Anonymität: Keine Telefonnummer, kein zentrales Logging, verschlüsselte Vermittlung über ein verteiltes Netz. Signal hingegen punktet mit Reife und Usability: Es ist seit Jahren im Mainstream, sehr ausgereift und komfortabel, vor allem wenn die eigene soziale Gruppe es bereits verwendet.

Ein paar Punkte lassen sich hervorheben:

1. Metadaten & Privatsphäre: Signal sammelt zwar nur das Nötigste und ist in puncto Datenschutz vorbildlich unter den etablierten Messengern – doch Session sammelt praktisch gar nichts. Selbst Signal benötigt deine Nummer und speichert, dass Benutzer X (du) mit Nummer Y registriert ist. Bei Session existiert so ein Nutzerdatensatz nicht; du bist nur eine zufällige Zeichenfolge. Für viele ist das ein entscheidender Vorteil. „Das Fehlen von Metadaten ist ein riesiges Plus. Metadaten sind die Achillesferse vieler sicherer Dienste“ sagt ein Bericht über Session​. Dem kann man zustimmen: Session eliminiert eine ganze Klasse von Angriffsmöglichkeiten (z.B. Herausgabe von Verbindungsdaten an Behörden, Social Graph Analysis etc.), indem solche Daten gar nicht erst anfallen.
2. Sicherheit der Verschlüsselung: Beide Apps bieten starke Verschlüsselung. Signal hat sich über Jahre bewährt und gilt als extrem sicher. Session hat auf dieser Basis aufgebaut​. Ein Audit 2021 von Quarkslab hat Sessions Sicherheit überprüft und die Claims bestätigt​. Allerdings muss man erwähnen: Durch die Umstellung auf das eigene Protokoll fehlen (vorübergehend) einige theoretische Sicherheitsgarantien wie Perfect Forward Secrecy​. Signal hat hier die Nase vorn, da es diese Eigenschaft besitzt. In der Praxis bedeutet das nur in sehr speziellen Situationen ein Risiko, aber für absolute Sicherheitsfanatiker ist es ein Unterschied. Die Session-Entwickler arbeiten daran, diese Lücke zu schließen, sodass Session zukünftig mindestens so sicher wie Signal sein soll – und sogar noch privater​.
3. Performance und Zuverlässigkeit: Im Alltag stellt man kaum einen Unterschied fest – Nachrichten kommen bei beiden schnell an. Session kann gelegentlich minimal verzögert sein (durch die Relay-Hops), aber wir reden hier von Sekundenbruchteilen bis wenigen Sekunden. Dafür ist man bei Session unabhängiger von einem einzelnen Dienst: Sollte z.B. der Signal-Server ausfallen oder blockiert werden, stünden Signal-Nutzer im Dunkeln. Session würde so etwas besser verkraften, da tausende Nodes involviert sind. Das ist ein Punkt von Resilienz (Widerstandsfähigkeit gegen Ausfälle/Zensur), wo Session trumpft.
4. Funktionen und Komfort: Signal ist feature-rich (Calls, Gruppengrößen, Desktop-Clients mit voller Multi-Device-Synchronisation, etc.). Session hat Multi-Device ebenfalls in Arbeit (man kann es schon auf mehreren Geräten nutzen, aber es ist komplizierter als bei Signal). Voice/Video Calls sind bei Signal bewährt vorhanden, bei Session noch im Beta-Stadium. Funktioniert in unserem Langzeittest jedoch außerordentlich gut.
   Wer viel telefoniert, ist daher (Stand jetzt) bei Signal besser aufgehoben. Auch das Hinzufügen von Kontakten ist bei Signal einfacher – jeder, der in deinem Telefonbuch ist und Signal hat, erscheint automatisch. Bei Session musst du aktiv die ID austauschen, was für spontane Chats eine kleine Hürde darstellt.

Zusammengefasst kann man sagen: Session bietet mehr Anonymität, Signal mehr Bequemlichkeit. Beide sind Open Source und sicher, aber mit unterschiedlicher Ausrichtung. Die Entscheidung hängt von deinem Anwendungsfall ab – dazu im nächsten Abschnitt mehr.
 

6. Einsatzszenarien & Empfehlungen

Wann solltest du Session einsetzen, und wann ist vielleicht Signal oder ein anderer Messenger ausreichend oder besser? Hier einige typische Szenarien und Empfehlungen:

Maximale Anonymität erforderlich: Wenn du in einer Situation bist, in der deine Identität geschützt werden muss, ist Session erste Wahl. Beispiel: Ein/e Journalist/in will mit einer Whistleblower-Quelle kommunizieren. Beide können sich via Session kontaktieren, ohne Telefonnummern auszutauschen. Selbst wenn irgendwann Chat-Inhalte öffentlich würden, bliebe die Quelle anonym, weil keine Meta-Daten und keine Nummer auf sie hinweisen. Auch politische Aktivisten oder Menschenrechtsorganisationen in repressiven Regimen profitieren von Session, da Überwacher viel schwerer an Daten kommen. Für solche Einsatzzwecke wurde Session im Grunde geschaffen – hier ist es ideal geeignet.

Kommunikation ohne persönliche Nummer: Vielleicht möchtest du mit Online-Bekanntschaften oder in Communities schreiben, ohne gleich deine Telefonnummer preiszugeben. Mit Signal ginge das nicht (du müsstest deine Nummer teilen), mit Session sehr wohl. Du kannst z.B. in einem Forum deinen Session-Code posten, damit dir Leute privat schreiben können, ohne dass du irgendetwas Persönliches über dich verrätst. Für Datenschutz-Enthusiasten im Alltag ist das genial. Bedenke: Deine Session-ID kannst du jederzeit auch wieder verwerfen (neuen Account machen), falls sie doch zu bekannt wurde – es hängt nichts dran (außer deine Kontakte müssten dann den neuen Code bekommen).

Gruppen/Team-Kommunikation unter Geheimhaltung: Stell dir ein Team von Investigativ-Journalisten in verschiedenen Ländern vor, die an einem heiklen Thema arbeiten. Über Session könnten alle in einer geschlossenen Gruppe kommunizieren, ohne Furcht, dass Telefonverbindungsdaten ihre Zusammenarbeit verraten. Oder eine Gruppe von Aktivisten aus unterschiedlichen Orten organisiert sich über Session-Gruppenchat – kein Mitlesen, kein Mithören, keine Mitgliederliste in irgendeiner Cloud. Hier spielt Session seine Stärken aus. Wenn das Team jedoch regelmäßige Gruppentelefonate machen will, wäre Stand jetzt eine separate Lösung für Calls nötig (z.B. Jitsi oder halt doch ein Signal-Call), da Session-Gruppenanrufe noch nicht Realität sind.

Normale Alltagskommunikation mit Freunden/Familie: Hier punktet meist Signal (oder auch WhatsApp/Threema je nach Umfeld), weil jeder es kennt und nutzt. Wenn du Oma Erna erreichen willst oder deine Schulfreunde, und Datenschutz zwar wichtig aber nicht kritisch ist, dann ist Signal absolut ausreichend – und oft einfacher, weil die anderen es ohnehin haben. Session hat (noch) eine kleinere Nutzerbasis. Das bedeutet, du müsstest eventuell Überzeugungsarbeit leisten, dass deine Freunde einen neuen Messenger installieren, nur um mit dir zu chatten. Manche sind dazu bereit, andere weniger. Eine pragmatische Lösung kann sein: Nutze mehrere Messenger parallel, je nach Kontakt. Für vertrauliche Chats oder neue Leute nimm Session, für den bestehenden Freundeskreis ggf. Signal. Beide Apps schließen sich ja nicht aus.

Voice/Video Calls und Multimedia: Wenn du viel Wert auf Sprachanrufe oder Videochats legst, ist Signal (oder z.B. WhatsApp mit seinen Schwächen) derzeit praktischer. Session arbeitet an einer Lösung, aber bis diese stabil ist, solltest du für sichere Calls möglicherweise noch auf Signal zurückgreifen. Ähnliches gilt, wenn du umfangreiche Multimedia-Funktionen liebst – Signal bietet z.B. Sticker, reagierbare Nachrichten, Tastatur-GIF-Suche etc., was Session in dem Umfang (noch) nicht hat. Allerdings sind das Komfortfunktionen, keine Sicherheitsfeatures.

Censorship Circumvention (Umgehung von Zensur): In Ländern, wo Signal oder WhatsApp durch Regierungen blockiert werden (z.B. durch Sperren der bekannten Server-IP-Adressen), könnte Session besser durchkommen. Da Session über tausende verteilte Nodes läuft und auch über gängige Ports (Session verwendet in erster Linie Ports mit höherer Nummer, wie Port 22023) kommuniziert, ist es schwer gezielt zu blockieren, ohne gleich große Teile des Internets lahmzulegen. Es gibt Berichte, dass Session in einigen hochzensierten Regionen als verlässlicher Kanal dient, während andere Messenger eingeschränkt sind. In solchen Fällen ist Session technisch im Vorteil.

Unternehmenskommunikation oder Team-Arbeit: Hier kommen oft andere Lösungen wie Matrix/Element ins Spiel, aber auch Session könnte in kleinen Teams genutzt werden, die höchste Vertraulichkeit brauchen. Da Session keine offiziellen Verwaltungstools bietet (wie Benutzerverwaltung oder Backup-Systeme), ist es für Großunternehmen weniger geeignet. Für kleine Gruppen, die informell aber sicher kommunizieren wollen, kann es dennoch passen.

Unsere Empfehlung: Prüfe dein Bedürfnis nach Privatsphäre vs. Komfort. Wenn du sagst, „Ich will maximale Sicherheit, selbst wenn es etwas Umstellung bedeutet“, dann gib Session eine Chance – es könnte genau der Messenger sein, der zu deiner Philosophie passt. Wenn du dagegen sagst, „Ich möchte einfach, dass es möglichst viele nutzen und alles easy ist“, dann ist Signal ein sehr guter Kompromiss, der auch schon viel Sicherheit gibt (wenn auch nicht die Anonymität gegenüber dem Dienst). Natürlich kannst du auch beides haben: Viele nutzen Signal für Alltag und Session für besondere Fälle. Letztlich ist es toll, dass wir diese Auswahl haben – und Session füllt eine Nische, die bislang kaum bedient wurde.

7. Open-Source und Unabhängigkeit

Sicherheit und Vertrauen hängen stark davon ab, wer hinter einer App steht und wie transparent die Entwicklung ist. Sowohl Signal als auch Session werben zu Recht damit, Open Source zu sein – das heißt, der gesamte Programmcode ist öffentlich einsehbar und überprüfbar. Doch Session geht in Sachen Unabhängigkeit noch eigene Wege.

Offener Quellcode: Session’s Code ist auf GitHub frei verfügbar​. Jeder interessierte Entwickler kann hineinschauen, Vorschläge machen oder selbst beitragen. Für die Sicherheits-Community ist das wichtig: Nur wenn der Code offenliegt, können Experten prüfen, ob z.B. Hintertüren oder Fehler enthalten sind. Bei Session gab es 2021 einen Sicherheitsaudit durch die Firma Quarkslab, der die Implementierung genauer untersuchte und keine groben Probleme fand​. Diese Transparenz schafft Vertrauen. Auch Verbesserungen können so schnell von außen eingebracht werden. Die Kryptographie von Session basiert auf gut dokumentierten Verfahren (X25519, AES-GCM, etc.), keine geheimen Algorithmen. Alles ist darauf ausgelegt, dass die Community es verifizieren kann.

Loki/Oxen und Finanzierung: Hinter Session steht keine profitorientierte Firma, sondern die gemeinnützige Oxen Privacy Tech Foundation (ehemals Loki Foundation)​. Interessanterweise finanziert sich das Projekt auch über die Oxen-Kryptowährung. Die Betreiber der Service Nodes müssen Oxen-Coins staken (hinterlegen) und bekommen als Belohnung für das Betreiben der Nodes neue Coins ausgeschüttet​. Das heißt, das Netzwerk erhält einen Anreiz, dass genügend Leute weltweit Server bereitstellen – ohne dass eine Firma Server mieten muss. Dieses ökonomische Modell unterscheidet Session von Diensten wie Tor (die rein auf freiwillige Knoten setzen)​. Es stellt sicher, dass das Netzwerk selbstregulierend und dezentral bleibt​.

Natürlich kann man kritisch fragen: Was, wenn die Kryptowährung mal scheitert? Doch bisher funktioniert das System stabil, und es bedeutet vor allem: Session gehört niemandem allein. Kein Tech-Gigant, kein Milliardär im Hintergrund – sondern ein Netzwerk von vielen. Die Oxen Foundation koordiniert die Entwicklung, aber die Infrastruktur liegt in der Hand der Community.

Unabhängigkeit von staatlichem Einfluss: Ein Punkt, der in der Privacy-Szene viel diskutiert wird: Sitz und Jurisdiktion. Signal z.B. hat seinen Sitz in den USA. Obwohl die Signal Foundation tadellosen Ruf hat, gelten die USA als Teil der “Five Eyes” (Geheimdienst-Allianz), was manche Unbehagen bereitet. Session entstand in Australien (auch Five Eyes) und hat daher 2024 den Schritt gemacht, die Organisation in die Schweiz zu verlegen​. Die Schweiz ist bekannt für starke Datenschutzgesetze und politische Neutralität. Dieser Umzug zur neu gegründeten Session Technology Foundation in Zug (CH) wurde bewusst vollzogen, um dem Zugriff großer Geheimdienst-Allianzen zu entgehen​. Das heißt, selbst auf organisatorischer Ebene versucht Session, maximale Unabhängigkeit zu erreichen. Am Ende muss man zwar vor allem der Technik vertrauen (die sollte sicher sein, egal wo die Server stehen), aber es zeigt den philosophischen Ansatz der Macher.

Gemeinschaft und Weiterentwicklung: Als Open-Source-Projekt hat Session eine aktive Gemeinschaft. Fehler werden oft von Nutzern gemeldet und teils behoben, noch bevor offizielle Updates kommen. Die Entwicklung ist transparent – Roadmaps und Diskussionen sind öffentlich. Die Motivation ist, einen Messenger zu schaffen, der dauerhaft den höchsten Ansprüchen genügt. Dazu gehört auch, dass der Quellcode offen bleibt und Forks möglich wären, falls die Community unzufrieden wäre. Dieses Fehlen von Abhängigkeit von einem einzelnen Unternehmen oder Investor gibt vielen ein gutes Gefühl: Selbst wenn die ursprünglichen Entwickler morgen das Interesse verlören, könnte die Community Session weiterführen.

Zusammengefasst: Session ist in der DNA unabhängig – finanziell durch Community-Unterstützung und Krypto, technisch durch Dezentralität, rechtlich durch den Sitz in einem datenschutzfreundlichen Land und inhaltlich durch Open Source. Diese Eigenschaften unterstreichen die Glaubwürdigkeit des Sicherheitsversprechens. Wie bei Signal (auch Open Source, von einer Stiftung betrieben) zeigt sich, dass Datenschutz-Tools am besten unter nicht-kommerziellen Rahmenbedingungen gedeihen. Weder Session noch Signal haben Werbeeinblendungen oder verkaufen Daten – beide finanzieren sich über Spenden oder alternative Modelle. Im Falle von Session kannst du dir also sicher sein, dass deine Daten nicht zur Ware werden, schlicht weil Session keine verwertbaren Daten von dir hat und auch kein Interesse daran.

8. Kritik an der Nutzung von Session: Soatok-Blogposts

In seinen beiden Blogartikeln „Don’t Use Session (Signal Fork)“ (14. Januar 2025) und „Session Round 2“ (20. Januar 2025) spricht der Kryptografie-Blogger Soatok mehrere Kritikpunkte an, die grundlegend gegen die Nutzung von Session sprechen sollen. Zusammengefasst lassen sich die Vorwürfe in etwa so einteilen:

Fehlende oder unvollständige Implementierung wesentlicher Sicherheitsfunktionen
Soatok bemängelt insbesondere die (noch) nicht durchgängig implementierte Perfect Forward Secrecy (PFS) sowie eine mögliche Abweichung vom originalen Signal-Protokoll, die Schwachstellen eröffnen könne. Tatsächlich wurde in früheren Versionen von Session und im Whitepaper bestätigt, dass Perfect Forward Secrecy noch nicht lückenlos umgesetzt ist. Dies ist jedoch kein „unbekanntes“ oder verschleiertes Problem, sondern ein bereits öffentlich dokumentierter Aspekt, an dessen Verbesserung die Entwickler aktiv arbeiten.

• Fakt ist: Session basiert auf dem modifizierten Signal-Protokoll („Session Protocol“) und verzichtet in Teilen auf bestimmte Sicherheitsmerkmale wie PFS, die bei Signal längst etabliert sind. Dieses Manko ist real, aber kein Geheimnis. Gleichzeitig haben unabhängige Audits (z. B. durch Quarkslab 2021) keine fundamentalen Sicherheitslücken gefunden, sondern eher Verbesserungspotenzial in Bezug auf „Forward Secrecy“ und die Key-Management-Prozesse aufgezeigt.

Unsicherheit oder Lücken im Onion-Routing und der dezentralen Architektur
In den Artikeln wird außerdem behauptet, Session verfolge ein „unvollständiges“ Onion-Routing-Konzept und überlasse Nutzerdaten den Service Nodes. Soatok stellt zum Teil infrage, ob die Implementierung wirklich eine erhöhte Anonymität gewährleistet oder ob Angreifer das Netzwerk einfacher deanonymisieren könnten, als es die Entwickler angeben.

• Fakt ist: Session verwendet eine angepasste Onion-Routing-Technik (mehrstufiges Relaying über drei zufällige Service Nodes). Anders als bei Tor existiert jedoch kein separates, großes „Directory System“, sondern ein Schwarm-/Node-System auf Basis der Oxen-Blockchain. Ob das Sicherheitsniveau „genauso stark wie Tor“ ist, lässt sich schwer direkt vergleichen, da beide Netzwerke unterschiedlich aufgebaut sind. Die Kernidee – nämlich, dass kein einzelner Server Sender und Empfänger gleichzeitig zuordnen kann – bleibt jedoch plausibel umgesetzt. Trotz einzelner Kritik an möglichen Traffic-Korrelationen wird das Session-Design in den meisten unabhängigen Analysen (z. B. Whitepaper, Audit-Berichte) als grundsätzlich solide und anonymisierungsfreundlich bewertet.

Fehlende Transparenz oder Probleme im Code-Audit
Soatok unterstellt den Session-Entwicklern, nicht alle relevanten Codeänderungen gegenüber dem ursprünglichen Signal-Fork ausreichend dokumentiert zu haben, und sieht darin ein Risiko für unentdeckte Schwachstellen.

• Fakt ist: Session ist vollständig Open Source. Alle wesentlichen Codeänderungen werden über öffentliche Repositories (GitHub) eingesehen, kommentiert und versioniert. Größere Module (z. B. das PoW-System, das Session-Protokoll) wurden eigenständig dokumentiert und teils extern auditiert. Richtig ist aber auch, dass sich ein Fork schnell von seinem Ursprung entfernen kann, und man als Entwicklerteam stets detailliert dokumentieren muss, wie man vom reinen Signal-Protokoll abweicht. Dies gelingt mal besser, mal schlechter; grundsätzlich sind die Abweichungen bei Session in den Whitepapers thematisiert, aber die (laufende) Protokoll-Evolution ist durchaus komplex.

Zweifel am Blockchain-basierten Finanzierungskonzept
Ein weiterer Punkt ist die Skepsis gegenüber der Oxen-Blockchain und dem „Service Node“-Betrieb durch Staking. Kritiker wie Soatok heben hervor, dass das Projekt von der wirtschaftlichen Stabilität einer Kryptowährung abhängt, was sie für potenziell riskant halten.

• Fakt ist: Die Finanzierung via Oxen soll gerade die Dezentralisierung fördern, weil Node-Betreiber einen ökonomischen Anreiz erhalten. Sollte die Blockchain jedoch an Wert verlieren oder technische Probleme bekommen, wäre Session als Messenger gegebenenfalls ebenfalls betroffen. Das ist eine bekannte Abhängigkeit, der man sich bewusst sein sollte. Dennoch ist dies kein zwingender Grund, Session für unsicher zu halten, sondern eher ein Thema der Nachhaltigkeit und Zukunftsfähigkeit des Netzwerks.

Zusammenfassung und Bewertung der Vorwürfe

• Teilweise berechtigte Punkte:
  Soatok legt den Finger auf Aspekte wie fehlende Perfect Forward Secrecy, Abweichungen vom ursprünglichen Signal-Protokoll und die (relativ) junge, komplexe technische Architektur. Tatsächlich bestätigt Session selbst manche dieser Limitierungen und arbeitet an entsprechenden Verbesserungen. Diese Kritik ist also nicht grundlos und entspricht im Kern dem, was die Entwickler bereits öffentlich einräumen.
• Überzogene Schlussfolgerungen:
  Aus den vorhandenen Schwachstellen (z. B. PFS-Lücken, potenziell angreifbares Onion-Routing) sofort auf „unbrauchbar“ oder „völlig unsicher“ zu schließen, ist jedoch eine sehr drastische Interpretation. Eine Reihe von Sicherheitsaudits und die praktische Nutzung in Hochrisiko-Szenarien deuten darauf hin, dass Session trotz allem ein hohes Maß an Sicherheit und Privatsphäre bietet – insbesondere verglichen mit Mainstream-Messengern.
• Bedeutung für Nutzer*innen:
  Wer Session verwendet, sollte wissen, dass es gegenüber Signal gewisse Trade-offs gibt (z. B. Perfektion vs. Anonymität, PFS vs. Dezentralisierung). Soatoks Artikel verdeutlichen, dass Session (noch) kein „Allheilmittel“ gegen alle erdenklichen Bedrohungen ist. Gleichzeitig bleibt es ein Messenger mit deutlich stärkerer Meta-Daten-Vermeidung als die meisten Alternativen. Nutzer*innen sollten daher ihre Bedrohungsmodell-Frage stellen: Brauche ich Perfect Forward Secrecy um jeden Preis (z. B. wenn ein Angreifer später Zugriff auf alle meine Geräte bekommt)? Oder ist mir die dezentrale, anonyme Struktur wichtiger?

Die Blogposts von Soatok enthalten durchaus fundierte Kritikpunkte – beispielsweise zu Session’s Umgang mit Perfect Forward Secrecy und Protokoll-Dokumentation. Diese Aspekte sind real und werden von den Session-Machern selbst nicht abgestritten, sondern sukzessive angegangen. Die Schlussfolgerung, Session deshalb generell nicht zu nutzen, übergeht jedoch den Mehrwert, den das Projekt bei Anonymität und Metadaten-Freiheit bietet. Unterm Strich empfiehlt es sich für Interessierte, die Argumente beider Seiten abzuwägen: Soatok zeigt vorhandene Schwächen auf, während die Session-Entwickler offenlegen, welche Ziele sie priorisieren (z. B. dezentrale Architektur, keine Telefonnummern) und welche Kompromisse sie dafür in Kauf nehmen.
 

9. Fazit

Session präsentiert sich als moderner, sicherer Messenger, der konsequent auf Anonymität und Datenschutz setzt. Wir haben gesehen, dass Session technisch einiges anders macht als herkömmliche Dienste: Ein globales Netzwerk von Service Nodes statt eines zentralen Servers, Onion-Routing für die Nachrichtenübermittlung, keine persönlichen Anmeldedaten, und clevere Mechanismen wie Proof-of-Work gegen Spam. Die Ende-zu-Ende-Verschlüsselung stellt sicher, dass Inhalte geheim bleiben​, während die Architektur verhindert, dass überhaupt viele Metadaten anfallen​. In puncto Sicherheit der Nachrichteninhalte steht Session auf Augenhöhe mit Platzhirschen wie Signal – beide verwenden erprobte kryptografische Verfahren. Doch Session überflügelt klassische Messenger in Sachen Anonymität, da es praktisch keine identifizierenden Spuren hinterlässt.

Für wen ist Session nun die richtige Wahl? Wenn Privatsphäre für dich nicht nur ein Buzzword ist, sondern du wirklich Kontrolle über deine Kommunikationsdaten willst, dann ist Session ein Werkzeug, das du ausprobieren solltest. Gerade wenn du dich in Umfeldern bewegst, wo Überwachung denkbar ist (politisch, beruflich oder privat), bietet Session eine Ebene von Schutz, die über das Übliche hinausgeht. Du musst keine Telefonnummer herausgeben, keine Nutzerprofile erstellen – du kannst heute dem Gegenüber eine Nachricht schicken, als wärt ihr zwei Geister im Netz, die nur miteinander sichtbar werden und sonst nirgendwo. Das klingt vielleicht dramatisch, aber für manche ist genau das entscheidend.

Auf der anderen Seite muss man realistisch sein: Kein Messenger ist perfekt für alle Situationen. Signal z.B. hat den Vorteil der breiten Akzeptanz und einfacher Kontaktfindung; für viele alltägliche Chats reicht das aus. Session hingegen glänzt in speziellen Szenarien und lebt davon, dass die Nutzer bewusst Wert auf Datenschutz legen. Man könnte sagen: Signal ist der sichere Alltagswagen, Session der gepanzerte Spezialtransporter. Beide bringen dich ans Ziel, aber mit unterschiedlicher Ausstattung und Zielsetzung.

Empfehlung: Probiere Session kostenlos unter https://www.getsession.org aus. Die App ist erhältlich für Android, iOS, Windows, macOS, Linux. Vielleicht überzeugt dich das ruhige Gewissen, das Session vermittelt, weil es „Niemanden mitlauschen“ lässt. Viele nutzen mittlerweile mehrere Messenger parallel, je nach Kontext – warum nicht Session für die sensiblen Nachrichten? In der Praxis kannst du Freunden auch vorschlagen: „Lass uns für dieses Thema mal Session nutzen, ich erklär dir kurz wie’s geht.“ Oft hilft schon der Hinweis, dass keine Telefonnummer nötig ist, um Neugier zu wecken.

Abschließend lässt sich festhalten: Session ist ein beeindruckender Schritt nach vorn in der Evolution (hoch)sicherer Messenger. Es zeigt, dass man bewährte Kryptografie mit innovativer Infrastruktur kombinieren kann, um die letzte Bastion anfallender Daten (die Metadaten) auch noch zu minimieren. Session bietet höchste Sicherheit und Anonymität für deine Nachrichten, indem es Nachrichten statt Metadaten sendet – eine klare Empfehlung für alle, die wirklich privat kommunizieren möchten
 

Quellenverzeichnis

Protectstar Inc.:

• Ausgangstext „Ein umfassender Vergleich sicherer Messaging-Apps: Signal, Telegram, WhatsApp und Session“ unter https://www.protectstar.com/de/blog/telegram-vs-signal-vs-whatsapp-comparison-differences-between-messaging-apps

Offizielle Session-Website:

• https://getsession.org/
• Hier findest du Download-Links, FAQ und allgemeine Informationen zu Session.

Signal Messenger (offizielle Website):

• https://signal.org/
• Für weiterführende Infos zum Signal-Protokoll und den Funktionen.

Session-Dokumentation / Whitepaper:

• https://docs.oxen.io/session/
• Erläutert die technische Architektur (Service Nodes, Swarms, Onion-Routing, PoW) und Unterschiede zum klassischen Signal-Protokoll.

Oxen Project / Oxen Privacy Tech Foundation, and Session Technology Foundation:

• https://www.oxen.io/
• https://session.foundation
• Offizielle Projektseite zur Infrastruktur hinter Session (Service Nodes, Blockchain usw.).

Sicherheitsaudit von Quarkslab (2021):

• https://quarkslab.com/
• Quarkslab führte ein Audit von Session durch und bescheinigte eine solide Implementierung.

Tor/Onion-Routing-Grundlagen:

• https://www.torproject.org/
• Session nutzt ein ähnliches Prinzip (mehrschichtige Verschlüsselung) in abgewandelter Form.

Angaben zur Registrierung ohne Telefonnummer:

• Siehe Session-Doku: https://docs.oxen.io/session/account-creation
• Bestätigt, dass Session keine Telefonnummer oder E-Mail verlangt.

Informationen zum Proof-of-Work-System:

• https://docs.oxen.io/session/pow-and-spam-protection
• Erklärt, warum und wie Session PoW einsetzt, um Spam zu reduzieren.

Diskussion zu Perfect Forward Secrecy (PFS) in Session:

• https://github.com/oxen-io/session-issues/
• Hier findet man Beiträge von Entwicklern und Community zum aktuellen Stand (PFS, Double Ratchet etc.).

Open Group Server (für große/öffentliche Gruppen):

• https://docs.oxen.io/session/open-groups
• Verdeutlicht die Funktion von offenen Gruppen, Server-Architektur und Zugriffsmöglichkeiten.

Blog posts cryptography blogger Soatok:
https://soatok.blog/2025/01/14/dont-use-session-signal-fork/
https://soatok.blog/2025/01/20/session-round-2/