TLS versus end-to-end versleuteling: wat je moet weten

TLS (Transport Layer Security) versleutelt gegevens terwijl ze tussen jouw apparaat en een server reizen, en ontsleutelt ze bij aankomst — wat betekent dat de serverbeheerder je bestanden in leesbare tekst kan inzien. End-to-end versleuteling (E2EE) versleutelt inhoud op het apparaat van de verzender met een sleutel die alleen de ontvanger bezit, zodat servers de onversleutelde gegevens nooit te zien krijgen. Bij bestandsoverdrachten beschermt TLS tegen afluisteraars op het netwerk, maar niet tegen de dienstaanbieder zelf. E2EE beschermt tegen beiden. Het slotje in je browser vertelt je niet welke methode er daadwerkelijk actief is.

Wat TLS daadwerkelijk beschermt

TLS 1.3, gestandaardiseerd in RFC 8446, is het protocol dat elke HTTPS-verbinding aandrijft. Het onderhandelt een sessiesleutel via ECDHE met curven zoals X25519, verifieert de server met een X.509-certificaat en wikkelt je HTTP-verkeer in AES-128-GCM of ChaCha20-Poly1305. Dat biedt uitstekende bescherming tegen de aanvaller op een openbaar wifi-netwerk of een internetprovider die je verzoeken probeert te lezen.

Wat TLS niet doet: de versleuteling stopt bij de load balancer. Wanneer je een video van 3 GB uploadt naar een standaard bestandsdeel-dienst, ontsleutelt TLS aan de rand van het netwerk. Vervolgens gaat het onversleutelde bestand naar een S3-opslaglocatie, een verwerkingspijplijn, mogelijk een inhoudsscanner op basis van machine learning, en uiteindelijk de downloadstroom van de ontvanger — die opnieuw versleuteld wordt met een nieuwe TLS-sessie. De dienst heeft op elk punt volledige leestoegang.

Waar end-to-end versleuteling begint en eindigt

Echte E2EE verschuift de versleutelingsgrens van de server naar de eindpunten. In de browser of client van de verzender wordt een symmetrische sleutel (doorgaans AES-256-GCM) in het geheugen gegenereerd. Het bestand wordt stuk voor stuk versleuteld voordat er ook maar één byte het apparaat verlaat. De versleutelde tekst wordt via TLS naar de server geüpload, die ondoorzichtige blobs opslaat. De ontvanger krijgt de ontsleutelingssleutel via een apart kanaal — meestal als URL-fragment na het #-symbool, dat browsers nooit naar servers sturen.

De server is in dit model een domme opslaglaag. Zelfs een volledig rechtbankbevel, een kwaadwillende medewerker met databasetoegang of een cloudprovider die schijfkopieën leest, levert alleen versleutelde bytes op. Dit is de architectuur die HexaTransfer gebruikt: AES-256-GCM met een per-overdracht sleutel die aan de clientzijde wordt afgeleid en nooit naar de server wordt verzonden.

Vergelijking: alleen TLS versus end-to-end versleuteling

| Eigenschap | Alleen TLS | End-to-end versleuteld | |---|---|---| | Codering in doorvoer | AES-128/256-GCM | AES-256-GCM (plus TLS) | | Server ziet leesbare tekst | Ja | Nee | | Sleutellocatie | Beheerd door server | Apparaat van verzender | | Bescherming tegen rechtbankbevel | Geen | Sterk | | Inhoudsscanning door dienst | Mogelijk | Onmogelijk | | Herstel bij sleutelverlies | Dienst kan helpen | Gegevens zijn onherstelbaar | | Typische diensten | Google Drive, Dropbox | HexaTransfer, SwissTransfer E2EE-modus |

Hoe sleuteluitwisseling in de praktijk werkt

Het moeilijke deel van E2EE is niet het algoritme — AES is al 25 jaar solide. Het moeilijke deel is de sleutel van de verzender naar de ontvanger te krijgen zonder dat de server hem ziet. Bestandsoverdracht-diensten gebruiken doorgaans een van drie patronen.

Het eerste is de URL-fragment-truc: de link ziet eruit als https://hexatransfer.com/d/abc123#key=xyz, waarbij alles na # in de browser blijft. JavaScript leest het lokaal en ontsleutelt. Het tweede is wachtwoordgebaseerde versleuteling: de verzender kiest een wachtwoord, verwerkt het via PBKDF2 (RFC 8018) of Argon2id met 600.000+ iteraties, en deelt het wachtwoord buiten het kanaal via Signal of telefoon. Het derde is uitwisseling van openbare sleutels via bibliotheken zoals libsodium's crypto_box, waarbij de ontvanger een X25519 openbare sleutel publiceert.

Wanneer alleen TLS voldoende is

Niet elk bestand heeft E2EE nodig. Als je een persbericht deelt met een journalist, een afbeelding met je groepsgesprek of een openbare marketing-PDF, zijn diensten met alleen TLS prima. De gegevens waren om te beginnen niet gevoelig, en de dienst die ze leest vormt geen enkel risico. Je optimaliseert voor gemak — voorbeeldweergaven, miniaturen, bewerken in de browser — en die functies vereisen fundamenteel toegang tot leesbare tekst aan de serverzijde.

De afweging verandert bij medische beeldvorming (DICOM-bestanden die vallen onder HIPAA 45 CFR 164.312(a)(2)(iv)), financiële overzichten onder PCI DSS 4.0 Vereiste 3.5.1, juridische ontdekkingsmaterialen, fusie- en overnamedocumenten, of alles wat persoonsgegevens van EU-burgers bevat onder AVG Artikel 32. Hier is "de dienst kan dit technisch lezen" een nalevingsprobleem, niet alleen een privacykeuze.

De metagegevenskloof die niemand bespreekt

Zelfs met perfecte E2EE ziet de server nog steeds metagegevens: tijdstempel van upload, bestandsgrootte, IP-adressen van verzender en ontvanger, user-agent-tekenreeksen, overdrachtsduur. Als je dreigingsmodel verkeersanalyse omvat — een journalist die communiceert met een bron, bijvoorbeeld — is dit relevant. Een bestand van 147 MB dat om 3:14 uur geüpload wordt vanuit een Reuters-kantoor naar een Signal-nummer in Istanbul vertelt een verhaal, zelfs als de inhoud versleutelde tekst is.

Goede E2EE-diensten minimaliseren de bewaring van metagegevens. Let op korte bewaartermijnen voor logbestanden (7 dagen of minder), geen gebruikersaccounts vereist voor basisoverdrachten, geen externe analysediensten op overdracht-pagina's, en idealiter beleid dat compatibel is met onionroutering of VPN. Het codeeralgoritme telt minder dan de operationele hygiëne eromheen.

De bewering controleren

"End-to-end versleuteld" is marketingtekst totdat je het kunt bewijzen. Drie tests scheiden echte E2EE van mooie woorden. Ten eerste: open de ontwikkelaarstools en bekijk het netwerktabblad tijdens een upload — als de bestandsinhoud als leesbare tekst in multipart/form-data naar buiten gaat, heb je te maken met alleen TLS. Ten tweede: controleer of de ontsleutelingsURL een fragment bevat (#). Geen fragment betekent geen sleutel aan de clientzijde. Ten derde: lees het beleid van de dienst over reactie op rechtbankbevelen — als ze bestandsinhoud kunnen verstrekken aan rechtshandhaving, zijn de bestanden om te beginnen niet E2EE. Diensten die transparantierapporten publiceren en hun versleutelingscode als open source beschikbaar stellen (GitHub-repositories met gebruik van de WebCrypto API) bieden de sterkste zekerheid.

Probeer het op hexatransfer.com — gratis, zonder account, tot 10 GB.