Clientseitige Verschlüsselung beim Teilen von Geheimnissen

Clientseitige Verschlüsselung schützt ein gespeichertes Geheimnis vor dem Betreiber und vor allen, die an die Datenbank gelangen, und vor sonst nichts. Bösartiges JavaScript, eine Browsererweiterung oder ein geleakter Link hebeln sie aus, weil der Schlüssel im Link mitreist. Sie ist kein Allheilmittel, und ihre eine Garantie erkauft sie mit Nachteilen an anderer Stelle.

Dieser Leitfaden erklärt, was Verschlüsselung im Browser garantiert, wo sie unbemerkt versagt, wie sie sich zum serverseitigen Modell verhält und wie LinkPilot beides seit dem 29. September 2026 kombiniert. An diesem Tag stellte der Generator für Einmal-Links auf Verschlüsselung im Browser um.

Neu geschrieben am 19. Oktober 2026. Die ursprüngliche Fassung dieses Artikels beschrieb das damals aktuelle serverseitige Modell von LinkPilot; ein Hinweis vom 29. September 2026 hielt die Umstellung fest. Diese Fassung beschreibt durchgehend das aktuelle Modell. Die Überlegungen dazu, was jedes Modell schützt und was nicht, sind unverändert.

Was schützt clientseitige Verschlüsselung tatsächlich?

Das gespeicherte Geheimnis, vor dem Betreiber und vor allen, die an die Datenbank gelangen. In einem Tool mit clientseitiger Verschlüsselung (auch Ende-zu-Ende-Verschlüsselung oder E2EE genannt) läuft es so ab:

1. Der Browser erzeugt einen symmetrischen Schlüssel, typischerweise einen 256-Bit-Schlüssel für AES-GCM über die Web Crypto API (crypto.subtle.generateKey).
2. Der Browser verschlüsselt den Inhalt mit diesem Schlüssel.
3. Nur der Geheimtext geht an den Server, der ihn unter einer zufälligen Kennung speichert.
4. Der Schlüssel wird als Fragment (#…) an den Link angehängt. Nach RFC 3986, Abschnitt 3.5 senden Browser das Fragment nie in HTTP-Anfragen mit, der Schlüssel gelangt also nicht über die Leitung zum Server.
5. Der Browser des Empfängers liest das Fragment, ruft den Geheimtext ab und entschlüsselt lokal.

Der Server sieht immer nur Geheimtext. Ein Betreiber, der in die eigene Datenbank schaut, ein geleaktes Datenbank-Backup, eine behördliche Anordnung zur Herausgabe gespeicherter Daten: Keines davon liefert das Geheimnis, solange jedes andere Glied der Kette hält.

Aufbau eines E2EE-Secret-Links

https://example.com/s/x7Kd93hF2a#4fT9wLm2...Qz1
└──────── sent to the server ───┘└ browser only ┘

Alles vor dem # wird mit der Anfrage übertragen und kann in Server- und Proxy-Logs auftauchen. Das Fragment verarbeitet nur der Browser des Empfängers. Dieses eine Zeichen trägt die gesamte Sicherheit. Das ist elegant und zugleich die Wurzel der meisten Schwachstellen unten.

Wovor schützt clientseitige Verschlüsselung nicht?

Vor bösartigem oder kompromittiertem JavaScript, vor Browsererweiterungen und vor einem geleakten Link, weil der Schlüssel im Link steckt.

• Sie schützt nicht vor bösartigem JavaScript. Der Verschlüsselungscode läuft im Browser, und der Browser hat diesen Code vom Server bekommen. Liefert der Server veränderten Code aus, weil der Betreiber böswillig wurde, dazu gezwungen oder gehackt wurde, lässt sich das Geheimnis vor der Verschlüsselung oder nach der Entschlüsselung mitlesen. Das ist die grundsätzliche Grenze von E2EE im Browser.
• Sie schützt nicht vor Browsererweiterungen. Eine Erweiterung mit Zugriff auf die Seite sieht den Klartext nach der Entschlüsselung und kann das Fragment direkt auslesen.
• Sie macht einen geleakten Link nicht harmlos. Der Schlüssel ist Teil des Links. Fügt der Empfänger den vollständigen Link in einen Chat ein, leitet die E-Mail weiter oder synchronisiert seinen Browserverlauf, reist der Schlüssel mit. Ein E2EE-Link mit geleakter URL ist ein vollständig lesbares Geheimnis. Der einzige Schutz ist eine Passphrase, die über einen anderen Kanal geht. Deshalb mischt LinkPilot die Passphrase in den Schlüssel ein, statt sie getrennt zu prüfen.
• Sie kann den Inhalt weder prüfen noch scannen noch in einer Vorschau zeigen. Weil der Server den Inhalt nicht lesen kann, kann er ihn weder filtern noch auf Malware scannen noch Data Loss Prevention darauf anwenden. Kontrollen müssen stattdessen am Geheimtext und an Zugriffsereignissen ansetzen.

Das Problem der Code-Auslieferung im Detail

Der Punkt, über den es sich nachzudenken lohnt: E2EE im Browser heißt, ausgerechnet dem Server, dem man angeblich nicht vertraut, bei jedem Seitenaufruf ehrliches JavaScript zuzutrauen. Eine native App wird einmal installiert, ist signiert und versioniert; eine Webseite wird bei jedem Besuch neu geladen. Subresource Integrity und veröffentlichter Quellcode verkleinern diese Lücke, schließen sie aber nicht.

Ehrlich gelesen bedeutet „Wir können Ihre Geheimnisse nicht lesen“ also „Wir können Ihre Geheimnisse nicht passiv lesen“. Aus einer passiven Möglichkeit einen aktiven Angriff mit verändertem Code zu machen, ist eine echte Hürde (aktive Angriffe sind riskanter, gezielt und unter Umständen nachweisbar), aber es ist nicht dasselbe wie „unmöglich“. Das gilt für die Aussage von LinkPilot genauso wie für die aller anderen.

Die serverseitige Alternative

Das andere verbreitete Modell, das LinkPilot bis September 2026 nutzte, verschlüsselt ruhende Daten auf dem Server und schützt das Öffnen mit einer gehashten Passphrase:

• TLS bei der Übertragung; Inhalte liegen in einer eigenen Tabelle einer Datenbank mit Verschlüsselung auf Datenträgerebene.
• Passphrasen werden im Browser vor der Übertragung gehasht und per Hash verglichen; die Passphrase selbst erreicht die Datenbank nie.
• Echtes Löschen: Beim ersten Öffnen, beim Ablauf oder beim Widerruf wird der gespeicherte Inhalt überschrieben, und spätere Versuche erhalten HTTP 410.
• Passphrase-Versuche sind begrenzt und werden protokolliert.

In diesem Modell kann der Server ein aktives Geheimnis lesen. Genau das ermöglicht serverseitige Vorschauen, Scans und inhaltsbezogene Funktionen, und genau diese Eigenschaft entfernt E2EE. Open-Source-Tools wie OneTimeSecret nutzen es weiterhin; Ist OneTimeSecret sicher? beleuchtet die Folgen.

Was LinkPilot heute tut

Seit dem 29. September 2026 nutzt LinkPilot clientseitige Verschlüsselung und behält die serverseitigen Kontrollen, die ohne den Inhalt auskommen. Laut der Seite zur Sicherheitsarchitektur:

• Verschlüsselung im Browser. Der Inhalt wird mit AES-GCM-256 und einem 256-Bit-Schlüssel verschlüsselt, den der Browser des Absenders erzeugt. Der Server speichert den Geheimtext und sonst nichts; der Schlüssel reist im Teil des Links nach dem #.
• Passphrase als Teil des Schlüssels (Pro). Eine Passphrase wird mit PBKDF2-SHA256 (210.000 Iterationen) gestreckt und über HKDF-SHA256 mit dem Link-Schlüssel kombiniert. Weder der Link allein noch die Passphrase allein entschlüsselt das Geheimnis. Versuche sind auf 5 pro IP, Minute und Geheimnis begrenzt, über einen In-Memory-Limiter und ein gleitendes Zeitfenster in der Datenbank.
• Löschen nach dem Lesen am Geheimtext. Eine Datenbankfunktion erfasst den Aufruf in einem einzigen, unteilbaren Schritt, sodass gleichzeitige Öffnungsversuche das Geheimnis nicht zweimal preisgeben. Der gespeicherte Geheimtext wird mit [REDACTED] überschrieben, und spätere Versuche erhalten HTTP 410.
• Widerruf. Ein Geheimnis lässt sich jederzeit im Dashboard widerrufen; widerrufene Geheimnisse lassen sich nicht mehr öffnen und liefern 410.
• Vorschausicheres Öffnen. Vorschau-Bots und E-Mail-Scanner senden GET-Anfragen, die nur Metadaten liefern (Status und ob eine Passphrase nötig ist). Als Aufruf zählt nur ein ausdrückliches Öffnen im Browser.
• Audit-Verlauf (Pro). Erstellt, angezeigt, falsche Passphrase, gelöscht, abgelaufen und widerrufen, jeweils mit Zeitstempel, Land und Stadt laut Edge-Anbieter, der Browserkennung und einem täglich neu gesalzenen Hash der Adresse. Der Verlauf erfasst Zugriffe, nie Inhalte.
• Dateien. Auch Anhänge werden im Browser verschlüsselt, mit einem Schlüssel, der aus dem Link-Schlüssel abgeleitet ist. Name, Größe und Typ einer Datei bleiben für LinkPilot als Metadaten sichtbar.

Drei Grenzen, offen benannt. Geheimnisse, die vor dem 29. September 2026 erstellt wurden, lagen bis zu ihrem Ablauf im Klartext; sie wurden nie neu geschrieben. Dateimetadaten sind sichtbar, auch wenn Dateiinhalte es nicht sind. Und alles aus dem Abschnitt darüber, was sie nicht leistet, gilt weiter: Bösartiges JavaScript, Browsererweiterungen und ein geleakter Link lassen sich mit diesem Modell nicht lösen, und mit keinem anderen browserbasierten Modell.

Die Abwägungen im Überblick

Kein Modell ist für sich genommen „sicherer“. Sie wehren unterschiedliche Bedrohungen zu unterschiedlichen Kosten ab, und wer sie kombiniert, gibt weniger auf, aber nicht nichts.

Das Modell zur Bedrohung passend wählen: drei Szenarien

1. Ein Datenbankpasswort an einen externen Dienstleister schicken. Die Gefahr ist, dass das Geheimnis in E-Mail oder Chat liegen bleibt oder versehentlich weitergeleitet wird. Jedes Modell wird damit fertig, mit kurzem Ablauf und Löschen nach dem Lesen; entscheidend sind Bedienbarkeit und Nachweis. Verschlüsselung im Browser mit einer Passphrase über einen anderen Kanal und ein Verlauf, der zeigt, wann der Link geöffnet wurde, ist die pragmatische Wahl.

2. Eine Journalistin erhält Material von einer Quelle. Zum Bedrohungsmodell gehört, dass der Plattformbetreiber zur Herausgabe gezwungen wird. Hier ist der Betreiber Teil der Bedrohung. E2EE ist also das Minimum, und spezialisierte Werkzeuge wie SecureDrop, bei denen das ganze System auf genau diese Bedrohung ausgelegt ist, sind die richtige Wahl. Ein Web-Tool, das gezwungen werden könnte, verändertes JavaScript auszuliefern, reicht allein nicht.

3. Ein Entwicklungsteam übergibt routinemäßig Zugangsdaten. Die Gefahr ist Wildwuchs: vergessene Links, kein Nachweis, wer was gesehen hat. Wichtig sind hier der Audit-Verlauf, Widerruf, Workspace-Rollen und eine Ablaufrichtlinie. Früher brauchte man dafür einen Server, der den Inhalt lesen konnte. Heute nicht mehr, weil diese Funktionen am Geheimtext und an Zugriffsereignissen ansetzen. Passwörter sicher im Team teilen behandelt die Richtlinienseite dieses Szenarios.

So wählen Sie

Wählen Sie clientseitige Verschlüsselung, wenn:

• Sie dem Betreiber nicht vertrauen, auch nicht sich selbst, wenn Sie auf Cloud-Infrastruktur arbeiten, die Sie nicht vollständig prüfen können.
• gesetzliche oder vertragliche Vorgaben verlangen, dass der Anbieter den Inhalt technisch nicht lesen kann.
• Sie die Passphrase über einen zweiten Kanal schicken und den Ablauf kurz halten, denn sonst ist ein geleakter Link das ganze Geheimnis.

Wählen Sie serverseitige Verschlüsselung, wenn:

• der Server den Inhalt prüfen muss: Malware-Scans, Data Loss Prevention, Inhaltsfilter.
• Sie ein Tool für genau einen Zweck selbst hosten und der Betreiber Sie selbst sind.

Suchen Sie nach beidem, wenn:

• Sie den Betreiber aus der Vertrauenskette nehmen wollen und trotzdem einen Audit-Verlauf, Widerruf, Team-Rollen und ein Öffnen brauchen, das keine Linkvorschau auslösen kann. Fragen Sie den Anbieter, welche Kontrollen am Geheimtext ansetzen und welche stillschweigend Klartext brauchen.

Ist ein Online-Verschlüsselungstool die richtige Wahl?

Wer nach einem Online-Verschlüsselungstool sucht, will meist eines von zwei Dingen: ein Stück Text in Geheimtext verwandeln, den man überall einfügen kann, oder eine vertrauliche Nachricht sicher zu einer Person bringen. Das Erste ist ein Werkzeug. Das Zweite ist ein Ablauf, und das Werkzeug allein bringt ihn nicht zu Ende.

Eine Seite, in die man Text zum Verschlüsseln einfügt, verschlüsselt im Browser, wenn sie gut gebaut ist. Das können Sie mit den Schritten im Abschnitt zur Überprüfung unten kontrollieren. Alles rund um den Geheimtext bleibt bei Ihnen: eine starke Passphrase wählen, sie über einen separaten Kanal schicken, den Geheimtext überall löschen, wo Sie ihn eingefügt haben, und herausfinden, ob der Empfänger ihn entschlüsseln konnte. Kodierung ist keine Verschlüsselung, ein Base64-Tool schützt also gar nichts. Und eine schwache Passphrase ist in der Praxis der übliche Grund, warum Verschlüsselung im Browser scheitert.

Ein Einmal-Link verschlüsselt genauso im Browser und übernimmt den Rest des Ablaufs: Der Schlüssel reist im Teil des Links nach dem #, die gespeicherte Kopie wird beim ersten Öffnen vernichtet, der Link läuft ab, wenn ihn niemand öffnet, und der Absender sieht, dass er geöffnet wurde. Für eine Nachricht an eine Person passt das besser. Für Geheimtext, den Sie selbst aufbewahren oder in ein System einfügen müssen, das Sie kontrollieren, ist ein lokales Tool wie age oder GPG jeder Webseite überlegen, weil der Schlüssel nie einen Browser berührt.

Wann Sie keines von beiden nutzen sollten

Manche Geheimnisse gehören in keinen Link. Langlebige Root-Zugangsdaten, produktive Signaturschlüssel und umfangreiche Datenexporte gehören in einen Secrets Manager oder ein KMS mit Zugriffskontrolle, nicht in eine URL. Und wenn der Empfänger den Wert immer wieder braucht, ist ein Eintrag im Tresor eines Passwortmanagers besser, als Links erneut zu verschicken. Einmalige Zustellung ist für Übergaben da, nicht zum Aufbewahren. Secret-Links oder Passwortmanager zieht diese Grenze.

Eine Aussage überprüfen

Wählen Sie ein Tool nicht danach, welches mehr verspricht. Wählen Sie danach, wogegen Sie sich schützen wollen, und prüfen Sie, ob das Versprechen auf der Verpackung zur Architektur darunter passt:

• Steht der Schlüssel im Fragment? Sehen Sie sich den Aufbau des Links an; der Schlüssel sollte hinter dem # stehen.
• Liefert ein einfacher Abruf des Links das Geheimnis? Das sollte er nicht.
• Was bewirkt die Passphrase: Gibt sie nur das Öffnen frei, oder ist sie Teil des Schlüssels?
• Was wird protokolliert, und sagt der Betreiber das schriftlich?

Die Antworten von LinkPilot stehen auf der Seite zur Sicherheitsarchitektur, einschließlich der Grenzen. Für diese Seite gilt derselbe Test wie für die aller anderen.

Weiterlesen

• So funktionieren Einmal-Links
• Ist OneTimeSecret sicher?
• LinkPilot oder PrivateBin
• Secret-Links oder Passwortmanager
• Warum URLs vertrauliche Informationen preisgeben
• Link-Scanner und Einmal-Geheimnisse

Quellen

• W3C, Web Cryptography API.
• NIST, SP 800-38D: Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC.
• IETF, RFC 3986, section 3.5 Fragment.
• Freedom of the Press Foundation, SecureDrop.