Nozioni di crittografia
HTTPS e la crittografia dei messaggi non sono la stessa cosa
La differenza tra proteggere una connessione e cifrare un messaggio prima che lasci il browser.
Pubblicato: 29 marzo 2026
Limiti dell’implementazione attuale
Il client attuale cifra il testo nel browser e inserisce il contenuto cifrato nell’URL. La password condivisa separatamente non fa parte del link. Non esiste un server applicativo che memorizzi, recuperi, elimini o consumi i messaggi una sola volta.
Ulteriore contesto
Immagina due buste.
La prima attraversa un tunnel sorvegliato, viene aperta a destinazione e consegnata al personale dell’ufficio. Questo ricorda HTTPS.
L’analogia è imperfetta. I server web non sono uffici, TLS non è un tunnel e JavaScript tende a trasformare le analogie semplici in diagrammi architetturali. La distinzione resta comunque utile.
Senza HTTPS, qualcuno lungo il percorso di rete potrebbe osservare o modificare il traffico.
Collogue deve usare HTTPS indipendentemente da qualsiasi cifratura aggiuntiva dei messaggi. La crittografia del browser fornita tramite una connessione non affidabile potrebbe essere sostituita prima dell’esecuzione.
HTTPS protegge il viaggio. L’applicazione di destinazione può comunque elaborare il contenuto.
Che lo faccia o meno è una decisione dell’applicazione.
Con la cifratura nel browser, la pagina trasforma il testo in chiaro in testo cifrato prima di inviare la richiesta di creazione.
Questo non rende TLS facoltativo. La connessione trasporta comunque identificatori, testo cifrato, codice dell’applicazione e metadati operativi. Un attaccante capace di modificare la pagina potrebbe alterare il processo di cifratura.
Una revisione della sicurezza efficace considera almeno quattro stati.
Il testo in chiaro esiste nel browser del mittente.
Le minacce includono estensioni malevole, script, malware, chi osserva lo schermo e i copia-incolla accidentali.
La richiesta può contenere testo in chiaro o testo cifrato a seconda dell’applicazione.
Il testo in chiaro esiste nel browser del destinatario.
Il destinatario può leggerlo, così come può farlo un software con privilegi sufficienti su quel dispositivo.
Un’affermazione sulla sicurezza che considera solo uno di questi stati è incompleta.
- copiare il testo in chiaro prima della cifratura;
- inviare la chiave a un altro endpoint;
- indebolire la generazione casuale;
- sostituire un algoritmo;
- modificare il link di destinazione.
Non è un argomento contro la crittografia nel browser. È un argomento a favore di modelli di minaccia precisi, distribuzioni sicure, controlli di sicurezza dei contenuti, trasparenza del codice sorgente, build riproducibili quando pratico e revisioni indipendenti.
La cifratura lato client può creare un confine diverso quando l’applicazione non riceve mai la chiave del messaggio.
Anche in questo caso, verifica Collogue invece di generalizzare.
Qualcuno sulla rete può leggere o modificare questa connessione con facilità?
In quale forma il messaggio raggiunge l’applicazione?
Chi possiede ciò che serve per decifrarlo?
Per quanto tempo e con quale frequenza il servizio lo restituirà?
Questi controlli si completano a vicenda. Nessuno dovrebbe attribuirsi il merito degli altri.
No. HTTPS protegge l’applicazione distribuita, le richieste, gli identificatori e il testo cifrato dall’osservazione e dalla manomissione sulla rete.
Sì. TLS viene normalmente terminato presso il servizio; in seguito l’applicazione elabora i valori inviati.