La crittografia end-to-end è un livello aggiuntivo, non un permesso di ignorare gli avvisi TLS o fidarsi di codice manomesso.
TLS e crittografia end-to-end stabiliscono due confini diversi. Questi confini contano anche nella valutazione di VPN e proxy. TLS protegge normalmente la connessione tra il dispositivo e il servizio; una crittografia end-to-end corretta e autenticata protegge il contenuto della conversazione fino al dispositivo del destinatario. Leggere il livello TLS non significa necessariamente leggere i contenuti cifrati end-to-end, ma questo non autorizza a concludere che la sicurezza di TLS non conti più.
Se un intermediario può terminare la connessione sicura, potrebbe non solo osservare i dati trasmessi, ma anche modificare le risposte o il codice dell’applicazione web. Per questo «aggirare TLS con LVR1» non è una descrizione appropriata della sicurezza di un servizio di messaggistica.
Come può un certificato radice consentire l’ispezione?
In una connessione HTTPS, il dispositivo verifica la catena di certificati del server e il nome host. Se un intermediario presenta un certificato che l’applicazione considera valido, può creare due connessioni separate: una con l’utente e un’altra con il server reale. In questo caso l’intermediario è il punto terminale di una delle connessioni TLS, non un osservatore che ha violato la crittografia semplicemente guardando i pacchetti.
Installare un certificato arbitrario non basta da solo; l’applicazione deve fidarsi del certificato e devono essere superate anche le verifiche della connessione. La documentazione Android sulla configurazione della sicurezza di rete spiega che le politiche di fiducia possono differire tra applicazioni. Le app destinate ad Android 7.0 o versioni successive non considerano attendibili per impostazione predefinita i certificati aggiunti dall’utente, salvo configurazione diversa.
Si tratta di un meccanismo tecnico generale. Senza prove non consente di formulare conclusioni su un particolare operatore, paese o incidente. Un’interruzione o un filtraggio non dimostra di per sé che l’ispezione TLS sia riuscita.
Che cosa diventa visibile se TLS viene aperto?
| Tipo di dati o situazione | Possibile conseguenza dell’ispezione TLS |
|---|---|
| Contenuto protetto soltanto da HTTPS | Un intermediario attendibile potrebbe vedere il testo in chiaro |
| Messaggio già cifrato con la chiave valida del destinatario | L’intermediario incontra normalmente testo cifrato, non il testo del messaggio |
| Dati di instradamento, di sessione o richieste accessorie | L’entità dell’esposizione dipende dal formato e dalla progettazione del servizio |
| Codice della versione web ricevuto attraverso lo stesso percorso | Modificare il codice può minacciare la sicurezza del dispositivo finale |
| Servizio non disponibile o traffico bloccato | La crittografia da sola non stabilisce una connessione |
La protezione dei contenuti tramite E2EE dipende anche dall’autenticità della chiave del destinatario e dall’integrità del software di entrambe le parti. Se un aggressore sostituisce la chiave iniziale o manomette l’applicazione che vede il messaggio prima della cifratura, la semplice presenza di AES o ML-KEM non basta.
Perché la versione web ha bisogno di TLS sicuro?
Un’applicazione web riceve generalmente il codice eseguibile dal server. Se quel codice è dannoso, può accedere al contenuto prima della cifratura o dopo la decifratura. La crittografia end-to-end non può essere valutata indipendentemente dalle modalità di distribuzione ed esecuzione del codice.
Anche nella versione installata contano l’autenticità del pacchetto, gli aggiornamenti e l’integrità del sistema operativo. La firma del pacchetto e la verifica dell’hash sono utili, ma non costituiscono un test completo della sicurezza dell’applicazione. Anche il modello di minaccia di Livara afferma che, se un aggressore modifica sia il file sia l’hash visualizzato, la corrispondenza dell’hash da sola non dimostra autenticità.
Che cosa dichiara Livara?
Secondo la documentazione di sicurezza di Livara, i messaggi diretti usano LVR1 e i gruppi privati compatibili usano LGS1. La documentazione descrive la combinazione di P-256 e ML-KEM-768 e la cifratura del contenuto dei messaggi. Queste descrizioni sono dichiarazioni del prodotto, non il risultato di un audit indipendente condotto in questo articolo.
La stessa pagina descrive anche la conservazione dei metadati di instradamento e la natura pubblica dei canali di diffusione. La conclusione corretta non è quindi che «tutte le informazioni sono nascoste» o che «non serve alcuna fiducia nella rete». È invece necessario valutare la protezione dei contenuti privati separatamente dalla connessione, dalla consegna delle chiavi, dal codice dell’applicazione e dai metadati.
Che cosa fare davanti a un avviso sul certificato?
- Non ignorare un avviso del browser o dell’applicazione per continuare una conversazione sensibile.
- Verifica la data del dispositivo e l’indirizzo esatto del servizio; non ogni errore di certificato è necessariamente un attacco.
- Se il dispositivo è gestito da un’organizzazione, chiedi all’amministratore autorizzato informazioni sulle politiche di gestione e sui certificati installati; non modificare autonomamente le impostazioni gestite.
- Non installare un certificato o un profilo soltanto perché lo chiede un messaggio sconosciuto.
- Per le conversazioni sensibili, confronta le impronte delle chiavi con il tuo contatto attraverso un canale indipendente; la corrispondenza delle chiavi non sostituisce la risoluzione di un avviso TLS.
Domande frequenti
Una VPN risolve tutti questi problemi?
No. Una VPN può cambiare il percorso da cui viene osservato il traffico, ma non corregge automaticamente un dispositivo infetto, un certificato attendibile dannoso o codice web manomesso.
Basta autenticarsi senza inviare una password?
No. Il protocollo di autenticazione, la gestione delle sessioni e la cifratura dei messaggi svolgono funzioni diverse. Una falsa pagina di accesso o codice dannoso può acquisire direttamente l’input dell’utente prima dell’esecuzione del protocollo.
Principio pratico: E2EE è un livello prezioso; non considerarlo un permesso di ignorare certificati, autenticità dell’applicazione o verifica delle chiavi.
