Cos’è HTTPS e perché il lucchetto del browser non basta

Il lucchetto dice che la connessione è cifrata verso quel dominio, non che il sito è onesto. Ecco cos’è HTTPS e cosa controllare oltre l’icona.

Apri la pagina della banca, della webmail o del password manager. Accanto all’indirizzo compare un’icona di “connessione sicura”: un lucchetto, uno scudo o, su Chrome/Edge recenti, l’icona delle impostazioni del sito. Per anni campagne e abitudini hanno lasciato un’equazione rassicurante: icona = sito sicuro.

Quell’equazione oggi è incompleta e, se la prendi alla lettera, pericolosa. HTTPS (oggi basato su TLS) garantisce che il canale tra il tuo dispositivo e quel server sia cifrato e integro: un estraneo sulla Wi‑Fi del bar non legge password e cookie in chiaro. Ma non valuta l’onestà di chi controlla il dominio. Un truffatore può registrare un lookalike, ottenere un certificato valido in pochi minuti e mostrarti lo stesso tipo di icona.

Qui spiego, in pratica, cosa protegge davvero HTTPS, cosa verifica il browser prima di “fidarsi” del certificato, come ispezionare i dettagli da desktop (Windows prima, poi macOS/Linux) e quali controlli quotidiani affiancare all’icona — perché il phishing moderno è quasi sempre su HTTPS.

ℹ️ Nota / Prerequisito operativo
Ti serve un browser aggiornato (Chrome, Edge, Firefox o Safari). Per i test di lettura certificato usa siti che conosci già (es. Wikipedia o ai riparo). Non inserire password su pagine aperte da link sospetti “solo per provare”.

HTTP vs HTTPS in pratica

La differenza centrale è riservatezza e integrità del canale, non la “bontà morale” del sito.

Con HTTP (senza la S) ciò che digiti e ricevi viaggia in chiaro sul percorso rete. Su una Wi‑Fi pubblica, chi controlla l’accesso (o chi sniffera il traffico radio con strumenti accessibili) può vedere URL completi con parametri, cookie di sessione, campi password e il contenuto delle pagine.

Con HTTPS (HTTP su TLS) browser e server negoziano chiavi di sessione. Il traffico applicativo esce dal dispositivo già cifrato e viene decifrato solo all’estremo opposto della connessione TLS. Un osservatore vede pacchetti opachi; non legge il body HTML né la password nel form.

* Con HTTPS il percorso completo dell’URL non è leggibile in chiaro sul filo dopo l’handshake; resta nel tunnel TLS.
** Nella fase iniziale della connessione il Server Name Indication (SNI) — il nome host che stai contattando — viaggia ancora spesso in chiaro. Chi gestisce la rete può sapere verso quale dominio vai, non cosa fai dentro. Tecnologie come ECH (Encrypted Client Hello) mirano a ridurre anche questo segnale, ma non sono universali: non basare la privacy solo su di esse.

💡 Consiglio pratico — Cifratura ≠ fiducia
HTTPS è il furgone blindato: protegge il pacco in viaggio. Non ti dice se il destinatario è un truffatore. La “fiducia” che ti serve per banca e mail è un altro problema: identità del dominio (URL) + abitudini (segnalibri, password manager, 2FA).

Cosa HTTPS non cifra (e perché conta)

Anche con lucchetto “ok”:

• il DNS (a seconda di come risolvi i nomi: DNS classico in chiaro, DoH/DoT se attivi) può rivelare quali host cerchi;
• i metadati di rete (IP di destinazione, volume, timing) restano osservabili;
• estensioni e malware sul tuo PC vedono comunque la pagina in chiaro dopo la decifratura locale.

Quindi: HTTPS riduce il rischio del tragitto. Non sostituisce antivirus, buon senso sull’URL né un password manager.

Anatomia del lucchetto: cosa controlla il browser

Prima di mostrare contenuti su https://…, il browser pretende dal server un certificato (in pratica una “carta d’identità” firmata per quel nome). Per accettare la connessione verifica, in sintesi, tre famiglie di controlli:

1. Possesso della chiave — Il server dimostra di possedere la chiave privata legata al certificato (altrimenti non completa l’handshake). Se fallisce, sospetti un impostore o un MitM goffo.
2. Corrispondenza del nome (hostname) — Il nome che hai nella barra (es. airiparo.it) deve essere coperto dal certificato (campo CN storico e, soprattutto, SAN).
3. Catena di fiducia — Il certificato deve essere firmato (direttamente o tramite intermedi) da una Certificate Authority (CA) che il tuo OS/browser considera attendibile, e non risultare revocato/scaduto secondo i controlli del client.

Se qualcosa non torna, ottieni pagine tipo «La tua connessione non è privata» / «Avviso di sicurezza». Quell’avviso non è un optional da bypassare per “vedere comunque il sito” quando stai per inserire credenziali.

⚠️ Attenzione — Icone che cambiano
Chrome e Edge stanno riducendo il lucchetto “rassicurante” a favore di icone più neutre (impostazioni sito / scudo). Il significato tecnico resta: connessione TLS accettata verso quel host. Non leggere l’icona come bollino etico.

Il certificato in 5 minuti (senza panico)

Non serve leggere tutta la ASN.1. Per capire con chi stai parlando bastano pochi campi.

Campi utili

DV in due parole (perché i phishing hanno il lucchetto)

Le CA automatizzate (Let’s Encrypt e simili) rilasciano certificati DV a chi dimostra il controllo del nome. È una vittoria per cifrare il web. È anche il motivo per cui banca-sicura-login-123.example può avere HTTPS impeccabile: la CA non giudica se il brand è “la tua banca”.

Perché HTTPS non equivale a «sito sicuro»

1. Phishing su HTTPS (domini lookalike)

Registri un dominio confondibile (paypa1…, …-secure-login…, IDN con caratteri simili), metti una copia della pagina di login, chiedi un certificato DV. Il browser cifra verso quel host e mostra connessione sicura — verso il truffatore. La cifratura protegge il tragitto delle tue credenziali fino al suo database.

2. Sito legittimo ma compromesso

CMS datato, plugin vulnerabile, credenziali admin deboli: un attaccante inietta form o script malevoli. Il certificato resta valido: stai parlando davvero col server della vittima, ma il contenuto è avvelenato. HTTPS garantisce integrità in transito, non igiene del codice sul server.

3. Download e malware

Scaricare un .exe / .apk / documento booby-trapped via HTTPS impedisce (di regola) a un MitM di sostituire il file a metà strada. Non dice che il file è pulito. Il lucchetto non è un antivirus.

4. Tracking, XSS, abusi nel contenuto

Pixel, script di profilazione, XSS riflessi o persistenti vivono dentro la pagina. TLS cifra il tubo; non filtra cosa il sito ha deciso di servirti.

🚨 Avviso critico — Link in email e SMS
Quasi tutti i kit di phishing seri oggi usano HTTPS. Non usare l’icona come prova di legittimità. Conta l’URL carattere per carattere (o, meglio, non cliccare: apri il sito dai segnalibri).

Laboratorio pratico: ispezionare la connessione (desktop)

Obiettivo: abituarti a leggere host + emittente + scadenza, non a collezionare screenshot.

Windows — Chrome / Edge (percorso principale)

1. Apri un sito che conosci (es. https://www.wikipedia.org o questo sito).
2. Clicca l’icona a sinistra della barra indirizzi (lucchetto, scudo o “impostazioni sito”).
3. Apri La connessione è sicura (o dicitura equivalente).
4. Apri Il certificato è valido / dettagli certificato.
5. Nella finestra (UI browser o store certificati di Windows) leggi: rilasciato a / SAN, rilasciato da, date.
6. Opzionale, se sviluppi: F12 → scheda Security / Sicurezza: versione TLS e sintesi cifratura.

Cosa annotarti mentalmente:

• Il nome in barra coincide con quanto vedi nei SAN?
• L’issuer ti dice qualcosa di utile sul brand? Di solito no (DV).
• Se sei arrivato da un link strano e l’host è “quasi” quello giusto → esci senza login.

macOS — Safari

1. Clic sul lucchetto (o indicatore connessione) nella barra.
2. Mostra certificato.
3. Espandi la catena: foglia (sito) → intermedi → root. Stessi campi utili: nomi, issuer, date.

Firefox (Windows, macOS, Linux)

1. Lucchetto → Connessione sicura → Ulteriori informazioni.
2. Finestra Informazioni pagina → Mostra certificato.
3. Pagina integrata con Subject, Issuer, SAN, fingerprint.

Linux — Chrome / Firefox

Stesse etichette di Windows/macOS per le rispettive UI. Cerca sempre la catena «connessione sicura → certificato».

Telefono (sintesi)

Su Android/iOS l’ispezione certificato è più scomoda. In pratica: non fare forensics sul telefono per siti sospetti; usa il PC, oppure non procedere al login. Sul mobile conta ancora di più: segnalibri, app ufficiali dello store, 2FA.

Mixed content e l’icona “strana”

A volte l’URL è https://… ma l’indicatore non è “pienamente sicuro”: informazione, lucchetto barrato, avvisi in Console.

Mixed content = pagina caricata in HTTPS che tira dentro risorse via HTTP (script, CSS, iframe, a volte immagini).

• Attivo (script, fogli che eseguono logica): i browser moderni bloccano o tentano upgrade; se uno script HTTP passasse, un MitM potrebbe sostituirlo e girare nel contesto della pagina “https”.
• Passivo (immagini, video): rischio minore ma segnalato; l’UI può togliere il massimo livello di sicurezza.

Diagnosi rapida (desktop): F12 → Console / Sicurezza e cerca messaggi su risorse http:// o “mixed”.

Se gestisci tu il sito: forza HTTPS lato hosting, evita hardcode http://, controlla CSP/upgrade-insecure-requests dove ha senso. Per header e hardening da hosting c’è la guida su CSP, HSTS e co. — lettura opzionale, non necessaria per usare HTTPS come navigatore.

Checklist quotidiana: oltre l’icona

Azioni pratiche

1. Segnalibri per i siti sensibili — Banca, SPID/CIE dove usi il web, webmail, password vault web: salva l’URL buono e usalo. Evita di “ricercare il nome + login” su Google ogni volta (annunci sponsorizzati inclusi).
2. Password manager — Se il gestore non propone il autofill, il dominio non matcha quello salvato. È uno dei segnali anti-phishing più onesti che hai. Guida pratica: password manager.
3. 2FA / passkey — Anche se un faux-HTTPS ruba la password, un secondo fattore serio alza il costo dell’attacco. Checklist post-breach: 2FA e passkey.
4. Non bypassare gli errori di certificato su siti dove inserisci segreti. “Avanzate → procedi” è per debugging controllato, non per home banking da link in SMS.

Errori comuni

1. Fidarsi dell’icona sugli annunci — Gli ads possono portare a cloni HTTPS. Controlla l’host prima di scaricare o loggarti.
2. Ignorare «connessione non privata» — Certificato scaduto, nome sbagliato, CA non fidata, intercettazione aziendale mal configurata: in tutti i casi, non inserire password “per vedere cosa c’è”.
3. Confondere HTTPS e VPN — La VPN sposta il percorso IP; non rende onesto un sito. Su HTTP attraverso VPN, l’operatore VPN (o chi rompe quella tratta) può vedere troppo. HTTPS resta utile con o senza VPN. Approfondimento: a cosa servono davvero le VPN.
4. Pensare che http://localhost in sviluppo = produzione — Molte API sensibili del browser richiedono contesto sicuro (HTTPS o localhost esplicitamente trattato). In produzione serve HTTPS vero.
5. Usare solo il colore/icona EV del 2015 — L’UI “verde con ragione sociale” non è più il faro che molti ricordano. Torna all’URL.

Domande Frequenti (FAQ)

Cos’è HTTPS in una frase?

È HTTP trasportato dentro una sessione TLS: tunnel cifrato e autenticato (via certificato) tra il tuo browser e il server di quel nome a dominio.

Il lucchetto (o l’icona “connessione sicura”) significa che il sito è affidabile?

No. Significa che la connessione verso quel host è stata accettata dal browser (cifratura + controlli sul certificato). L’host può essere un phishing.

Un sito di phishing può avere HTTPS?

Sì, ed è la norma. Con validazione DV chi controlla il dominio ottiene un certificato legittimo per quel nome falso.

Qual è la differenza tra HTTP e HTTPS sulla Wi‑Fi del bar?

In HTTP password e pagine viaggiano leggibili per chi intercetta. In HTTPS vede traffico cifrato verso un IP/host; non legge il contenuto del login (salvo compromissione del device o bypass dell’errore certificato).

Cosa significa l’avviso «la tua connessione non è privata»?

Il client ha rifiutato il certificato o la catena (scadenza, nome non corrispondente, emittente non fidato, problemi di revoca, ecc.). Fermati: non è il momento di inserire dati sensibili.

Mixed content: perché un sito https:// segnala contenuti non sicuri?

Perché la shell della pagina è HTTPS ma alcune risorse sono richieste in HTTP. I browser moderni mitigano; resta un segnale di configurazione debole.

HTTPS sostituisce antivirus, password manager o VPN?

No. Coprono problemi diversi: transito (HTTPS), file/device (antivirus), riuso password e phishing di dominio (password manager), percorso/IP (VPN). Servono insieme, non in sostituzione.

In sintesi

HTTPS è necessario e oggi è il default sensato del web: senza, sei nudo sul tragitto. Non è sufficiente a decidere se fidarti di un login. Affianca all’icona: lettura dell’host, segnalibri, password manager, 2FA, e zero pazienza per gli avvisi di certificato sui siti che contano.

Letture opzionali

• A cosa servono davvero le VPN — percorso di rete ≠ onestà del sito.
• Come fare un audit di sicurezza gratuito — se gestisci tu un sito e vuoi voti/config TLS lato server.
• Password manager in pratica — autofill come allarme anti-lookalike.