TLS vs chiffrement de bout en bout : ce qu'il faut savoir
Comparez le chiffrement de transport TLS et le véritable chiffrement de bout en bout pour savoir lequel protège le mieux vos transferts de fichiers.
Le TLS (Transport Layer Security) chiffre les données pendant leur transit entre votre appareil et un serveur, puis les déchiffre à l'arrivée — ce qui signifie que l'opérateur du serveur peut lire vos fichiers en clair. Le chiffrement de bout en bout (E2EE) chiffre le contenu sur l'appareil de l'expéditeur avec une clé que seul le destinataire détient, de sorte que les serveurs ne voient jamais les données non chiffrées. Pour les transferts de fichiers, TLS protège contre les espions réseau mais pas contre le fournisseur lui-même. L'E2EE protège contre les deux. Le cadenas dans votre navigateur ne vous dit pas lequel est réellement en jeu.
Ce que TLS protège réellement
TLS 1.3, standardisé dans la RFC 8446, est le protocole qui alimente chaque connexion HTTPS. Il négocie une clé de session via ECDHE avec des courbes comme X25519, authentifie le serveur avec un certificat X.509, et enveloppe votre trafic HTTP dans AES-128-GCM ou ChaCha20-Poly1305. C'est une excellente protection contre l'attaquant sur le Wi-Fi du café ou un FAI cherchant à lire vos requêtes.
Ce que TLS ne fait pas : il se termine au niveau de l'équilibreur de charge. Quand vous uploadez une vidéo de 3 Go vers un service de partage de fichiers typique, TLS déchiffre à la périphérie, puis le fichier en clair rejoint un bucket S3, un pipeline de transcodage, peut-être un job de scan de contenu par ML, et enfin le flux de téléchargement du destinataire — qui est re-chiffré avec une nouvelle session TLS. Le service dispose d'un accès complet en lecture à chaque étape.
Où le chiffrement de bout en bout commence et se termine
Le vrai E2EE déplace la frontière de chiffrement du serveur vers les terminaux. Sur le navigateur ou le client de l'expéditeur, une clé symétrique (typiquement AES-256-GCM) est générée en mémoire. Le fichier est chiffré morceau par morceau avant qu'un seul octet ne quitte l'appareil. Le texte chiffré est uploadé via TLS vers le serveur, qui stocke des blobs opaques. Le destinataire reçoit la clé de déchiffrement par un canal séparé — le plus souvent sous forme de fragment d'URL après le symbole #, que les navigateurs ne transmettent jamais aux serveurs.
Dans ce modèle, le serveur est une couche de stockage muette. Même une réquisition complète, un employé malveillant accédant à la base de données, ou un fournisseur cloud lisant des snapshots de disque ne produiraient que des octets chiffrés. C'est l'architecture qu'HexaTransfer utilise : AES-256-GCM avec une clé par transfert dérivée côté client et jamais transmise à l'origine.
Comparaison : TLS seul vs chiffrement de bout en bout
| Propriété | Transfert TLS seul | Chiffrement de bout en bout | |---|---|---| | Chiffre en transit | AES-128/256-GCM | AES-256-GCM (plus TLS) | | Le serveur voit le texte en clair | Oui | Non | | Emplacement de la clé | Géré par le serveur | Appareil de l'expéditeur | | Protection contre une réquisition | Aucune | Forte | | Analyse du contenu par le fournisseur | Possible | Impossible | | Récupération si vous perdez la clé | Le fournisseur peut aider | Les données sont irrécupérables | | Services typiques | Google Drive, Dropbox | HexaTransfer, SwissTransfer mode E2EE |
Comment l'échange de clés fonctionne réellement
La partie difficile de l'E2EE n'est pas le chiffrement — AES est solide depuis 25 ans. La partie difficile est d'acheminer la clé de l'expéditeur au destinataire sans que le serveur ne la voie. Les services de transfert de fichiers utilisent typiquement l'un de trois schémas.
Le premier est l'astuce du fragment d'URL : le lien ressemble à https://hexatransfer.com/d/abc123#key=xyz, où tout ce qui suit # reste dans le navigateur. JavaScript le lit localement et déchiffre. Le deuxième est le chiffrement par mot de passe, où l'expéditeur choisit une phrase de passe, la passe dans PBKDF2 (RFC 8018) ou Argon2id avec 600 000+ itérations, et partage le mot de passe hors bande via Signal ou un appel téléphonique. Le troisième est l'échange par clé publique utilisant des bibliothèques comme crypto_box de libsodium, où le destinataire publie une clé publique X25519.
Quand TLS seul suffit
Tous les fichiers n'ont pas besoin d'E2EE. Si vous partagez un communiqué de presse avec un journaliste, un mème avec votre groupe de discussion, ou un PDF marketing public, les services TLS seul sont parfaitement adéquats. Les données n'étaient pas sensibles au départ, et le fait que le fournisseur puisse les lire ne crée aucun risque. Vous optimisez pour la commodité — aperçus, miniatures, édition dans le navigateur — et ces fonctionnalités nécessitent fondamentalement un accès côté serveur au texte en clair.
Le calcul change avec l'imagerie médicale (fichiers DICOM couverts par HIPAA 45 CFR 164.312(a)(2)(iv)), les états financiers relevant de PCI DSS 4.0 Exigence 3.5.1, les documents de procédure judiciaire, les documents de fusion-acquisition, ou tout ce qui contient des données personnelles de l'UE sous l'Article 32 du RGPD. Là, « le fournisseur peut techniquement lire cela » est un problème de conformité, pas seulement une esthétique de confidentialité.
L'angle mort des métadonnées
Même avec un E2EE parfait, le serveur voit toujours les métadonnées : horodatage d'upload, taille du fichier, adresses IP de l'expéditeur et du destinataire, chaînes user-agent, durée du transfert. Si votre modèle de menace inclut l'analyse de trafic — un journaliste communiquant avec une source, par exemple — cela compte. Un fichier de 147 Mo uploadé à 3h14 depuis un bureau de l'AFP vers un numéro Signal à Istanbul raconte une histoire même si le contenu est du texte chiffré.
Les bons services E2EE minimisent la conservation des métadonnées. Cherchez des fenêtres de conservation des journaux courtes (7 jours ou moins), aucun compte utilisateur requis pour les transferts basiques, aucune analyse tierce sur les pages de transfert, et idéalement des politiques favorables à Tor ou au VPN. La suite de chiffrement compte moins que l'hygiène opérationnelle autour d'elle.
Vérifier la promesse
« Chiffrement de bout en bout » est du texte marketing jusqu'à ce que vous puissiez le prouver. Trois tests séparent le vrai E2EE du jeu de mots. D'abord, ouvrez les DevTools et observez l'onglet réseau pendant un upload — si le corps du fichier sort en texte en clair multipart/form-data, vous regardez du TLS seul. Ensuite, vérifiez si l'URL de déchiffrement contient un fragment (#). Pas de fragment, pas de clé côté client. Enfin, lisez la politique de réponse aux réquisitions du service : s'il peut produire le contenu des fichiers aux forces de l'ordre, les fichiers ne sont pas E2EE. Les services qui publient des canaris de mandats et publient leur code crypto en open source (dépôts GitHub montrant l'usage de l'API WebCrypto) vous donnent la garantie la plus forte.
Pour les envois quotidiens de gros fichiers où la confidentialité compte, choisissez un service explicite sur son modèle. Essayez sur hexatransfer.com — gratuit, sans compte, jusqu'à 10 Go.
Envoyez vos fichiers volumineux en toute sécurité avec le chiffrement de bout en bout
Transférez des fichiers jusqu'à 10 Go gratuitement avec le chiffrement de bout en bout. Aucun compte requis. Vos fichiers sont chiffrés dans votre navigateur avant l'envoi — personne d'autre ne peut les lire.
Envoyer un fichier