Ciao,
a volte un forum presenta avvisi per contenuti misti. Vedi ora Letsencrypt:
Alcuni favicons - http://alohadentalgroup.com/assets/icons/favicon.ico
Rilevato in https://sjc4.discourse-cdn.com/letsencrypt/assets/_application-b690f7341f116f756f6621f3fbcc8e6ae69695c2db2f5ebceb6c46aaed19b17f.js 76678:17
Non è possibile modificare questi collegamenti in https o ignorare questi link http?
Un forum con contenuti misti è negativo.
Quell’URL dell’favicon non è ospitato su Discourse, stai usando Discourse? Qual è l’URL dell’installazione?
Hai abilitato force_https?
Se sì, ricarica le tue icone. Se no, abilitalo e poi ricarica.
Non lo so, non sono un amministratore del forum di Letsencrypt.
Ma se esiste un’opzione locale, chiederò nel forum interno Regular-forum.
PS: Grazie per lo spostamento
Il messaggio di avviso non è motivo di preoccupazione.
Uno degli utenti del sito Let’s Encrypt ha inserito un URL in http in questo argomento: Issues running certbot command - Help - Let's Encrypt Community Support.
Per questo motivo il browser avvisa (a ragione) della presenza di contenuto misto.
Gli avvisi sui contenuti misti sono sempre negativi. È possibile aggiungere cookie tramite HTTP che vengono utilizzati nella successiva connessione HTTPS. Pertanto, il software del forum non dovrebbe mai avviare connessioni HTTP.
In particolare in un forum che discute di “Il mio certificato è errato” o “Ho avvisi sui contenuti” (il certificato è corretto, ma ci sono contenuti misti: primo certificato con quel dominio, i collegamenti devono essere aggiornati).
Quel favicon non è disponibile tramite HTTPS. L’avviso sui contenuti misti non è ideale, ma è preferibile alla confusione dell’utente sul motivo per cui i suoi link non funzionano.
Lo so. Ma è possibile che un uomo nel mezzo utilizzi una connessione HTTP avviata dal browser per aggiungere un cookie tramite HTTP. In seguito, il cookie viene inviato dal browser tramite HTTPS e l’uomo nel mezzo conosce il cookie di sessione.
Funziona. Lo stato HTTP (404, 301, 410, 500) non è rilevante.
Questo è
non è un problema. Il favicon non è un link avviato dall’utente; l’utente aggiunge solo il link HTTP al sito senza HTTPS.
Soluzione semplice: Nessuna anteprima se la destinazione è HTTP. In tal caso, non è necessario caricare il favicon.
Non su una connessione di terze parti. Il browser non invia i propri cookie per il sito del forum a un altro sito, sia HTTP che HTTPS.
Stai creando un problema che non esiste. Si prega di dimostrare uno sfruttamento per questo su try.discourse.org se si ritiene davvero che questo sia un problema.
Questo non è il problema. Sarebbe un bug del browser.
Un uomo nel mezzo può aggiungere un cookie nella connessione http://alohadentalgroup.com con il dominio alohadentalgroup.com, con il nome noto di un cookie di sessione (se esiste, non ho verificato) di quel dominio (non dal dominio del forum).
Se un utente - in seguito - utilizza il login di https://alohadentalgroup.com per gestire quel dominio, quel cookie (creato tramite HTTP) viene inviato di nuovo tramite HTTPS.
Questa è una funzionalità critica (e spesso sconosciuta) dei cookie.
Questo è uno dei motivi per cui vengono creati i prefissi dei cookie. Per i cookie che iniziano con __Secure- o __Host-, è richiesto HTTPS. In tal caso, ciò non è più possibile. Lo stesso vale per Preload (ma la maggior parte dei siti non utilizza HSTS e non è pre-caricato).
Vedi (2017)
o altri link.
PS: Il mio “controlla il tuo sito web” (vedi il mio profilo) ha una pagina con alcuni esempi. E una piccola demo. Un cookie creato tramite HTTP e inviato di nuovo tramite HTTPS. Tramite HTTP non è possibile (con un browser moderno) creare il cookie __Host-. Ma i cookie con prefisso sono rari.