So prüfen Sie, dass browserlokale Verschlüsselung keinen Klartext sendet

Ob „browserlokale Verschlüsselung“ Vertrauen verdient, entscheidet nicht der Leitspruch, sondern welche Anfragen dieser Vorgang gesendet hat. Suchen Sie in Network mit einer Canary-Zeichenfolge, die nur in diesem Experiment vorkommt: Anfragezeilen, Bodies und Analytics dürfen weder Klartext noch Passphrase noch den Schlüssel hinter # enthalten. AES-256-GCM muss lokal in Web Crypto fertig sein, bevor Chiffretext das Gerät verlässt.

Zuerst das Fazit: Vor Ort prüfbar ist, ob diese HTTP-Anfrage Klartext, eine Passphrase oder einen Schlüssel im # fragment als Geschäftsdaten gesendet hat. Das beweist nicht, dass keine Erweiterung die Zwischenablage gelesen hat, und nicht, dass die nächste Version gleich bleibt. Die folgenden Schritte sind wiederholbar – keine neuen Adjektive.

Die Suchintention in einem Satz beantworten

Browserlokale Verschlüsselung heißt: Ver- und Entschlüsselung laufen in dem Tab, den Sie gerade sehen. Das Skript ruft die Web Crypto API des Browsers auf, führt Algorithmen der Klasse AES-GCM lokal aus, und Klartext sowie Schlüssel verlassen den Browser standardmäßig nicht als HTTP-Body. Die Prüfung ist kein Marketingsatz: Öffnen Sie DevTools Network, suchen Sie eine Canary-Zeichenfolge, und wiederholen Sie den Test bei Bedarf offline.

Dieser Artikel richtet sich an Entwicklung, Betrieb und alle, die eine Datei oder Passphrase an ein „Online-Tool“ geben wollen und vorher selbst nachsehen. Er ersetzt nicht die Anleitung der Datei-Verschlüsselungsbox und wiederholt nicht die Produktdefinition der Startseite. Mitnehmen sollten Sie eine Prüfung, die Sie auf jeder Website wiederverwenden können.

Slogans beweisen sich nicht selbst; Datenverkehr lässt sich beobachten

Viele Seiten schreiben lokale Berechnung, kein Upload und Ende-zu-Ende. Diese Wörter können auf einem Tool stehen, das wirklich auf diesem Gerät fertig rechnet – oder auf einer Upload-Seite, die den Originaltext per POST schickt, damit ein Server ihn verschlüsselt. Der Satz selbst hat keine Prüfsumme.

Was Sie unmittelbar sehen, sind Methode, Adresse, Query-String und Request-Body, die dieser Tab gesendet hat. Das Network-Panel von Chrome listet sie auf. Erscheinen dort der Dateiname, den Sie gerade gewählt haben, die Passphrase, die Sie gerade eingegeben haben, oder ein Testtext, den nur Sie kennen, dann hat lokale Verschlüsselung bei diesem Vorgang nicht gehalten.

Umgekehrt gilt nur ein enger Schluss: Kein Klartext im Panel heißt nur, dass die beobachteten Anfragen diese Felder nicht mitgenommen haben. Es heißt nicht, dass im Speicher kein Klartext war, und nicht, dass eine Browser-Erweiterung das Eingabefeld nicht gelesen hat. Marketing in eine wiederholbare Beobachtung zu verwandeln, reicht schon: Sie können Kollegen sagen „Ich habe den Canary gesucht; Anfragezeile und Body sind sauber“ – statt einen Satz von der Startseite weiterzuleiten.

Experimentieren Sie nicht mit einem echten Schlüssel, einer Ausweisnummer oder einer ungeschwärzten Tabelle. Bereiten Sie eine wegwerfbare kleine Datei vor und eine einmalige lange Passphrase. Sie prüfen den Datenverkehr – Sie sollen Privates nicht erneut preisgeben.

Welche Schicht „lokal“ wirklich meint

„Browser-lokal“ heißt nicht „diese Domain wirkt sicher“, sondern „die kryptographischen Operationen laufen in der Skriptumgebung des aktuellen Dokuments“. Für AES-256-GCM ist der übliche korrekte Weg crypto.subtle.encrypt: Schlüsselableitung, Verschlüsselung und Authentisierungs-Tag laufen über die eigene Schnittstelle des Browsers. MDN schreibt, dass SubtleCrypto.encrypt nur in einem sicheren Kontext verfügbar ist – in Produktion also HTTPS. Auf einer gewöhnlichen HTTP-Seite ist crypto.subtle oft undefined.

AES-GCM wird nicht wegen des Namens gewählt. Es ist authentisierte Verschlüsselung mit Integritätsprüfung: Wurde der Chiffretext verändert oder der falsche Schlüssel verwendet, schlägt das Entschlüsseln fehl – statt „Müll, der wie Klartext wirkt“ auszugeben. Der IV ist meist 12 Byte (96 Bit), passend zur Empfehlung von NIST SP 800-38D für GCM. Jede Verschlüsselung sollte einen neuen zufälligen IV nutzen, damit derselbe Klartext unterschiedlichen Chiffretext ergibt.

Ein Dateivorgang lässt sich als konkrete Schritte schreiben: Sie wählen eine lokale Datei, das Skript liest sie blockweise, verschlüsselt jeden Block und löst den Browser-Download des Chiffretexts aus. Die heruntergeladene .lock- oder .enc-Datei hat dieses Gerät erzeugt – es ist keine Serverquittung. Eine Obergrenze von 5 GB pro Datei beschreibt das Streaming im Browser; sie bedeutet nicht, dass ein entfernter Rechner 5 GB Klartext erhalten hat.

Trennen Sie außerdem „fachlichen Upload“ von „Anfragen, die die Seite ohnehin sendet“. Eine sofort nutzbare Tool-Seite lädt weiter Styles, Skripte und Schriften und kann eine Zugriffsstatistik ohne Textkörper senden. Diese Anfragen beweisen nicht, dass „die Datei hochgeladen wurde“. Stehen in Query oder Body einer Statistik jedoch die Passphrase, die Sie gerade eingegeben haben, ein geprüftes Passwort oder der Text vor der Schwärzung, ist das etwas anderes.

FastPwd schreibt diese Grenze als Satz, den Sie prüfen können: Klartext und Schlüssel von Passwort-Generierung, Passwortprüfung, Datenschutz-Bereinigung sowie Datei-Ver- und Entschlüsselung verlassen den Browser standardmäßig nicht; Burn-Link lässt nur Chiffretext nach außen, der Entschlüsselungsschlüssel liegt im #-Fragment der URL. Die Datei-Verschlüsselungsbox teilt in 1-MB-Blöcke und leitet mit PBKDF2 (100000 Iterationen, SHA-256) aus der Passphrase einen AES-256-Schlüssel ab, Ausgabe .lock / .enc. Alle Tools sind sofort nutzbar – kein Konto, kein Passwort-Tresor. Ein Versprechen bleibt ein Versprechen. Unten macht Network daraus eine Prüfliste.

Eine Canary-Prüfung in Network durchführen

Bereiten Sie zuerst eine Markierung vor, die in echter Arbeit nicht vorkommt. Als Dateiname eignet sich canary-fp-20260825.bin, als Passphrase ein zufälliger langer Satz, im Text eine Zeile, die nur in diesem Versuch steht. Der Canary dient der Suche: Im Network-Filter einfügen; ein Treffer ist ein Fehlschlag.

Öffnen Sie die DevTools, wechseln Sie zu Network, aktivieren Sie Preserve log und setzen Sie den Filter zuerst auf All – lassen Sie nicht nur XHR stehen. Auch eine abgebrochene oder mit 4xx beantwortete Anfrage kann bereits Klartext getragen haben. Führen Sie dann einen vollständigen Vorgang aus: Datei wählen, Passphrase eingeben, Verschlüsseln oder Generieren anklicken. Schließen Sie das Panel danach nicht.

  1. Fügen Sie den Canary in den Filter ein. Ein roter Treffer heißt: anhalten und diese Anfrage lesen – nicht auf „fühlt sich lokal an“ zurückfallen.
  2. Gibt es keinen Treffer, öffnen Sie Fetch / XHR einzeln und prüfen Sie Anfragezeile, Query-String und Body. Styles, Schriften und Skripte können Sie übergehen.
  3. Filtern Sie Statistikpfade gesondert und öffnen Sie Query und Body. Seitentitel und Pfad dürfen erscheinen; die gerade eingegebene Passphrase, ein geprüftes Passwort, der Text vor der Schwärzung und Dateiinhalt dürfen nicht.

Die Anfragezeile lesen

Pfad und die Query hinter dem Fragezeichen verdienen eine Zeichen-für-Zeichen-Prüfung. Locator-Felder wie id dürfen erscheinen; Dateiname, Passphrase, geprüftes Passwort oder der Schlüssel hinter # dürfen nicht. Vergleichen Sie die ganze Adresszeile mit der Anfragezeile: Landet der Teil nach # in der Anfragezeile, hat die Umsetzung ein Fragment als Query behandelt – oder ein Skript hat ihn gelesen und in eine Anfrage geschrieben.

Den Request-Body lesen

Die Nutzlast von POST / PUT ist die zweite Stelle. Beansprucht Dateiverschlüsselung, lokal fertig zu sein, dürfen im Body weder die Originalbytes der Datei noch die Passphrase stehen. Burn-Link darf ein Chiffretext-Feld haben – das ist erwarteter Ausgang; prüfen Sie, dass er nicht wie der gerade eingegebene Klartext aussieht. Sendet eine Passwortprüfung das geprüfte Passwort per POST, hat es dieses Gerät bereits verlassen – unabhängig davon, ob der Zweck „Leak-Abfrage“ oder „Stärke berechnen“ heißt.

Analytics gesondert prüfen

Zugriffsstatistik wird oft übersehen. Eine saubere Haupt-API plus ein Bericht mit dem ganzen Eingabefeld heißt immer noch: Dieser Vorgang hat „Klartext im Browser“ nicht gehalten. Wenn Sie Statistikpfade filtern, unterstellen Sie nicht „das Analyse-Skript ist harmlos“ – es ist eine weitere ausgehende Anfrage, geprüft wie eine fachliche API. Die Zugriffsstatistik von FastPwd läuft über den eigenen Tracker der Site und sendet von localhost standardmäßig nicht; trotzdem sollten Sie mit dem Canary bestätigen, dass im Bericht keine Passphrase und kein Dateiinhalt stehen.

Aktivieren Sie Preserve log. Springt oder lädt die Seite nach dem Verschlüsseln neu und die Option ist aus, kann die erste Anfrage mit Klartext schon weg sein – und Sie erhalten ein falsches „das Panel ist leer“.

Offline erneut prüfen: Statische Ressourcen sind kein fachlicher Upload

Die zweite Gegenprobe ist preiswert. Lassen Sie die Seite vollständig laden, schalten Sie in Network Offline ein – oder trennen Sie das Systemnetz – und verschlüsseln Sie die wegwerfbare kleine Datei. Schließt der Download der .lock trotzdem ab, brauchte diese Ver- und Entschlüsselung keine live API. Das ist ein starkes Signal für „Browser-lokale Verschlüsselung“, aber nicht das einzige.

Scheinbare Fehlschläge sind häufig: Eine Schrift oder ein Analyse-Skript, das unter Offline rot wird, ist kein Verschlüsselungsfehler. Achten Sie darauf, ob nach dem Klick auf Verschlüsseln eine neue fachliche POST-Anfrage erscheint und ob die Ergebnisdatei schon im Download-Ordner liegt. Es gibt auch scheinbare Erfolge: Ein Skript kann Klartext zwischenspeichern und senden, sobald Sie wieder online sind. Offline muss also bestehen – online suchen Sie trotzdem noch den Canary.

Das Fragezeichen geht in HTTP, die Raute standardmäßig nicht

Eine URL hat zwei Teile, die oft vermischt werden. Die Query hinter dem Fragezeichen landet in der HTTP-Anfragezeile; Server, Reverse-Proxys und Zugriffsprotokolle können sie sehen. Das Fragment hinter # bleibt standardmäßig im Browser, damit das Skript der aktuellen Seite es lesen kann. Das HTTP-Request-Target enthält kein Fragment – das ist die Vereinbarung von RFC 9110 zum Request-Target und der Grund, warum URL.hash nur auf der Browserseite existiert.

Liegt der Schlüssel eines einmaligen Chiffretext-Links daher in #, sieht der Server beim Öffnen von s.html?id={id}#{key} nach Design nur id, nicht den Schlüssel. Das ist kein zusätzliches Krypto-Protokoll, sondern das Standardverhalten des Browsers für Fragmente. Es hat Grenzen: Fügen Sie die volle Adresse in ein Ticket, einen Gruppenchat oder eine Vorschaukarte ein, die den Hash verwirft, wandert der Schlüssel von „geht nicht in HTTP“ zu „steht auf fremden Bildschirmen und in fremden Protokollen“.

Die Prüfung ist ebenso konkret: Legen Sie in Burn-Link einen harmlosen Testtext an und sehen Sie, ob der Body der Erstellungsanfrage nur Chiffretext enthält; auf der Leseseite prüfen Sie, ob Dokumentanfrage und spätere APIs in der URL nur id tragen. Der Teil hinter # in der Adresszeile darf in diesen Anfragen nicht erscheinen. Die Leseseite ist für Empfänger öffentlich – keine Anmeldung.

Wohin schauen Geht es in HTTP? Was als bestanden zählt
Seiten-Slogan Nicht betroffen Kein Beweis – nur zum Abgleich
Anfragezeile / Query Ja Kein Canary, keine Passphrase, kein Fragment-Schlüssel
POST-Body Ja Kein Klartext; Burn-Link darf nur Chiffretext senden
URL-#-Fragment Standardmäßig nein In der Adresszeile, nicht in der Anfragezeile
Zugriffsstatistik Hängt von der Umsetzung ab Kein Klartext aus dem Eingabefeld
Nach Offline verschlüsseln Keine neue fachliche Anfrage Chiffretext wird trotzdem heruntergeladen; online erneut den Canary suchen

Was Sie beweisen können – und was nicht

Die Schlussfolgerung, die diese Prüfung trägt, ist eng. Sie aufzuschreiben macht sie nützlicher.

Sie kann stützen: In diesem Browser, dieser Version und bei diesem Vorgang haben Klartext, Passphrase und Fragment-Schlüssel den Tab nicht als beobachtete HTTP-Nutzdaten oder Statistik-Klartext verlassen.

Sie kann nicht stützen: Kein anderer Tab und keine Erweiterung liest die Zwischenablage; der Download-Ordner auf der Festplatte ist sicher; der Empfänger fertigt keinen Screenshot des Chiffretexts an; die Passwortprüfung hat einen netzweiten Leak-Korpus abgedeckt. Prüft sie nur lokale Entropie plus eine öffentliche Top-Liste schwacher Passwörter, beantwortet sie „wirkt das wie ein übliches schwaches Passwort“, nicht „es kam nie in einem Leak vor“. Das ist keine netzweite Have I Been Pwned-Abfrage.

Lesen Sie es auch nicht als Penetrationstest. Sie haben weder WebSockets noch Service-Worker-Caches geprüft und kein minifiziertes Skript zurückgebaut. Das Ziel ist, Kollegen erklären zu können: Ich habe Network geöffnet, einen Canary gesucht, Anfragezeile und Body sind sauber. Das liegt näher an einer technischen Diskussion als das Weiterleiten von „die Site sagt, es wird nichts hochgeladen“.

FAQ

Wenn es offline noch verschlüsselt – beweist das, dass nichts hochgeladen wurde?

Es beweist nur, dass diese Ver- und Entschlüsselung keine live API brauchte. Bereits zwischengespeicherte Skripte der Seite können, sobald Sie wieder online sind, noch nachsenden. Offline muss also bestehen – online suchen Sie in Network erneut mit demselben Canary. Beide Schritte müssen bestehen, bevor die Schlussfolgerung trägt.

Wenn das Network-Panel leer ist – war dieser Vorgang sicher?

Nein. Ein Filter, der nur Img lässt, deaktiviertes Preserve log oder eine Anfrage, die beim Wechsel gelöscht wurde, erzeugen alle eine falsche Leere. Stellen Sie den Filter auf All, suchen Sie den Canary und öffnen Sie Statistikberichte gesondert. Ein leeres Panel ist eine gescheiterte Beobachtung, kein Sicherheitsbeweis.

Burn-Link legt Chiffretext auf dem Server ab – ist das noch browserlokale Verschlüsselung?

Das zählt als „Klartext lokal fertig gerechnet, dann geht Chiffretext nach außen“. Der Server sollte nur Chiffretext und eine Lookup-id sehen; der Entschlüsselungsschlüssel steht hinter der Raute im Link und geht standardmäßig nicht in HTTP. Erstellen und Lesen brauchen kein Konto. Prüfen Sie, dass der Body kein Klartext ist und dass die Anfragezeile den Schlüssel hinter # nicht enthält.

Sendet die Passwortprüfung das geprüfte Passwort an eine webbreite Leak-Datenbank?

Die Passwortprüfung von FastPwd bewertet die Stärke auf diesem Gerät und gleicht eine eingebaute öffentliche Liste schwacher Passwörter ab. Das geprüfte Passwort wird nicht hochgeladen. Sie fängt übliche schwache Passwörter, kann aber nicht „im Netz nie gesehen“ beweisen und ist keine Abfrage im Stil von Have I Been Pwned. Suchen Sie das geprüfte Passwort als Canary in Network, um genau das zu prüfen.

Dieselben Schritte an einem sofort nutzbaren Tool üben

Wenn Sie an einer Seite mit klar beschriebener Rechengrenze üben möchten, beginnen Sie mit der Datei-Verschlüsselungsbox von FastPwd. Sofort nutzbar, keine Registrierung. Wählen Sie eine kleine Datei ohne echte Privatsphäre, nutzen Sie einen Canary als Passphrase, verschlüsseln Sie und laden Sie eine .lock herunter. Beobachten Sie gleichzeitig Network: Sie sollten statische Ressourcen und möglicherweise Zugriffsstatistik sehen, nicht die Originaldatei oder die Passphrase als fachliche Felder. Der Algorithmus ist AES-256-GCM in Web Crypto; eine einzelne Datei höchstens 5 GB.

Burn-Link eignet sich als zweite Übung: Legen Sie einen harmlosen Testtext an und bestätigen Sie, dass nach außen Chiffretext geht; die Leseseite ist für Empfänger öffentlich, die Linkform ist s.html?id={id}#{key}. Die Datenschutz-Bereinigung eignet sich für „gerät der Originaltext in die Statistik“ – Links und zu schwärzender Text bleiben laut Produktbeschreibung im Browser; ob das bereinigte Ergebnis reicht, entscheiden weiter Sie.

Diese Übungen sollen nicht beweisen, dass eine bestimmte Site „absolut sicher“ ist. Sie sollen dieselbe Prüfreihe vertraut machen. Auf jeder Seite, die lokale Verschlüsselung behauptet, bleiben die Schritte gleich: Canary, Preserve log, Anfragezeile, Body, Statistik – und bei Bedarf Offline.

Merken Sie sich beim nächsten Prüfen drei Dinge. Erstens: Schauen Sie auf den Datenverkehr, nicht auf Slogans. Zweitens: Ausgehender Chiffretext ist akzeptabel; Schlüssel und Klartext nicht. Drittens: Nach Wechsel von Browser, Version oder Funktion die Canary-Suche erneut ausführen. Nur eine wiederholbare Beobachtung gehört in Ihre eigenen Sicherheitshinweise.