TLS vs crittografia end-to-end: cosa devi sapere

TLS (Transport Layer Security) cifra i dati mentre viaggiano tra il tuo dispositivo e un server, poi li decrittografa all'arrivo — il che significa che l'operatore del server può leggere i tuoi file in chiaro. La crittografia end-to-end (E2EE) cifra i contenuti sul dispositivo del mittente con una chiave che solo il destinatario detiene, così i server non vedono mai i dati non cifrati. Per i trasferimenti file, TLS protegge contro gli intercettatori di rete ma non contro il provider stesso. L'E2EE protegge contro entrambi. Il lucchetto nella barra degli indirizzi del browser non ti dice quale dei due è effettivamente in gioco.

Cosa protegge effettivamente TLS

TLS 1.3, standardizzato in RFC 8446, è il protocollo che alimenta ogni connessione HTTPS. Negozia una chiave di sessione usando ECDHE con curve come X25519, autentica il server con un certificato X.509, e avvolge il tuo traffico HTTP in AES-128-GCM o ChaCha20-Poly1305. Questa è un'eccellente protezione contro l'attaccante sulla Wi-Fi del bar o un ISP che tenta di leggere le tue richieste.

Cosa non fa TLS: termina al load balancer. Quando carichi un video da 3 GB su un tipico servizio di condivisione file, TLS decrittografa al bordo, poi il file in chiaro arriva in un bucket S3, una pipeline di transcoding, magari un processo di scansione del contenuto ML, e infine nello stream di download del destinatario — che viene ri-cifrato con una nuova sessione TLS. Il servizio ha pieno accesso in lettura ad ogni passaggio.

Dove inizia e finisce la crittografia end-to-end

La vera E2EE sposta il confine di crittografia dal server agli endpoint. Nel browser del mittente o nel client, una chiave simmetrica (tipicamente AES-256-GCM) viene generata in-memory. Il file viene cifrato chunk per chunk prima che un singolo byte lasci il dispositivo. Il ciphertext viene caricato tramite TLS sul server, che archivia blob opachi. Il destinatario riceve la chiave di decrittografia attraverso un canale separato — molto spesso come frammento URL dopo il simbolo #, che i browser non trasmettono mai ai server.

Il server, in questo modello, è uno strato di storage muto. Anche un'ingiunzione completa, un dipendente disonesto con accesso al database, o un cloud provider che legge gli snapshot del disco produrrebbero solo byte cifrati. Questa è l'architettura che usa HexaTransfer: AES-256-GCM con una chiave per-trasferimento derivata lato client e mai trasmessa all'origine.

Confronto: solo TLS vs crittografia end-to-end

| Proprietà | Trasferimento solo TLS | Cifrato end-to-end | |---|---|---| | Cifrario in transito | AES-128/256-GCM | AES-256-GCM (più TLS) | | Il server vede il testo in chiaro | Sì | No | | Posizione della chiave | Gestita dal server | Dispositivo del mittente | | Protezione contro ingiunzioni | Nessuna | Forte | | Scansione del contenuto dal provider | Possibile | Impossibile | | Recupero se perdi la chiave | Il provider può aiutare | I dati sono irrecuperabili | | Servizi tipici | Google Drive, Dropbox | HexaTransfer, SwissTransfer modalità E2EE |

Come avviene effettivamente lo scambio di chiavi

La parte difficile dell'E2EE non è il cifrario — AES è solido da 25 anni. La parte difficile è portare la chiave dal mittente al destinatario senza che il server la veda. I servizi di trasferimento file usano tipicamente uno di tre pattern.

Il primo è il trucco del frammento URL: il link ha questo aspetto https://hexatransfer.com/d/abc123#key=xyz, dove tutto dopo # rimane nel browser. JavaScript lo legge localmente e decrittografa. Il secondo è la crittografia basata su password, dove il mittente sceglie una passphrase, la esegue attraverso PBKDF2 (RFC 8018) o Argon2id con 600.000+ iterazioni, e condivide la password fuori banda tramite Signal o una telefonata. Il terzo è lo scambio a chiave pubblica usando librerie come crypto_box di libsodium, dove il destinatario pubblica una chiave pubblica X25519.

Quando TLS da solo va bene

Non ogni file ha bisogno dell'E2EE. Se stai condividendo un comunicato stampa con un giornalista, un meme con la tua chat di gruppo, o un PDF di marketing pubblico, i servizi solo TLS sono perfettamente adeguati. I dati non erano sensibili per cominciare, e il provider che li legge non crea alcun rischio. Stai ottimizzando per la comodità — anteprime, miniature, modifica nel browser — e quelle funzionalità richiedono fondamentalmente l'accesso al testo in chiaro lato server.

Il calcolo cambia con l'imaging medico (file DICOM coperti da HIPAA 45 CFR 164.312(a)(2)(iv)), i rendiconti finanziari ai sensi di PCI DSS 4.0 Requisito 3.5.1, i materiali di discovery legale, i documenti di M&A, o qualsiasi cosa contenente dati personali UE ai sensi del GDPR Articolo 32. Qui, "il provider può tecnicamente leggere questo" è un problema di conformità, non solo un'estetica di privacy.

Il divario dei metadati di cui nessuno parla

Anche con E2EE perfetta, il server vede ancora i metadati: timestamp di upload, dimensione del file, indirizzi IP di mittente e destinatario, stringhe user-agent, durata del trasferimento. Se il tuo modello di minaccia include l'analisi del traffico — un giornalista che comunica con una fonte, ad esempio — questo conta. Un file da 147 MB caricato alle 3:14 di notte da un ufficio Reuters a un numero Signal a Istanbul racconta una storia anche se i contenuti sono ciphertext.

I buoni servizi E2EE minimizzano la conservazione dei metadati. Cerca finestre brevi di conservazione dei log (7 giorni o meno), nessun account utente richiesto per i trasferimenti di base, nessun analytics di terze parti sulle pagine di trasferimento, e idealmente politiche amiche di onion routing o VPN. La suite di cifratura conta meno dell'igiene operativa che la circonda.

Verificare la dichiarazione

"Crittografato end-to-end" è testo di marketing finché non puoi dimostrarlo. Tre test separano la vera E2EE dai giochi di parole. Primo, apri DevTools e guarda la scheda rete durante un upload — se il corpo del file esce come testo in chiaro multipart/form-data, stai guardando solo TLS. Secondo, controlla se l'URL di decrittografia contiene un frammento (#). Nessun frammento, nessuna chiave lato client. Terzo, leggi la policy di risposta alle ingiunzioni del servizio: se possono produrre i contenuti dei file alle forze dell'ordine, i file non sono E2EE in partenza. I servizi che pubblicano warrant canary e rendono open source il loro codice di crittografia (repository GitHub che mostrano l'uso della WebCrypto API) ti danno la garanzia più forte.

Per gli invii quotidiani di file grandi dove la riservatezza conta, scegli un servizio che sia esplicito riguardo al suo modello. Provalo su hexatransfer.com — gratis, senza registrazione, fino a 10 GB.