Crittografia lato server vs. lato client: a quale modello dovresti fidarti?

La crittografia lato server cifra i dati sul server dopo aver ricevuto il testo in chiaro, richiedendo fiducia nel fornitore del servizio. La crittografia lato client cifra i dati nel tuo browser prima dell'invio, così il server non vede mai il testo in chiaro. Per la condivisione di segreti, la crittografia lato client è più sicura perché elimina il servizio come punto di fiducia — anche un server compromesso non può leggere i tuoi dati.

Questo articolo confronta entrambi gli approcci: come funzionano, cosa ciascuno ti chiede di fidarti e dove si trovano i veri compromessi. Non è un argomento a favore di un lato — è un framework per valutare quale modello si adatta al tuo threat model.

Per una panoramica rapida su perché la crittografia lato client è importante, leggi il nostro articolo precedente. Per un'analisi dettagliata dell'implementazione specifica di Vaulted, leggi il nostro approfondimento zero-knowledge.

Come funziona la crittografia lato server

Nel modello lato server, il servizio gestisce la crittografia per tuo conto. Il flusso tipico:

Inserisci un segreto nel browser
Il tuo browser invia il testo in chiaro al server tramite TLS
Il server cifra i dati usando una chiave che gestisce lui stesso
Il testo cifrato viene memorizzato nel database
Quando il destinatario richiede il segreto, il server lo decifra e restituisce il testo in chiaro

La chiave di crittografia non lascia mai il server. Potrebbe trovarsi in un hardware security module (HSM), un cloud key management service (KMS) o un file di configurazione — ma il server la controlla completamente.

Il modello di fiducia lato server

Con la crittografia lato server, ti fidi:

Dell'operatore del servizio che non legga i tuoi dati (ha la chiave e il testo in chiaro in memoria durante la cifratura/decifratura)
Dell'infrastruttura che non venga compromessa (un server compromesso espone sia le chiavi che i dati)
Dei dipendenti dell'operatore che non abusino dell'accesso (chiunque abbia accesso al server può potenzialmente leggere i segreti)
Della giurisdizione legale che non imponga la divulgazione (l'operatore può essere costretto a consegnare i dati perché detiene le chiavi)
Dei log del server e del monitoraggio che non catturino il testo in chiaro (i framework di logging possono registrare inavvertitamente dati sensibili)

Questo non è necessariamente un modello sbagliato. Molti servizi lo usano con successo — cloud storage, provider di email e servizi database si affidano tutti alla crittografia lato server. La domanda è se il compromesso si adatta al tuo caso d'uso.

Come funziona la crittografia lato client

Nel modello lato client, la crittografia avviene nel browser prima che qualsiasi dato raggiunga il server. Il flusso è diverso:

Inserisci un segreto nel browser
Il browser genera una chiave di crittografia e cifra i dati localmente
Solo il testo cifrato viene inviato al server
La chiave di crittografia viene consegnata al destinatario attraverso un canale separato (tipicamente il frammento dell'URL)
Il browser del destinatario decifra il testo cifrato localmente

Il server non vede mai il testo in chiaro e non detiene mai la chiave di crittografia. Memorizza e recupera blob cifrati — niente di più.

Vaulted usa questo modello. Ogni segreto ottiene una nuova chiave AES-256-GCM. La chiave viene inserita nel frammento dell'URL (#), che i browser non includono mai nelle richieste HTTP secondo RFC 3986. Il server riceve il testo cifrato e un IV casuale di 12 byte per la memorizzazione, ma la chiave rimane interamente nel link condiviso tra mittente e destinatario.

Il modello di fiducia lato client

Con la crittografia lato client, ti fidi:

Del browser che implementi correttamente la crittografia (la Web Crypto API delega ai motori crittografici nativi come BoringSSL o NSS)
Del codice dell'applicazione che esegua effettivamente la crittografia lato client (puoi verificarlo ispezionando le richieste di rete)
Del canale di consegna del link che sia sicuro (chiunque abbia l'URL completo, incluso il frammento, può decifrare il segreto)
Del dispositivo del destinatario che non sia compromesso (dopo la decifratura, malware o cattura dello schermo possono accedere al testo in chiaro)

Non ti fidi del server, dell'operatore del servizio, dei suoi dipendenti o della sua giurisdizione legale. Il server è un relay di archiviazione per dati cifrati che non può leggere.

Confronto dei compromessi

Nessun modello è universalmente migliore. Ciascuno fa compromessi diversi tra sicurezza, usabilità e ricchezza di funzionalità.

Proprietà di sicurezza

Proprietà	Lato server	Lato client
Esposizione in caso di violazione	Chiavi + testo cifrato esposti	Solo testo cifrato esposto (inutile senza chiavi)
L'operatore può leggere i dati	Sì (detiene le chiavi)	No (non ha mai le chiavi)
Rischio di coercizione legale	L'operatore può conformarsi (ha accesso)	L'operatore non può conformarsi (non ha accesso)
Rischio di intercettazione link	Non applicabile (nessuna chiave nel link)	URL completo = accesso completo (mitigato dalla passphrase)
Man-in-the-middle	TLS protegge il transito; il server vede il testo in chiaro	TLS protegge il testo cifrato; la chiave nel frammento non viene mai inviata

Proprietà di usabilità

Proprietà	Lato server	Lato client
Onere di gestione delle chiavi	Nessuno per l'utente (il server se ne occupa)	L'utente deve condividere il link in modo sicuro
Recupero della password	Possibile (il server detiene le chiavi)	Non possibile (le chiavi sono solo nel link)
Ricerca e indicizzazione	Il server può cercare nel testo in chiaro	Non possibile senza decifratura
Flessibilità di condivisione	Il server può ricifrare per nuovi destinatari	Richiede un nuovo link per ogni destinatario
Accesso offline	Richiede connessione al server per decifrare	Possibile se il testo cifrato e la chiave sono memorizzati localmente

Compromessi sulle funzionalità

Funzionalità	Lato server	Lato client
Audit logging del contenuto	Possibile	Non possibile (il server non può leggere il contenuto)
Policy basate sul contenuto	Possibile (DLP, compliance scanning)	Non possibile senza decifratura
Rotazione delle chiavi	Il server può ricifrare con nuove chiavi	Richiede la rigenerazione e la ricondivisione dei link
Controllo degli accessi multi-parte	Il server può gestire le chiavi per utente	Ogni destinatario necessita della chiave direttamente
Garanzia zero-knowledge	No	Sì

Quando la crittografia lato server è accettabile

La crittografia lato server è una scelta ragionevole quando:

Ti fidi dell'operatore del servizio e delle sue pratiche di sicurezza
Hai bisogno di funzionalità che richiedono accesso lato server ai dati (ricerca, condivisione, compliance scanning)
La sensibilità dei dati non giustifica il costo in usabilità della crittografia lato client
Operi in un ambiente regolamentato dove le certificazioni di conformità dell'operatore contano più delle garanzie zero-knowledge
La complessità della gestione delle chiavi deve essere gestita dal servizio, non dall'utente

I servizi di cloud storage, la posta elettronica aziendale e la crittografia di database gestiti usano tutti questo modello efficacemente.

Quando la crittografia lato client è necessaria

La crittografia lato client diventa necessaria quando:

Non puoi o non dovresti fidarti dell'operatore del servizio con i tuoi dati
I dati sono sufficientemente sensibili da non dover esporre il testo in chiaro in caso di violazione del server
Hai bisogno di una garanzia zero-knowledge — prova matematica che il server non può leggere i tuoi dati
Requisiti legali o di conformità richiedono che l'operatore del servizio non abbia accesso al contenuto
Vuoi protezione contro le minacce interne al fornitore del servizio

La condivisione di segreti è uno dei casi d'uso più forti per la crittografia lato client. I dati sono intrinsecamente sensibili (password, chiavi API, credenziali), la condivisione è transitoria (con limite di visualizzazioni, con limite di tempo), e la relazione di fiducia è minima (potresti non conoscere o non fidarti dell'operatore del servizio).

Come Vaulted affronta questo

Vaulted usa esclusivamente la crittografia lato client. Ogni segreto viene cifrato nel browser con una nuova chiave AES-GCM prima che qualsiasi dato raggiunga il server. La chiave viaggia solo nel frammento dell'URL, e la protezione opzionale con passphrase aggiunge un secondo livello tramite derivazione della chiave PBKDF2 e key wrapping AES-KW.

Il server memorizza il testo cifrato con un time-to-live e un contatore di visualizzazioni. Non può decifrare, cercare o ispezionare il contenuto. Una violazione completa del database produce solo blob cifrati — computazionalmente inutili senza le chiavi che esistono solo nei link condivisi.

Per i dettagli crittografici completi — generazione delle chiavi, gestione dell'IV, wrapping della passphrase e le esatte chiamate alla Web Crypto API — leggi il nostro approfondimento sulla crittografia zero-knowledge.

Fare la tua scelta

Il modello di crittografia giusto dipende da cosa stai proteggendo e a chi sei disposto a fidarti.

Se hai bisogno di funzionalità come ricerca, recupero o gestione centralizzata delle chiavi, la crittografia lato server è la scelta pratica. Se hai bisogno della garanzia che nessuno — né il servizio, né i suoi dipendenti, né un ordine del tribunale — possa leggere i tuoi dati, la crittografia lato client è l'unico modello che la fornisce.

Per la condivisione di segreti, la risposta è semplice: i dati sono sensibili, l'interazione è breve, e meno parti possono accedere al testo in chiaro, meglio è.

Pronto a condividere un segreto con crittografia zero-knowledge? Crea un segreto su Vaulted — i tuoi dati non lasciano mai il tuo browser non cifrati.

Correlati

Perché la crittografia lato client è importante — il caso a favore della cifratura nel browser
Crittografia zero-knowledge: come Vaulted mantiene privati i tuoi segreti — approfondimento sull'implementazione crittografica
Sicurezza su Vaulted — sintesi del nostro modello di sicurezza