TLS vs. Ende-zu-Ende-Verschlüsselung: Das sollten Sie wissen
Vergleichen Sie TLS-Transportverschlüsselung mit echter Ende-zu-Ende-Verschlüsselung und finden Sie heraus, welche Methode Ihre Dateien besser schützt.
TLS (Transport Layer Security) verschlüsselt Daten auf dem Weg zwischen Ihrem Gerät und einem Server – entschlüsselt sie aber bei der Ankunft, sodass der Serverbetreiber Ihre Dateien im Klartext lesen kann. Ende-zu-Ende-Verschlüsselung (E2EE) verschlüsselt Inhalte auf dem Gerät des Absenders mit einem Schlüssel, den ausschließlich der Empfänger besitzt, sodass Server die unverschlüsselten Daten niemals zu Gesicht bekommen. Für Dateiübertragungen schützt TLS vor Lauschangriffen im Netzwerk, nicht aber vor dem Anbieter selbst. E2EE schützt gegen beides. Das Schloss-Symbol im Browser sagt Ihnen nicht, welches Verfahren tatsächlich aktiv ist.
Was TLS tatsächlich schützt
TLS 1.3, standardisiert in RFC 8446, ist das Protokoll hinter jeder HTTPS-Verbindung. Es handelt einen Sitzungsschlüssel per ECDHE mit Kurven wie X25519 aus, authentifiziert den Server mit einem X.509-Zertifikat und kapselt Ihren HTTP-Datenverkehr in AES-128-GCM oder ChaCha20-Poly1305. Das bietet hervorragenden Schutz gegen Angreifer im öffentlichen WLAN oder einen Internetanbieter, der Anfragen mitliest.
Was TLS nicht leistet: Es endet am Load-Balancer. Wenn Sie ein 3-GB-Video bei einem typischen Dateifreigabedienst hochladen, entschlüsselt TLS am Edge-Server – danach trifft die Datei im Klartext auf einen S3-Bucket, eine Transcoding-Pipeline, möglicherweise einen ML-basierten Inhalts-Scanner und schließlich den Download-Stream des Empfängers, der mit einer neuen TLS-Sitzung neu verschlüsselt wird. Der Dienst hat bei jedem Schritt vollständigen Lesezugriff auf Ihre Datei.
Wo Ende-zu-Ende-Verschlüsselung beginnt und endet
Echte E2EE verschiebt die Verschlüsselungsgrenze vom Server zu den Endpunkten. Im Browser oder Client des Absenders wird ein symmetrischer Schlüssel (typischerweise AES-256-GCM) im Arbeitsspeicher erzeugt. Die Datei wird Abschnitt für Abschnitt verschlüsselt, bevor ein einziges Byte das Gerät verlässt. Der Chiffretext wird über TLS zum Server hochgeladen, der nur opake Datenblobse speichert. Der Empfänger erhält den Entschlüsselungsschlüssel über einen separaten Kanal – am häufigsten als URL-Fragment nach dem #-Symbol, das Browser niemals an Server übermitteln.
Der Server ist in diesem Modell eine reine Speicherschicht ohne Bedeutung für die Sicherheit. Selbst eine vollständige Datenbeschlagnahme durch Behörden, ein betrügerischer Mitarbeiter mit Datenbankzugriff oder ein Cloud-Anbieter, der Disk-Snapshots liest, würde nur verschlüsselte Bytes liefern. Dies ist die Architektur, die HexaTransfer verwendet: AES-256-GCM mit einem pro Übertragung clientseitig abgeleiteten Schlüssel, der niemals zum Server übertragen wird.
Vergleich: Nur-TLS vs. Ende-zu-Ende-Verschlüsselung
| Eigenschaft | Nur-TLS-Übertragung | Ende-zu-Ende-verschlüsselt | |---|---|---| | Chiffre während der Übertragung | AES-128/256-GCM | AES-256-GCM (plus TLS) | | Server sieht Klartext | Ja | Nein | | Schlüsselstandort | Serverseitig verwaltet | Gerät des Absenders | | Schutz vor Beschlagnahme | Keiner | Stark | | Inhalts-Scan durch Anbieter | Möglich | Unmöglich | | Wiederherstellung bei Schlüsselverlust | Anbieter kann helfen | Daten unwiederbringlich | | Typische Dienste | Google Drive, Dropbox | HexaTransfer, SwissTransfer E2EE-Modus |
Wie der Schlüsselaustausch tatsächlich funktioniert
Das Schwierige bei E2EE ist nicht die Chiffre – AES ist seit 25 Jahren bewährt. Die Herausforderung besteht darin, den Schlüssel vom Absender zum Empfänger zu übertragen, ohne dass der Server ihn sieht. Dateiübertragungsdienste verwenden typischerweise eines von drei Mustern.
Das erste ist der URL-Fragment-Trick: Der Link sieht aus wie https://hexatransfer.com/d/abc123#key=xyz, wobei alles nach # im Browser verbleibt. JavaScript liest ihn lokal und entschlüsselt die Datei. Das zweite ist kennwortbasierte Verschlüsselung, bei der der Absender eine Passphrase wählt, sie durch PBKDF2 (RFC 8018) oder Argon2id mit 600.000+ Iterationen leitet und das Passwort außerhalb des Übertragungskanals – per Signal oder Telefonanruf – mitteilt. Das dritte ist ein Public-Key-Austausch mit Bibliotheken wie libsodiums crypto_box, bei dem der Empfänger einen öffentlichen X25519-Schlüssel veröffentlicht.
Wann TLS allein ausreicht
Nicht jede Datei benötigt E2EE. Wenn Sie eine Pressemitteilung mit einem Journalisten teilen, ein Meme in einem Gruppen-Chat versenden oder eine öffentliche Marketing-PDF weiterleiten, sind Nur-TLS-Dienste vollkommen ausreichend. Die Daten waren von Anfang an nicht sensibel, und dass der Anbieter sie liest, schafft kein Risiko.
Die Rechnung ändert sich bei medizinischen Bilddaten (DICOM-Dateien, die gemäß DSGVO und BDSG besonders geschützt sind), Jahresabschlüssen unter PCI DSS 4.0 Anforderung 3.5.1, anwaltlichen Dokumenten, Fusionsunterlagen oder allem, was personenbezogene EU-Daten gemäß DSGVO Artikel 32 enthält. Hier ist „der Anbieter kann dies technisch lesen" ein Compliance-Problem, kein bloß ästhetisches Datenschutzanliegen. Der BfDI betont in seinen Stellungnahmen, dass geeignete technische Maßnahmen im Sinne von Artikel 32 DSGVO regelmäßig über reine Transportverschlüsselung hinausgehen müssen.
Die Metadatenlücke, über die niemand spricht
Selbst bei perfekter E2EE sieht der Server noch Metadaten: Upload-Zeitstempel, Dateigröße, IP-Adressen von Absender und Empfänger, User-Agent-Strings, Übertragungsdauer. Wenn Ihr Bedrohungsmodell Traffic-Analyse einschließt – etwa ein Journalist in Kontakt mit einer Quelle –, ist das bedeutsam. Eine 147-MB-Datei, die um 3:14 Uhr hochgeladen wird, erzählt eine Geschichte, selbst wenn ihr Inhalt Chiffretext ist.
Gute E2EE-Dienste minimieren die Metadatenspeicherung. Achten Sie auf kurze Protokollaufbewahrungsfristen (7 Tage oder weniger), keine Kontoerfordernis für Grundübertragungen, keine Drittanbieter-Analysen auf Übertragungsseiten und idealerweise VPN-freundliche Richtlinien. Die Cipher-Suite ist weniger entscheidend als die Betriebshygiene rund um den Dienst.
Den Anspruch verifizieren
„Ende-zu-Ende-verschlüsselt" ist Marketing-Text, bis Sie ihn belegen können. Drei Tests trennen echte E2EE von Wortspielerei. Öffnen Sie erstens die Browser-DevTools und beobachten Sie den Netzwerk-Tab während eines Uploads – wenn der Dateiinhalt als Klartext-Multipart/Form-Data ausgeht, handelt es sich um Nur-TLS. Prüfen Sie zweitens, ob die Entschlüsselungs-URL ein Fragment (#) enthält. Kein Fragment bedeutet keinen clientseitigen Schlüssel. Lesen Sie drittens die Subpoena-Response-Richtlinie des Dienstes: Wenn er Dateiinhalte an Strafverfolgungsbehörden liefern kann, waren die Dateien nie wirklich E2EE. Dienste, die Warrant-Canaries veröffentlichen und ihren Krypto-Code als Open Source bereitstellen (GitHub-Repositories mit WebCrypto-API-Nutzung), bieten die stärkste Sicherheit.
Für alltägliche Großdateiversendungen, bei denen Vertraulichkeit zählt, wählen Sie einen Dienst, der sein Modell transparent kommuniziert. Testen Sie es auf hexatransfer.com – kostenlos, kein Konto erforderlich, maximal 10 GB.
Große Dateien sicher mit Ende-zu-Ende-Verschlüsselung senden
Übertragen Sie Dateien bis zu 10 GB kostenlos mit Ende-zu-Ende-Verschlüsselung. Kein Konto erforderlich. Ihre Dateien werden in Ihrem Browser verschlüsselt, bevor sie hochgeladen werden — niemand sonst kann sie lesen.
Datei senden