Come rendere HTTPS la prima richiesta tramite una VPN

Un browser che digita prima http:// e arriva su https:// dopo un reindirizzamento ha già inviato una richiesta in chiaro e una VPN non cambia la situazione. Il tunnel protegge la tratta dal cliente al nodo di uscita; non crittografa nulla al di sopra dello strato di trasporto, quindi un osservatore tra l'uscita e l'origine vede ancora il salto del testo in chiaro. Rendere HTTPS la prima richiesta è una modifica lato client composta da tre parti: un vero indirizzo HTTPS, la modalità di aggiornamento del browser e la politica del sito. I passaggi seguenti sono nell'ordine che utilizzo, ciascuno con il segno di spunta che ti dice se è stato necessario.

Passaggio 1: conferma qual è effettivamente la prima richiesta

Prima di modificare qualsiasi cosa, guarda cosa invia il browser. Aprite il pannello rete con la pagina ricaricata da una cold cache e leggete la prima riga: se lo schema è http e lo stato è 301 o 308, tutto quello che segue quella riga è una seconda richiesta. curl -sS -o /dev/null -w '%{http_code} %{url_effective}\n' http://example.com riproduce la stessa sequenza fuori dal browser e stampa l'URL su cui sei finito.

Sono possibili due risultati che necessitano di soluzioni diverse. Se il sito supporta HTTPS sullo stesso host, la soluzione è interrompere la pubblicazione del modulo HTTP: aggiornare il segnalibro, il collegamento wiki, il collegamento sul desktop e il modello di posta elettronica su cui gli utenti fanno clic. Se il sito non supporta affatto HTTPS, nessuna impostazione del browser lo creerà e la risposta onesta è che il problema è la destinazione. Non sovrascrivere il secondo caso con un'eccezione, poiché un'eccezione di certificato nella pagina di un account converte un problema di trasporto in un problema di credenziali. Annota in quale caso ti trovi prima di toccare un'impostazione.

Passaggio 2: attiva la modalità solo HTTPS del browser

La modalità di aggiornamento è la seconda parte e le modalità non sono intercambiabili. Controlla cosa fa il tuo prima di abilitarlo: aggiorna in silenzio, aggiorna con un avviso o rifiuta di caricare.

In Firefox i controlli si trovano dietro about:config e nella pagina delle impostazioni sulla privacy, con dom.security.https_only_mode come interruttore ed eccezioni per sito gestite dal menu del lucchetto. In Chrome ed Edge la stessa idea si trova in Impostazioni, Privacy e sicurezza, Sicurezza, etichettata Utilizza sempre connessioni sicure. Qualunque sia l'etichetta, verifica il comportamento rispetto a un host che risponde solo sulla porta 80, perché una modalità che si aggiorna e poi ritorna silenziosamente non è la protezione che pensi di aver abilitato. La documentazione di Firefox HTTPS-Only descrive il comportamento di aggiornamento, avviso ed eccezione per quel browser.

Passaggio 3: correggi le risorse, non solo la barra degli indirizzi

Quando un aggiornamento fallisce, leggi l'errore esatto invece della barra degli indirizzi. Un host senza ascoltatore HTTPS, un nome host che non corrisponde al certificato e una catena scaduta producono messaggi diversi e appartengono a proprietari diversi. Solo il primo è un gap lato server; il secondo è solitamente un segnalibro che non è mai stato aggiornato; il terzo è un problema di rinnovo per il quale la connessione VPN è irrilevante.

Non aggiungere un'eccezione di certificato al sito di un account perché la VPN è attiva. L'eccezione disabilita il controllo che avrebbe rilevato esattamente l'intercettazione che una VPN dovrebbe impedire.

La terza parte è all'interno della pagina ed è quella che manca alle persone. Una pagina caricata su HTTPS può comunque estrarre immagini, caratteri o script da un URL http e il browser li bloccherà o eseguirà il downgrade dell'indicatore di sicurezza per l'intera pagina. Ispeziona le richieste non riuscite nel pannello di rete e correggi i riferimenti alle risorse presso il loro proprietario anziché dare per scontato che la barra degli indirizzi descriva ogni richiesta. Su un sito che gestisci, ciò significa correggere gli URL memorizzati nel CMS o nel modello invece di riscriverli nel browser. Se non puoi modificare la fonte, registra il contenuto misto come una lacuna nota, perché un lucchetto su una pagina che estrae risorse di testo normale è un falso segnale.

Passaggio 4: cosa aggiunge HSTS e cosa no

HSTS è una politica del sito piuttosto che una preferenza del browser, ed è l'unico meccanismo che sopravvive a un http:// digitato su un nuovo profilo. Una volta che un browser ha visto un'intestazione Strict-Transport-Security per un host, riscrive le richieste successive in https prima di inviarle, che è esattamente la proprietà che desideri. Non fa nulla per un host che il browser non ha mai visitato e non fa nulla per un nome host diverso che serve la stessa applicazione.

Controlla cosa invia l'origine con curl -sSI https://example.com | grep -i strict-transport-security. Un'intestazione mancante è una modifica del server e non qualcosa che un client può installare. Se è presente, leggi max-age e se è impostato includeSubDomains, perché scade un breve periodo massimo tra le visite e un includeSubDomains mancante lascia ogni sottodominio non protetto. RFC 6797 definisce come un agente utente applica la politica e cosa può ignorare. Il precaricamento è un impegno separato, quindi controlla lo stato tramite l'API hstspreload.org prima di promettere a qualcuno che un dominio è nell'elenco.

Verifica e rollback

Il rollback è economico per le impostazioni del client e costoso per HSTS. La disattivazione della modalità solo HTTPS ripristina immediatamente il comportamento precedente; un'età massima lunga non lo fa e i visitatori che l'hanno già ricevuta continuano ad aggiornare fino alla scadenza.

Quindi verifica l'ordine prima di concludere. Ricarica da una cache fredda e conferma che la prima richiesta nel pannello di rete è https senza reindirizzamento precedente. Quindi controlla un sottodominio, perché includeSubDomains è il luogo in cui queste politiche di solito risultano più ristrette di quanto previsto. Quindi controlla una pagina che estrae risorse di terze parti, poiché il contenuto misto è l'errore che sopravvive a ogni altra correzione.

Se dopo tutto ciò la prima richiesta è ancora http, il client non è più la variabile: lo è il collegamento su cui gli utenti fanno clic. Cerca nei luoghi che controlli il modulo http del nome host, aggiornali e riprova con lo stesso ricaricamento della cache a freddo. Mantieni la domanda sulla VPN separata ovunque, perché il tunnel cambia chi può vedere la richiesta e non cambia mai se la richiesta è crittografata. La riga da inserire nel ticket è che la prima richiesta è quella che conta e un reindirizzamento è solo una ricevuta per una richiesta già inviata.