Verschlüsselungsgrundlagen
HTTPS und Nachrichtenverschlüsselung sind nicht dasselbe
Der Unterschied zwischen dem Schutz einer Verbindung und der Verschlüsselung einer Nachricht vor dem Verlassen des Browsers.
Veröffentlicht: 29. März 2026
Grenzen der aktuellen Implementierung
Der aktuelle Client verschlüsselt den Text im Browser und legt den verschlüsselten Inhalt in der URL ab. Das separat geteilte Passwort gehört nicht zum Link. Es gibt keinen Anwendungsserver zum Speichern, Abrufen, Löschen oder als Einmalansicht für Nachrichten.
Weiterer Kontext
Stellen Sie sich zwei Umschläge vor.
Der erste wird durch einen bewachten Tunnel transportiert, am Ziel geöffnet und den Mitarbeitenden eines Büros übergeben. Das ähnelt HTTPS.
Die Analogie ist unvollkommen. Webserver sind keine Büros, TLS ist kein Tunnel, und JavaScript verwandelt einfache Analogien gern in Architekturdiagramme. Die Unterscheidung ist trotzdem nützlich.
Ohne HTTPS kann möglicherweise jemand auf dem Netzwerkpfad den Datenverkehr beobachten oder verändern.
Collogue muss HTTPS unabhängig von einer zusätzlichen Nachrichtenverschlüsselung verwenden. Browser-Kryptografie, die über eine nicht vertrauenswürdige Verbindung ausgeliefert wird, könnte vor ihrer Ausführung ersetzt werden.
HTTPS schützt den Transportweg. Die Zielanwendung kann den Inhalt trotzdem verarbeiten.
Ob sie das tut, ist eine Entscheidung der Anwendung.
Bei browserseitiger Nachrichtenverschlüsselung wandelt die Seite den Klartext in Chiffretext um, bevor die Anfrage zum Erstellen gesendet wird.
Das macht TLS nicht optional. Die Verbindung überträgt weiterhin Kennungen, Chiffretext, Anwendungscode und Betriebsmetadaten. Ein Angreifer, der die Seite verändern kann, könnte den Verschlüsselungsprozess beeinflussen.
Eine sinnvolle Sicherheitsprüfung betrachtet mindestens vier Zustände.
Der Klartext befindet sich im Browser des Absenders.
Zu den Risiken gehören bösartige Erweiterungen, Skripte, Schadsoftware, das Mitlesen über die Schulter sowie versehentliches Kopieren und Einfügen.
Die Anfrage kann je nach Anwendung Klartext oder Chiffretext enthalten.
Der Klartext befindet sich im Browser des Empfängers.
Der Empfänger kann ihn lesen – ebenso ausreichend privilegierte Software auf diesem Gerät.
Eine Sicherheitsaussage, die nur einen dieser Zustände betrachtet, ist unvollständig.
- Klartext vor der Verschlüsselung kopieren;
- den Schlüssel an einen anderen Endpunkt senden;
- die Zufallserzeugung schwächen;
- einen Algorithmus ersetzen;
- den Ziellink verändern.
Das ist kein Argument gegen Browser-Kryptografie. Es ist ein Argument für genaue Bedrohungsmodelle, sichere Auslieferung, Content-Security-Kontrollen, Transparenz des Quellcodes, reproduzierbare Builds, wo praktikabel, und unabhängige Prüfungen.
Clientseitige Verschlüsselung kann eine andere Grenze schaffen, wenn die Anwendung den Nachrichtenschlüssel nie erhält.
Auch hier gilt: Prüfen Sie Collogue, statt zu verallgemeinern.
Kann jemand im Netzwerk diese Verbindung beiläufig lesen oder verändern?
In welcher Form erreicht die Nachricht die Anwendung?
Wer besitzt das, was zur Entschlüsselung erforderlich ist?
Wie lange und wie oft gibt der Dienst sie zurück?
Diese Kontrollen ergänzen einander. Keine sollte sich den Verdienst einer anderen anrechnen lassen.
Nein. HTTPS schützt die ausgelieferte Anwendung, Anfragen, Kennungen und Chiffretext vor Manipulation und Beobachtung im Netzwerk.
Ja. TLS wird normalerweise beim Dienst beendet; danach verarbeitet die Anwendung die übermittelten Werte.