Follow

Sealed Sender beim Signal-Messenger. Was ist das überhaupt und warum sollte man es aktivieren? 👇

kuketz-blog.de/signal-messenge

@kuketzblog war bei mir tatsächlich nicht standardmäßig aktiviert 😳

@Tifi @kuketzblog ist ja auch nur das Statussymbol, sealed sender sollte per Default an sein

@piratenpanda stimmt, nach Aktivierung des Reglers wurde auch bei alten Nachrichten der Umschlag angezeigt
@kuketzblog

@kuketzblog Das war hier deaktiviert bei seit Installation nicht veränderter Einstellung. Danke für den Hinweis!

@kuketzblog
Vielleicht sollte man erwähnen, dass sealed sender wegen der Möglichkeit der traffic correlation auf dem zentralen Server recht wenig bringt.

@kuketzblog Analogie zum Briefverkehr: Wenn du bei der Post anonym einen Brief abgibst aber beim gleichen Besuch deinen Ausweis vorzeigst um ein Paket abzuholen, weiß man in der Filiale genau, wer den Brief geschickt hat, auch wenn es nicht drauf steht. Bei Signal gibt es nur eine Filiale, bei der du alles machen musst. Bei einem dezentralen System sieht es anders aus, da gibt es viele Filialen und du kannst deine Briefe einfach an einer anderen abgeben als der, wo du deine Pakete abholst.

@larma Welchen Nutzen Sealed Sender unter diesen Bedingungen hat, vermag ich nicht zu beurteilen. Ich kann die Problematik theoretisch nachvollziehen - allerdings die Praxisrelevanz nicht einschätzen.

@kuketzblog Wenn der Traffic (bzw. Teile davon) nicht *ohne TLS-Verschlüsselung* geloggt wird, ist das vermutlich nicht sonderlich relevant.

Um solche Logs anzufertigen müsste der Server manipuliert würden. Bei Signal könnte das per behördlicher Anordnung aber durchaus passieren - entweder gegen Signal selbst oder die entsprechenden Cloud-Anbieter. Dass Signal nicht auf eigener Hardware hostet wird so zu einem größeren Problem als ohnehin schon.

@larma Das Problem haben wir bei wirklich allen zentralisierten Messengern.

Für erhöhten Schutzbedarf diesbezüglich: Briar.

@kuketzblog Es gibt noch föderierte Messenger (sagte er als Mitglied des Technical Council der XMPP Standards Foundation)

@pixelcode

Ja wäre schön, wenn xmpp in diesem Bereich ähnlich innovativ wie Signal sein würde.
Ich nutze xmpp mit OMEMO ja gerne, aber in Sachen Metadaten gibt's definitiv noch Verbesserungsbedarf.

An Marvin W: Gibt es denn schon Bestrebungen sich dieser Problematik anzunehmen?

@larma @kuketzblog

@the_white_wolf @pixelcode @kuketzblog

Dafür zu sorgen, dass XMPP in Sachen Metadaten ein vergleichbares oder sogar besseres Niveau erreichen kann wie zum Beispiel Signal, verstehe ich durchaus als Ziel. In dem Sinne wäre ich durchaus an konkreten Kritik-Punkten am Metadaten-Verhalten von XMPP interessiert.
Also was sind aktuell für dich persönlich die größten Probleme?

@larma

Danke erstmal für deine Erläuterungen weiter unten.

Allgemein gesagt wünsche ich mir, dass xmpp so wenig Infos wie möglich serverseitig speichert.
Wieviel man xmpp in der Hinsicht noch optimieren kann, entzieht sich aber meiner Kenntnis.
Das kannst du vermutlich besser beurteilen als ich.
Konkret würde ich mir wünschen, dass Kontaktelisten, Gruppen und Benutzerprofile ausschließlich lokal gespeichert werden gespeichert werden (wie zB Threema es macht).

@larma Tut mir Leid, aber weder XMPP noch Matrix sind IMHO »Vorbilder« wenn es um die Vermeidung von Metadaten geht. Höchstens wenn man einen eigenen Server betreibt und alle Kontakte kommunizieren darüber. Dann vielleicht. 😉

@kuketzblog Viele der Metadaten-Kritikpunkte unter kuketz-blog.de/conversations-m sind mindestens zweifelhaft:
- Login-Passwort: Bei Verwendung von SCRAM (von den meisten Servern und Clients unterstützt) wird das Klartext-Passwort weder auf dem Server gespeichert, noch beim Login-Prozess übertragen.
- Gespeicherte Kontakte: Das speichern von Kontakten auf dem Server ist bei vielen Clients optional.

@kuketzblog
- Zwischengespeicherte Nachrichten: Diese sind bei jedem Messenger vorhander, der nicht erzwingt, dass Empfänger und Sender gleichzeitig online sein müssen.
- Einsehen aktuell verbundener Nutzer: Das ist bei jedem Messenger möglich, der nicht eine vollständig dezentrale Struktur gewählt hat (auch dann manchmal).

- Nachrichten-Archiv: Lass ich gelten, ist aber wegen Verschlüsselung nicht extrem relevant.
- Informationen über Gruppen: Hier sind manche (zB. Signal) tatsächlich besser.

@larma Vielleicht sind einige Punkte überarbeitungsbedürftig. Aber ich bleibe dabei: Weder XMPP noch Matrix sind Vorbilder bei der Metadatenvermeidung. Die Stärken liegen definitiv woanders.

@kuketzblog @larma

Jein. Grundsätzlich fallen bei jedem Messenger auf dem Server gewisse Meta-Daten an.
Von, An, Zeitstempel, Länge der Nachricht, ...
Ob die gespeichert oder irgendwie genutzt werden, ist gerade bei nicht offenen Systemen nicht überprüfbar und kann natürlich auch bei dezentralen Systemen erfolgen.
Bei dezentralen Systemen sind aber nur die beteiligten Systeme involviert, es gibt keine zentrale Instanz in der jegliche Kommunikation aufläuft.
Schon daher muss ich nur meinem und dem Server meines Kommunikationspartners trauen.
Das ist viiiel besser, als ein einzelnes zentrales System, auf dass z.B. Behörden vergleichsweise einfach Zugriff haben.

Gruppenchats mit vielen Mitgliedern sind unabhängig von Verschlüsselung und Metadaten unsicher .. da ist bestimmt über einen der Mitglieder Zugriff möglich.

@kuketzblog @larma

wenn ich self-hoste, heißt das auch nur, dass ich die Metadaten statt in einem eingemauerten System einfach über's offene Internet ausspiele, in dem wir wissen, dass three-letter-agencies und andere Instanzen mitprotokollieren können. Von daher ist die Situation da sogar arguably schlechter als bei Signal, das man erstmal auf Server-Software-Ebene (weil die Trafficcorrellation ja eigentlich nur innerhalb der Server-*Software* gemacht werden kann) aktiv kompromitieren müsste.

@cherti Jetzt müsstest du aber schon erklären, warum du der Meinung bist, dass beim self-hosten mehr Metadaten an Dritte geschickt werden müssen als bei einem zentralisierten System (wo der zentrale Server ja auch als Drittpartei zu begreifen ist).

@larma ich sage nicht, dass mehr Metadaten geschickt werden, sondern dass die Metadaten öffentlich sind.

In Signal geht Trafficanalyse nur innerhalb der Serversoftware.
Wenn jeder seinen XMPP-Server selber hostet, sind die Metadaten hier die Verbindungen zwischen den Servern über's Internet (z.B. durch den decix).

Damit macht typischerweise mindestens ein ISP entsprechendes Verbindungs-Handling, vermutlich mehrere.

@larma Metadaten sind "was wann wohin geschickt wird". Bei Signal oder Threema passiert dieses Routing innerhalb eines zugemauerten Systems, bei einer everyone-selfhosts-Lösung passiert dieses Routing über die öffentliche (und, für diese Frage durch (mehrere) Dritte einsehbare) Netzwerkinfrastruktur, selbst wenn da noch TLS drumrum ist.

@larma

> "warum du der Meinung bist"

Ist nicht nur meine Meinung, das kannst du so in Präsentationen der Matrix-Core-Devs nachlesen, da haben sie explizit drinstehen, dass Federation die "Surveillance-Surface", wie sie es iirc nennen, erhöhe (aus dem beschriebenen Grund). :)

@cherti Sorry aber du bringst da glaube ich einiges durcheinander.
Erstmal sind Metadaten alles, was nicht Inhaltsdaten sind, nicht nur "was wann wohin geschickt wird" sondern auch, "wer wann online ist" und ähnliches.
Bei Metadaten muss man aber auch noch unterscheiden zwischen Netzwerk-Metadaten (sowas wie IP-Adressen) und Nutz-Metadaten (sowas wie den Empfänger einer Nachricht).

@cherti
Netzwerk-Metadaten sind in der Regel aus technischen Gründen unverschlüsselt, werden aber in föderierten Netzwerken nicht über die Punkt-zu-Punkt-Verbindung hinaus weitergeleitet - der Server des Empfängers erfährt also nicht die IP-Adresse des sendenden Clients.

@cherti
Nutz-Metadaten werden heutzutage üblicherweise transportverschlüsselt (also mit TLS) übertragen. Das bedeutet, dass ausschließlich die involvierten Parteien (also sendender und empfangende Clients und die zugehörigen Server) diese sehen können. Das ist bei Signal genauso wie bei XMPP. Der einzige Unterschied ist, dass bei XMPP die Verbindung zwischen sendenden Server und empfangenden Server nicht "in-house" erfolgt, sondern über eine TLS-verschlüsselte Verbindung durch das Internet.

@cherti "in-house" hier in Anführungsstrichen, weil eigentlich alle großen zentralisierten Anbieter inklusive Signal nicht wirklich in-house arbeiten, sondern bei einem oder mehreren Cloud-Anbietern in verschiedenen Rechenzentren gehostet sind.

@cherti
Natürlich kann man annehmen, dass TLS-Verbindungen zwischen zwei Servern nicht ausreichend sicher sind, dann müsste man aber korrekterweise auch gleichzeitig annehmen, dass die TLS-Verbindung zwischen Client und Server nicht sicher ist. Die Nutz-Metadaten sind dann bei allen Systemen, wo diese TLS-verschlüsselt übertragen werden gleich unsicher, unabhängig davon ob sie 2 mal (Client->Server->Client) oder 3 mal (Client->Server->Server->Client) übertragen werden.

@larma Das ist richtig, und die Nutz-Metadaten stehen hier auch nicht in Frage (auch wenn die bei XMPP stärker anfallen als in Signal).

Aber die Netzwerk-Metadaten sind im Fall von Federation von außen sichtbar, auch wenn auf der Leitung TLS gesprochen wird.
Und wenn ich self-hoste und wenn du self-hostest, dann kann der ISP sehen, wann ich dir schreibe und wann du mir schreibst. (Außer wir bauen künstliches Delay ein, und selbst das versteckt nur den Zeitpunkt, nicht aber die Tatsache.)

@larma Im Fall von Signal ist das "in-house" dadurch obfuskiert, dass die dort 1.5 Mio verschlüsselte Blobs durch die Gegend schubsen, damit der Noise-Pegel sehr hoch ist, aber bei selfhosting hat jeder Teilnehmer eine konkrete Adresse und die Netzwerkpakete dazwischen laufen durch's offene Internet, wo sie von außen sichtbar sind. D.h. wer-mit-wem-wann ist von außerhalb des Systems nachzuvollziehen (während du bei Signal oder Threema dafür erstmal in das System rein musst.)

@cherti ich verstehe self-hosten nicht unbedingt so, dass nur eine Person den Server nutzt. In der Tat ist bei weniger Traffic die Korrelation des Netzwerkverkehrs einfacher, bei zentralen Strukturen muss man dafür an weniger Punkten Daten mitlesen. Allerdings reichen bei Signal bereits 4 Nachrichten innerhalb weniger Minuten, dass man mit Sicherheit durch Netzwerkanalyse feststellen kann, dass zwei IP-Adressen miteinander kommunizieren.

@larma naja, wenn nicht jeder seinen eigenen Server nutzt, dann ist das Modell für die überwältigende Mehrheit der Nutzer fast identisch zur Situation in Signal (der Unterschied ist lediglich, dass die Kommunikationsmetadaten potentiell nicht nur bei einem Server, sondern bei mehreren anfallen, also eigentlich sogar schlechter).

Show newer

@kuketzblog Bei Signal auf iOS kann ich diese Icons nicht sehen. Schalter ist schon immer aktiviert.

@kuketzblog Danke für den Hinweis. Es war bei mir unter iOS auch nicht aktiviert. Ich vermute das es ggf. bei alten Installationen doch nicht standardmässig aktiviert ist, weil neu hinzugekommen?

@kuketzblog Ja, auch bei mir war die Standardeinstellung genau umgekehrt ("anzeigen" aus, "von allen" an).
Nur: Wie sende ich denn jetzt Nachrichten mit Sealed Sender? Passiert das automatisch? Ich kann das offenbar nirgends auswählen. Und Briefsymbol sehe ich nur bei den Nachrichten vom Signal-Bo selbst

@kuketzblog Der Disclamer ist übrigens so nicht korrekt. Die Signal-Serverflotte sitzt schon länger nicht mehr nur in AWS, und wenn der Sender in AWS, der Empfänger aber in Azure abgewickelt wird, müssten Microsoft und Amazon zusammenarbeiten. Damit ist der Disclamer, so wie er da gerade steht, mindestens unvollständig.

(Dasselbe Argument kann man übrigens auch bei Hosting in einem Datencenter bringen, selbst wenn mir das Blech eigentlich gehört.)

@kuketzblog Ok, dann hab ich den Disclamer nicht ganz verstanden: Wie kann Amazon Traffic-correllation der IP-Adressen machen, wenn Nur der Sender bei AWS ankommt, der Empfänger aber über die Microsoft-Cloud abgewickelt wird?

@cherti Ja, was in meinem Kopf ist, steht nicht im Beitrag. 😁

Was Ich sagen will: Das funktioniert nur, wenn die Kommunikation in diesem Fall über einen Anbieter (bspw. Amazon) stattfindet. Ansonsten müssen sie eben zusammenarbeiten bzw. kooperieren.

Sign in to participate in the conversation
Mastodon

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!