Durante le fasi di passaggio da HTTP in chiaro ad HTTPS criptato potrebbe capitare un errore piuttosto fastidioso: nella mia esperienza è capitato con numerosi siti web in WordPress. Si tratta della notifica sul browser, una volta che siamo passati ad HTTPS in WordPress, di “Connessione non sicura“: in particolare, “alcuni elementi di questa pagina non sono sicuri – ad esempio immagini“. In un precedente articolo di questo sito, per la cronaca, abbiamo discusso su come passare WordPress in HTTPS.
Generalità sul problema: mixed content
In ambito tecnologico il problema è noto come “contenuti misti” (Mixed Content, vedi anche qui) e si può riassumere in questo scenario: se il vostro utente visita una pagina web del vostro sito in HTTPS, la connessione sarà – come sappiamo – crittografata ed autenticata digitalmente. Tuttavia se nella richiesta sono presenti contenuti che includano richieste HTTP (in chiaro), ad esempio una chiamata ad una REST API – che di solito dovrebbero essere in HTTPS, per inciso – oppure ad una libreria cloud esterna in HTTP, si porrà il problema di una connessione solo parzialmente criptata.
Tecnicamente, quindi, i browser considerano insicura questa situazione e passibile di attacchi Man in the middle, per cui avviseranno l’utente del problema mediante un warning. In casi concreti può succedere che:
- le immagini con attributo src in HTTP siano visualizzate comunque (di solito), ma scompaia l’icona verde da HTTPS;
- eventuali contenuti caricati mediante jQuery, ad esempio, su URL esterni in HTTP non criptato non vengano eseguiti affatto (dipende dalla versione del browser, il comportamento non è uniforme in questo caso), a volte notificando il problema esplicitamente, a volte no;
- i fogli di stile vengano caricati ugualmente (di solito), facendo scomparire -Â anche qui – l’icona verde di HTTPS correttamente configurato.
I contenuti misti fanno pertanto riferimento alla co-presenza di HTTP e HTTPS all’interno di pagine web per cui avete configurato ad esempio Let’s Encrypt oppure altro genere di certificati.
Qual’è il problema?
In termini leggermente più tecnici, la notifica in questione è causata dalla presenza di URL (immagini o link) nella pagina HTML del vostro sito che si trovino in HTTP e non in HTTPS; i motivi per questa situazione sono vari, e possono dipendere sia da theme non pienamente compatibili con HTTPS che da plugin (specie di ottimizzazione o minificazione di CSS e JS, ma anche da alcuni plugin di rating con le stelline che inseriscono inavvertitamente URL in HTTP in chiaro). Il problema è quindi che il theme o il plugin o qualche personalizzazione del vostro sito non usa correttamente HTTPS, o meglio utilizza – ad esempio, caso tipico – delle stringhe statiche (o “cablate” nel codice) per cui associa all’URL di un’immagine la sua versione in chiaro e non quella criptata (dinamica, solitamente mediante site_url()).
Se ad esempio abbiamo un theme che usa la funzione site_url(), per l’appunto, essa cambia il prefisso del protocollo da HTTP a HTTPS in modo automatico, come lo cambiamo dal backend amministrativo di WordPress. Quindi è opportuno che questa funzione sia usata ovunque, in modo da garantire massima compatibilità con HTTPS con il theme stesso. Considerate che molti theme gratuiti non sono compatibili pienamente con HTTPS, per cui possono dare questo problema e vanno segnalati agli sviluppatori, o al limite corretti manualmente mediante apposito theme child.
Questa pagina sta tentando di caricare script da fonti non autenticate
Non è l’unico caso che può capitare e, ad esempio, se usate plugin per minificare i file CSS e/o JS, può capitare che comprimano i vostri file in modo non corretto o con l’URL in HTTP anzichè HTTPS. In genere, nella pagina HTML qualsiasi occorrenza di HTTP in chiaro deve essere rimpiazzata con la versione HTTPS. Se non fosse disponibile, le risorse esterne (ad esempio le @import di CSS, vanno localizzate): un altro potenziale problema può essere legato alla presenza di istruzioni come questa (in un file CSS del vostro theme):
@import url("http://netdna.bootstrapcdn.com/font-awesome/3.2.1/css/font-awesome.min.css"); @import url("http://fonts.googleapis.com/css?family=Roboto:400,300,700italic,700,500&subset=latin,latin-ext");
che andrebbe corretta, in questo caso, come:
@import url("https://netdna.bootstrapcdn.com/font-awesome/3.2.1/css/font-awesome.min.css"); @import url("https://fonts.googleapis.com/css?family=Roboto:400,300,700italic,700,500&subset=latin,latin-ext");
Un errore analogo è legato alla notifica, in questo caso, alla notifica di Chrome “Questa pagina sta tentando di caricare script da fonti non autenticate“, dove l’errore è legato a questo problema o ad altri analoghi su: minificazione CSS/JS, import errate in HTTP e cosଠvia. In alcuni casi, il caricamento di Google Fonts (che vanno in HTTPS di default) potrebbe andare in conflitto con il fatto che il sito sia in HTTP, generando mixed content che, in genere, ad alcuni browser non “piace” troppo.
Attenzione, ovviamente, che quando passiamo un URL da HTTP a HTTPS dobbiamo assicurarci che il browser dia una notifica “Sicuro” con l’icona in verde, altrimenti il problema non si potrà risolvere.
Come si risolve il problema
Per risolvere il problema bisogna ricorrere ad alcuni tool per la scansione della pagina, alla ricerca degli elementi (soprattutto immagini e link) che siano rimasti inavvertitamente in chiaro.
Tool di verifica per HTTPS
La maggioranza dei tool per queste verifiche, ad oggi, è a pagamento, per cui richiede una sottoscrizione per essere usata: l’unico tool gratuito per fare il check di HTTPS implementato correttamente sul vostro sito è, per quanto ho potuto vedere:
👇 Contenuti da non perdere 👇
- Informatica 🖥
- Marketing & SEO 🌪
- Mondo Apple 🍎
- Programmare 🖥
- Scrivere 🖋
- Sicurezza & Privacy 👁
- WordPress 🤵
- 💬 Il nostro canale Telegram: iscriviti
- 🟢 Processi decisionali di Markov nella vita di ogni giorno, spiegati in modo semplice
- 🟠 Che vuol dire “blogger”?
- 🔴 EPP: come funzionano i codici di stato dei domini