Wie du prüfst, dass Browser-Verschlüsselung keinen Klartext hochlädt

Suchst du nach «Datei im Browser verschlüsseln» oder «client-seitige Verschlüsselung», stehen auf den Trefferseiten fast immer dieselben Sätze: Die Rechnung läuft lokal, die Datei wird nicht hochgeladen, der Schlüssel verlässt das Gerät nicht. Die Sätze beruhigen. Beweisen tun sie nichts. Eine Seite kann sie drucken, während ein Skript trotzdem das Passwort aus dem Formular, ein Stück Datei oder den Schlüssel aus der Adresszeile per fetch wegschickt. Was du prüfen musst, ist nicht der Werbetext. Es ist, ob genau diese eine Aktion Klartext aus dem Browser geschickt hat.

Dieser Text ist kein Produktvergleich und keine Funktionsliste einer Tool-Seite. Die Frage ist enger: Wenn eine Seite behauptet, sie verschlüssele im Browser — was siehst du jetzt in den Entwicklertools und in der Adresszeile? Dateiverschlüsselung und Einmal-Links bei MyPassGen rechnen AES-256-GCM über die Web Crypto API, und jedes Tool öffnet ohne Konto. Dieselbe Prüfung gilt für sie. Du musst «wir speichern das nicht» nicht glauben.

Slogans prüfst du nicht. Traffic schon

«Client-seitige Verschlüsselung» ist ein abgenutzter Satz. Eine Seite schickt die Datei per POST auf den eigenen Server, packt sie dort in AES und gibt einen Download-Link zurück — und nennt das trotzdem «Online-Verschlüsselung». Eine andere ruft im Tab crypto.subtle.encrypt auf, schreibt eine .lock- oder .enc-Datei und sendet keinen fachlichen Upload. Marketingseiten können beide Abläufe in einen Satz pressen. Das Network-Panel kann das nicht.

Der Browser prüft den Slogan nicht. Er listet den Dokumentrequest, Skripte, Bilder und die XHR-/Fetch-Aufrufe, die dieser Klick ausgelöst hat. Du siehst, ob die Request-URL Klartext trägt, ob der Body eine Passphrase enthält und ob ein Analytics-url den Schlüssel hinter # mitschickt. Fehlen diese Zeichenketten, steht «verlässt dieses Gerät standardmäßig nicht» noch. Stehen sie da, ist der Slogan schon tot.

Du musst den Quelltext nicht lesen. Du brauchst einen wiederholbaren Durchgang: Panel öffnen, eine konkrete Sache tun (Passwort erzeugen, eine wegwerfbare Passphrase prüfen, eine kleine Datei verschlüsseln oder einen Einmal-Link anlegen), dann jeden neuen Request aufklappen. Zuerst trennst du, was «lokal» meint. Dann Raute und Query. Dann die Schritte.

Was «lokal» genau meint

Die Web Crypto API ist die Krypto-Schnittstelle des Browsers. Über crypto.subtle hashst, leitest, verschlüsselst und entschlüsselst du. Die W3C-Anwendungsfälle nennen ausdrücklich eine erlaubte Architektur: Der Nutzer wählt den Schlüssel im Browser, verschlüsselt das Dokument und lädt danach die verschlüsselten Bytes zum Anbieter hoch. Die API garantiert, dass die Rechnung auf diesem Gerät laufen kann. Sie verbietet nicht, später Geheimtext zu senden. Und sie hindert niemanden daran, zuerst hochzuladen und erst danach zu verschlüsseln.

Web Crypto verlangt außerdem einen sicheren Kontext: in Produktion HTTPS (localhost ist die übliche Ausnahme). Das ist eine Voraussetzung, kein Verkaufsargument. Behauptet eine Seite unter klarem HTTP, sie «nutze Web Crypto», schau zuerst auf das Schloss in der Adresszeile, bevor du über Algorithmen streitest.

Was AES-256-GCM auf diesem Gerät wirklich bedeutet

MyPassGen nutzt in der ersten Fassung nur AES-256-GCM. Laut MDN AesGcmParams und der dort zitierten NIST SP 800-38D ist GCM authentisierte Verschlüsselung: Wird der Geheimtext verändert, schlägt das Entschlüsseln fehl. Du bekommst keinen verstümmelten Text, der noch wie ein Dokument aussieht. Der empfohlene Initialisierungsvektor (IV) hat 96 Bit — 12 Byte — und unter demselben Schlüssel brauchst du für jede Verschlüsselung einen frischen IV. Der IV ist kein Geheimnis; er darf mit dem Geheimtext reisen. Das Authentication Tag ist standardmäßig 128 Bit. Diese Zahlen kannst du in einer Implementierung nachzählen. Es sind keine Slogans zum Auswendiglernen.

Bei Dateien wird der Schlüssel zusätzlich aus einer Passphrase abgeleitet. Die Dateibox auf dieser Seite nutzt PBKDF2 mit 100.000 Iterationen, SHA-256 und 16 Byte Salz, danach einen 256-Bit-AES-GCM-Schlüssel. Eine Datei darf höchstens 5 GB groß sein. Die Ausgabe ist .lock oder .enc. Wird die Passphrase zusammen mit der Datei per POST geschickt, rettet dich die Iterationszahl nicht. Das erste Prüfobjekt bleibt der Traffic, nicht die Schlüsselableitung.

Drei völlig verschiedene «Online-Verschlüsselungen»

Ausgelegt zerfallen die Abläufe in mindestens drei Klassen. Erstens: Der Tab wählt nur die Datei; die Bytes gehen auf einen Server; verschlüsselt wird gegenüber. Zweitens: Der Tab verschlüsselt zuerst, lädt nur Geheimtext hoch, und der Schlüssel läuft über einen anderen Kanal (zum Beispiel # in der URL). Drittens: Das Ergebnis landet als Download auf diesem Gerät, und kein fachlicher Request trägt einen Dateibody. Alle drei lassen sich als «Verschlüsselung auf einer Webseite» verkaufen. Nur die letzten beiden dürfen behaupten, Klartext werde standardmäßig nicht hochgeladen. Deine Aufgabe: Mit dem Network-Panel entscheiden, zu welcher Klasse diese Seite gehört.

Raute und Fragezeichen sind nicht dasselbe

Eine URL zerfällt in Schema, Host, Pfad, Query (hinter ?) und Fragment (hinter #). RFC 3986 §3.5 nennt den Teil hinter # Fragment: Er bezeichnet eine sekundäre Position, die der Client erst deutet, nachdem die Hauptressource angekommen ist. MDN zum URI-Fragment sagt es klarer: Fordert der Browser diese URI an, wird das Fragment nicht an den Server geschickt. Der Client verarbeitet es, nachdem die Ressource da ist.

Der Query-String ist das Gegenteil. Öffnest du einen https-Link, wandern die Name=Wert-Paare hinter ? in die Request-Zeile und in die Access-Logs gegenüber. Der vorherige Text, welche URL-Parameter du beim Teilen entfernen darfst, hat utm_source und id= schon als Query-Namen behandelt. Schreibst du einen Schlüssel als ?key=, sehen ihn Server, Reverse-Proxy und CDN-Logs. Schreibst du ihn hinter #, enthält die Standard-Request-Zeile dieses Stück nicht.

Referer streicht das Fragment ebenfalls. MDN Referer erlaubt Origin, Pfad und Query. Ein URL-Fragment sowie Benutzername und Passwort dürfen nicht mit. Die W3C-Referrer Policy leert das Fragment im Schritt «strip for use as a referrer» ebenfalls. «Schlüssel hinter #, dann bekommt die Maschine, die den Geheimtext hostet, ihn nicht über HTTP» ist also Protokollverhalten. Es ist kein Versprechen eines Anbieters.

Ein Einmal-Link auf dieser Seite sieht so aus: s.html?id={id}#{key}. Die Query trägt nur die Geheimtext-ID; der Schlüssel steht nur hinter der Raute. Beim Anlegen baut der Tab einen 32-Byte-Zufallsschlüssel, rechnet AES-256-GCM mit 12-Byte-IV und POSTet danach den Geheimtext. Beim Lesen holt das Skript den Schlüssel aus location.hash und entschlüsselt auf diesem Gerät. Klartext ist auf 32 KB begrenzt. Was du prüfst: Das Create-JSON soll ein Geheimtext-Feld haben und nicht den Originalsatz; der Dokumentrequest der Leseseite soll id= zeigen und nicht das Stück hinter #.

Im Network-Panel nachprüfen

Chrome, Edge, Firefox und Safari liefern alle ein Netzwerk-Panel. Die Namen weichen leicht ab. Die Schritte nicht. Du brauchst keine Erweiterung und keinen Dritt-«Scanner» — die volle URL oder die Datei noch einmal hochzuladen, vergrößert nur die Angriffsfläche.

1. Öffne die Entwicklertools und wechsle auf Network (Netzwerk). Aktiviere «Protokoll beibehalten / Preserve log», damit ein Seitenwechsel die Liste nicht leert.
2. Filter auf Fetch / XHR (oder «XHR»). Statische Dateien können warten. Fachliche Uploads laufen fast immer über diese Request-Klasse.
3. Tu die Sache, die du prüfen willst: Passwort erzeugen, eine wegwerfbare Testpassphrase tippen, eine URL mit UTM-Parametern einfügen, eine kleine Datei zum Verschlüsseln wählen oder einen Wegwerf-Satz schreiben und einen Einmal-Link anlegen.
4. Klappe jeden neuen Request auf. Lies die Request-URL: Dokument- und API-Adressen dürfen den gerade eingegebenen Klartext nicht enthalten und auch nicht # plus Schlüssel.
5. Öffne Payload / Request. JSON oder Formularfelder dürfen den Originaltext, eine Passphrase, das geprüfte Passwort oder die rohen Dateibytes nicht tragen. Ein Einmal-Create darf ein Geheimtext-Feld zeigen. Dieses Feld soll wie zufälliges Binär in Base64 aussehen, nicht wie der Satz, den du getippt hast.
6. Scanne Analytics- oder Collect-Requests (Namen enthalten oft matomo, collect oder g/collect). Sieh nach, ob die gemeldete Seiten-URL oder ein eigener Parameter location.href inklusive Raute geschickt hat.

Bei Dateien gibt es eine härtere Gegenprobe: Netz trennen oder Flugmodus, dann eine kleine Datei verschlüsseln. Soll die Rechnung auf diesem Gerät bleiben, muss der Download von .lock / .enc trotzdem klappen. Ein Einmal-Link besteht diesen Test nicht — er muss Geheimtext auf einem Server parken, ein Fehlschlag offline ist also erwartet, kein Eigentor. Machst du «null Requests» zur einzigen Bestehensgrenze, fällst du einen Zero-Knowledge-Einmal-Link fälschlich durch.

Eine Stärkeprüfungsseite darf eine statische Schwachpasswort-Liste laden (hier leaked-top10k.txt). Das ist eine Wortliste, nicht deine Eingabe. Im Network darfst du die Listendatei sehen. Das Passwort aus dem Eingabefeld darfst du weder in der Query noch im Body sehen. Das ist kein netzweites HIBP-Lookup. HIBP-artige Prüfungen schicken einen Hash oder ein Passwortfragment an eine fremde API.

MyPassGen ist auf diese Tabelle gebaut. Zufallspasswörter haben 6–128 Zeichen (Standard 16; unter 8 warnt die Seite, dass das Ergebnis schwach ist). Die Stärkeprüfung nutzt eine lokale Liste, kein netzweites Lookup. Säubern und Datei-Ver- bzw. Entschlüsseln laden das Original standardmäßig nicht als Fachdaten hoch. Ein Einmal-Link speichert nur Geheimtext. Jedes Tool öffnet ohne Registrierung. Die Spalte «darf nicht auftauchen» kannst du selbst im Panel abhaken. Du musst vorher keine Markenaussage akzeptieren.

Geheimtext raus ist nicht Klartext raus

Zero-Knowledge-Teilen und «vollständig offline» werden gern in einen Satz geknetet. Die Dateibox ist das Zweite: Das Ergebnis landet im Download-Ordner, der Server hat keine fachliche Kopie dieser Datei. Der Einmal-Link ist das Erste: Die Gegenseite muss ein Stück Geheimtext holen können, damit der Empfänger in seinem eigenen Browser entschlüsselt. Dass der Server Geheimtext sieht und den Schlüssel nicht, ist die Konstruktion, kein Unfall.

Die Leck-Prüfung musst du deshalb teilen. Beim Anlegen ist ein langer Base64-String im POST-Body normal. Liest dasselbe Feld als der «Test-API-Key», den du gerade getippt hast, ist Klartext rausgegangen. Der Dokumentrequest der Leseseite soll s.html?id=… sein. Nach der Spezifikation trägt die im Network gelistete Request-URL kein #. Öffne Headers dieses Requests und prüfe, dass Request-Zeile und Referer den Schlüssel beide weglassen.

Das Authentication Tag von GCM macht «ein paar Bytes kippen und trotzdem entschlüsseln» schwer: Passt das Tag nicht, schlägt decrypt sofort fehl. Das schützt Integrität und Authentizität. Es heißt nicht, der Link werde nie weitergeleitet. Wer die volle URL hat — inklusive Schlüssel hinter der Raute — kann entschlüsseln, bis der Lesecount aufgebraucht ist. Network prüft, ob der Server den Schlüssel bekommen hat. Chatlogs, Mail und Screenshots sind ein anderes Risiko. Der nächste Abschnitt behandelt sie getrennt.

Lecks, die die Spezifikation nicht deckt

Dass HTTP das Fragment nicht sendet, heißt nicht, der Schlüssel verlasse diesen Rechner nie. Seitenskript kann window.location.hash lesen und selbst per fetch wegschicken — das ist ein Implementierungsfehler, kein Protokolloch. Deshalb gibt es Schritt sechs: Meldet Analytics location.href als Seiten-URL, wandert das Stück hinter der Raute ins Statistiklog. Korrekt ist ein Pfad oder eine URL ohne Hash. «HTTP schickt es ja nicht» ersetzt das nicht.

Browserverlauf, synchronisierte Tabs und manche Absturzberichte merken sich die volle URL. Lässt du einen Einmal-Link in der Adresszeile stehen, lässt du den Schlüssel in der lokalen History. Teile ihn über einen Einwegkanal und füge die Adresse mit # nach dem Lesen nicht in eine Ticketvorlage. Referer streicht das Fragment; Query-Parameter können trotzdem zu Dritten mitreisen. Schiebe den Schlüssel niemals nach ?key=.

Bildschirm, Zwischenablage und Gruppenchat liegen außerhalb des Protokolls. Ein Kollege, der den vollen Link ins Chatfenster screenshotet, hat dem Server den Schlüssel trotzdem nicht gegeben — und alle anderen im Thread haben ihn jetzt. Lokale Verschlüsselung beantwortet «wo lief die Rechnung, und wer sieht Klartext standardmäßig nicht». Sie beantwortet nicht «leitet die Person mit der vollen URL weiter». Dieselbe Trennung gilt für die Datei-Passphrase: Die .lock darf auf ein Laufwerk; die Passphrase muss über einen anderen Kanal. Ein kurzes Geheimnis gehört auf einen Einmal-Link, nicht in denselben Mailbody wie die Passphrase.

Typische Irrtümer

«Ohne Netz geht es nicht, also wird Klartext hochgeladen.» Ein Einmal-Link muss Geheimtext parken. Ein Fehlschlag offline zeigt nur, dass er eine Geheimtext-Übertragung braucht. Lies, was diese Übertragung enthält. Bleib nicht bei «da war ein Request» stehen.

«HTTPS verschlüsselt den Weg schon, lokale Verschlüsselung ist doppelt.» HTTPS schützt Mithörer auf der Leitung. Der Server ist der TLS-Endpunkt. Request-Body und Query kann er trotzdem lesen. Lokale Verschlüsselung ist die Schicht, die verhindert, dass der Server — oder ein Analytics-Hop dazwischen — Klartext standardmäßig sieht. Sie stapelt sich mit TLS. Die Aufgaben sind verschieden.

«Die Seite erwähnt Web Crypto, also wird kein Klartext hochgeladen.» Web Crypto liefert nur Primitive. Erst encrypt, dann Geheimtext hochladen, und erst FormData per POST, dann auf dem Server verschlüsseln, können beide denselben API-Namen in die Fußzeile setzen. Der Payload im Panel schlägt den Slogan.

«Ich sehe keinen Request zur Produktdomain, also bin ich sicher.» Erweiterungen, Systemproxys und manche Unternehmensgateways zeichnen sich im Network der Seite nie selbst. Das Panel kann eine «es wird nichts hochgeladen»-Anzeige widerlegen. Es kann nicht beweisen, dass es auf der Welt keinen zweiten Kanal gibt. Für die tägliche Wahl eines Online-Tools reicht die Widerlegung: Klartext gesehen, sofort aufhören.

Wo du anfängst

Nimm eine wegwerfbare Aktion, die du heute sowieso brauchst. Dateiverschlüsselung ist der einfachste Gegensatz: Wähle einen Screenshot ohne Sensibles, tippe eine temporäre Passphrase, öffne Network, klicke Verschlüsseln, bestätige, dass kein Dateibody-POST da ist, und lade .lock oder .enc herunter. Schickst du dasselbe Bild weiter, geht der Geheimtext auf ein Laufwerk, die Passphrase in eine andere Nachricht. Eine einzelne Datei bleibt bei höchstens 5 GB.

Geht es um ein Einzeilen-Passwort oder einen Recovery-Code, nimm stattdessen einen Einmal-Link: Schreib einen Testsatz, erzeuge den Link, prüfe, dass der Create-Request nur Geheimtext trägt; öffne die Leseseite in einem privaten Fenster und sieh, dass die Dokument-Request-Zeile nur id= hat. Behandle die Leseseite nicht als indexierbare Inhaltsseite — sie ist eine einmalige Geheimtext-Szene. Links säubern folgt weiter der Tabelle aus dem vorherigen Text: UTM-Tags und Klick-IDs streichst du auf diesem Gerät.

Nach einem Durchgang kannst du die Überschrift schon beantworten: Ob Browser-Verschlüsselung echt ist, steht nicht im Slogan. Es steht darin, ob dieser Traffic Klartext, eine Passphrase oder den Schlüssel hinter der Raute enthielt. AES-256-GCM, Web Crypto und Tools, die ohne Konto aufgehen, sind Bedingungen, die du parallel prüfen kannst. Es sind keine Versprechen, für die du dich erst registrieren müsstest.

Häufige Fragen

Warum klappt Dateiverschlüsselung offline, ein Einmal-Link aber nicht?

Dateiverschlüsselung endet als lokaler Download. Ein Einmal-Link muss dem Empfänger später Geheimtext holen lassen, deshalb POSTet Create den Geheimtext. Beide können AES-256-GCM im Browser fertig rechnen. Was rausgehen darf, ist verschieden: Die Dateibox soll keinen Dateibody haben; der Einmal-Create darf Geheimtext senden und darf weder Klartext noch den Schlüssel senden.

Bekommt der Server den Schlüssel hinter # wirklich nie?

Unter üblichen URI- und HTTP-Implementierungen lassen Dokumentrequest und Referer das Fragment weg. Das siehst du am Dokumentrequest im Network. Liest ein Skript location.hash und meldet ihn, ist das Verhalten der Seite — such ihn in der Fetch-Liste.

Ist der Schlüssel im Query-String nicht einfacher?

Einfacher, und er landet in Serverlogs. ?id= darf Geheimtext finden. ?key= gibt die Entschlüsselungsfähigkeit hier und an jedes Log auf dem Weg. Soll der Empfänger entschlüsseln können und der Hoster nicht, gehört der Schlüssel hinter #.

Brauche ich ein Konto für diese Prüfung? Nimmt Analytics das Original mit?

Kein Konto. Zeichnet Analytics nur einen Seitentyp oder einen Pfad ohne Hash auf, nimmt es den Inhalt des Eingabefelds nicht mit. Meldet es die volle href, kann der Schlüssel hinter # ins Statistiklog. Die Query des Analytics-Requests im Network zu lesen ist direkter als «uns ist Datenschutz wichtig».