Riprendo questo specifico problema per gestirlo meglio.
hashcat ha scritto:Problemi minori:
Persiste uno stato di "contenuto misto" nelle discussioni in cui vengono incorporate immagini esterne (richiamate via http). Soluzioni: forzare il richiamo via https: magari attraverso le RegEx (spunto) (è possibile con imageshack, imgur e dropbox ma non con posteimage ed imagebanana).
developerwinme ha scritto:- Quando visito alcuni topic (ad esempio, questo), IE 11 su Windows 8.1 continua a chiedermi se voglio visualizzare anche il contenuto non sicuro (credo sia colpa di una opzione che ho attivato nelle impostazioni, ma comunque indica che ci sono porzioni non https in alcune pagine del forum). EDIT: Problema simile con Firefox (viene visualizzato il cartellino triangolare di avviso nella barra degli indirizzi). Dal report di Firefox, sembra essere colpa di imageshack.
Confermo che il problema è dato dai siti di imagehosting.
Lato-server non è gestibile perché bisognerebbe moddare phpBB, cosa che rimane uno dei miei paletti fissi da evitare.
Cerco di capire se, in qualche modo, è gestibile via Javascript (come facciamo per la gestione dei link esterni). Rimane il problema che non lo possiamo fare indiscriminatamente perché non tutti i siti di img hosting supportano HTTPS, quindi lo implementeremo per quei 4-5 servizi più popolari. Aperto bug.
Zane ha scritto:Confermo che il problema è dato dai siti di imagehosting.
Lato-server non è gestibile perché bisognerebbe moddare phpBB, cosa che rimane uno dei miei paletti fissi da evitare.
Cerco di capire se, in qualche modo, è gestibile via Javascript (come facciamo per la gestione dei link esterni). Rimane il problema che non lo possiamo fare indiscriminatamente perché non tutti i siti di img hosting supportano HTTPS, quindi lo implementeremo per quei 4-5 servizi più popolari. Aperto bug.
Posso proporti una soluzione un po' drastica ma, a mio parere, assolutamente ragionevole: filtrare i "contenuti misti" attraverso la Content Security Policy (CPS) che ho aggiornato recentemente e reputo definitiva (ho aggiunto il supporto ai plugin sociali di Facebook, Twitter e Google+ che prima era assente).
In caso affermativo ciò comporterebbe che tutte le immagini future (e quelle passate) vadano ospitate su servizi che offrono la possibilità di accesso via HTTPS (con un certificato valido (la policy prevede imgur, imageshack e dropbox)). Bisognerebbe quindi includere, nelle regole del sito, l'obbligo di utilizzare i suddetti host (pena la non visualizzazione dell'immagine).
Posto le policy aggiornate (in modalità report only).
Come avevo specificato in QUESTO messaggio, puoi provare la policy a livello locale utilizzando il componente aggiuntivo per Chrome CSP Tester configurato come segue: URL Pattern:
Casella Active: selezionata
Casella Report Only: deselezionata
Cliccare su Save (per apportare le modifiche)
E' possibile tenere traccia dei contenuti bloccati utilizzando la Console di Chrome (inclusa negli strumenti per sviluppatori del browser).
P.S.: Come puoi vedere QUI, adottando questa soluzione, risolviamo i problemi per la maggior parte dei browser (o quantomeno per quelli che generano avvisi espliciti).
Credo che come soluzione di transizione (da unire ad una policy riguardo agli host consentiti) sia una soluzione valida (semplice) ed efficace.
Zane ha scritto:Cerco di capire se, in qualche modo, è gestibile via Javascript (come facciamo per la gestione dei link esterni).
Dovrebbe esserlo:
Regular Expressions (MSDN) [JavaScript].
Ho dato uno sguardo veloce ma se ciò fosse fattibile, sarebbe un grosso piacere in quanto in questo caso potremmo utilizzare le regole (già pronte e testate) di HTTPS Everywhere.
Esempi: Imgur, Imagshack.US/.COM, Dropbox.
hashcat ha scritto:In caso affermativo ciò comporterebbe che tutte le immagini future (e quelle passate) vadano ospitate su servizi che offrono la possibilità di accesso via HTTPS (con un certificato valido (la policy prevede imgur, imageshack e dropbox)). Bisognerebbe quindi includere, nelle regole del sito, l'obbligo di utilizzare i suddetti host (pena la non visualizzazione dell'immagine).
Capisco il tuo nobile scopo, ma questa è una forzatura troppo forte per un motivo che interessa una fetta ristretta di utenza. Per tutti gli altri, non è facile da recepire e viene percepita come una presa di posizione.
Mi spiace, ma non possiamo imporre quale image hoster usare: quello che possiamo certamente fare è trasformare gli HTTP in HTTPS su una lista di image hoster che abbiamo definito insieme. Per tutti gli altri, il mixed-content rimane.
Zane ha scritto:Capisco il tuo nobile scopo, ma questa è una forzatura troppo forte per un motivo che interessa una fetta ristretta di utenza. Per tutti gli altri, non è facile da recepire e viene percepita come una presa di posizione.
Capisco e condivido il tuo punto di vista, imparerò a convivere con l'avviso di IE
Correlato a questo, non dovremmo invece avere problemi con i contenuti inseriti sul portale vero e proprio? (i.e. lì va tutto correttamente in HTTPS, giusto?)
Se facciamo un lavoro di liste fatto bene, comprendendo la conversione HTTP->HTTPS di quanti più servizi di hosting possibile ("ogni volta che ne viene usato uno nuovo, proviamo a capire se è aggiungibile alla lista), mi aspetto che il numero di avvisi cali drasticamente.
Relativamente al portale...
le immagini degli articoli hanno tutte un src relativo (<img src="/immagini/17/med" />) quindi funzionano ok
Il resto degli elementi (logo, icone ecc) viene caricato con un URL assoluto che usa il protocollo scelto dal visitatore: dato che ora il visitatore non può più scegliere ed è tutto HTTPS, non ci sono problemi
Alcuni link interni negli articoli sono invece in HTTP normale, ma poi ci pensano HSTS e la redirezione automatica a gestirli
Per i topic di commento, invece: il link è ok grazie a HSTS e redirezione automatica, mentre l'immagine decorativa è più problematica: sugli articoli creati d'ora in avanti, non ci sono problemi ed è in HTTPS, mentre per alcuni di quelli vecchi è in HTTP normale (dipende se l'autore stava usando HTTP oppure HTTPS al momento della stesura del pezzo). Gestiremo questo scenario aggiungendo alla nostra lista di image hoster anche TurboLab.it fra i siti che supportano HTTPS
Zane ha scritto:Se facciamo un lavoro di liste fatto bene, comprendendo la conversione HTTP->HTTPS di quanti più servizi di hosting possibile ("ogni volta che ne viene usato uno nuovo, proviamo a capire se è aggiungibile alla lista), mi aspetto che il numero di avvisi cali drasticamente.
Capisco l'obiezione.
Provvedendo in questa direzione ho stilato una lista degli "image hoster" che ho visto utilizzati, fino a questo momento, sul forum e del loro supporto (o meno) all'HTTPS (ordinati per frequenza):
Postimage: Certificato invalido (cloudflare) Imgur: OK Imageshack: OK Imagebanana: servizio dismesso img.tapatalk.com: OK TinyPic: NO
Per quanto riguarda la CPS ne ho stilato una versione aggiornata che consente il caricamento di immagini da qualsiasi sorgente e richiede l'accesso via HTTPS a tutte le altre risorse. Ho apportato qualche revisione (cambiata la gestione della sorgente di default, aggiunta la direttiva object-src) e miglioria (aggiunte tre direttive non ancora implementate ma (dovrebbero esserlo) valide in futuro).
Posto le policy aggiornate (in modalità report only).
Mi ero dimenticato di segnalare due lievi problemi individuati durante alcune prove della CSP:
I link a contenuti esterni presenti nei commenti degli utenti in calce agli articoli (lato portale) non rispettano la convenzione di essere aperti, al click, in una nuova scheda (come sul forum)
Le due risorse riportate di seguito vengono servite da Apache con un MIME type errato:
Resource interpreted as Font but transferred with MIME type text/plain: "https://turbolab.it/fonts/accentbox/BebasNeue-webfont.woff"
Resource interpreted as Image but transferred with MIME type text/plain: "https://turbolab.it/cursors/zoom_in.cur"
Riporto in evidenza la discussione poiché temo che non sia stata presa visione dei due problemi (minori) segnalati in calce (nel precedente messaggio).
hash, per favore fai due discussioni con i due problemi aggiuntivi e due relativi bug perché altrimenti se non affrontiamo 1problema=1topic=1bug è ingestibile. Grazie.
Zane ha scritto:hash, per favore fai due discussioni con i due problemi aggiuntivi e due relativi bug perché altrimenti se non affrontiamo 1problema=1topic=1bug è ingestibile. Grazie.
Purtroppo via Javascript non si può fare (le immagini nel tag img src="" usato dal forum vengono caricate immediatamente dal browser...).
Ho allora provato con la funzione per la censura, ma non funziona con una stringa "complessa" come http://
Ho chiesto suggerimenti al supporto. Vediamo cosa mi rispondono e, al massimo, vado a capire se si può gestire il problema con una modifica da qualche parte (cosa che, sapete, voglio cercare di evitare, ma direi che il problema è sufficentemente importante da valerne la pena)
Zane ha scritto:e viene bloccata da Internet Explorer
Dal mio IE11 (sia desktop che mobile) non viene bloccata, perché di default vengono bloccati tutti i contenuti misti tranne le immagini (approccio utilizzato sia da Internet Explorer che dalle più recenti versioni di Firefox).
Per quanto riguarda Chrome, l'approccio dovrebbe essere simile, ma vengono consentiti anche alcune tipologie aggiuntive di elementi, oltre alle immagini.
Comunque ottimo che questo problema stia per essere sistemato!
Ma va in HTTPS automaticamente, di conseguenza diventa...
Il funzionamento è basato su una lista di image hoster che erogano le immagini anche via HTTPS. L'unico che ho inserito in questo momento è imgur.com, ma l'idea è di aggiungerne altri mano a mano che vengono utilizzato dagli utenti (eviterei di cercare di popolare la lista in modo preventivo, dato che i servizi sono tantissimi, nascono e muoiono come mosche e potrebbe diventare un'impegno notevole mantenerla aggiornata).
Capire se un servizio eroga immagini anche via HTTPS è semplicissimo: basta caricarla sul servizio da testare poi prendere il link diretto e provare a raggiungere l'immagine via HTTPS invece che via HTTP.
Esempio: Tapatalk. Caricando un'immagine via Tapatalk viene restituito un URL del genere:
Se provo ad aprire direttamente questa immagine via HTTPS, scopro che il servizio risponde con un certificato non-valido. Di conseguenza, imageshack.com non può essere inserito nella nostra lista.
Firefox 35, al contrario, mi funziona come sempre: immagini mostrate, ma iconcina di avviso in barra URL:
L'unica circostanza in cui anche Firefox blocca è quando provi a caricare un'immagine via HTTPS da un image hoster con certificato non-valido. Ad esempio, questa non si vede neanche con Firefox (il certificato usato da imageshack.com è valido solo per il loro .us )
Stando a quanto leggo in questo post (e ho validi motivi di credere che non sia cambiato nulla nelle versioni successivi, visto che ho un paio di PC, la cui configurazione è praticamente quella di default, con cui ho verificato), il comportamento di default è che IE 9 e successivi bloccano tutto il contenuto misto con quell'avviso, TRANNE LE IMMAGINI.
Internet Explorer Team ha scritto:IE9 includes additional smarts to distinguish between what types of unsecure references exist in the page. If a HTTPS page contains unsecure images, the images are permitted by default
...
When an HTTPS contains unsecure images, the lock icon is removed from the address bar to indicate to the user that not all content was delivered securely
Per attivare il blocco delle immagini "miste", è necessario andare in Opzioni Internet -> Avanzate -> spuntare "Blocca immagini non sicure con altri contenuti misti". Di default, la spunta non è presente.
Vedo che nella barra dell'url del tuo screenshot, è presente il simbolo (di colore blu, accanto al pulsante ricarica) relativo al filtro dei contenuti tramite liste di monitoraggio/blocco ActiveX.
Non dovrebbe c'entrare nulla, ma magari è colpa sua?
Provato a caricare la pagina con gli strumenti di sviluppo (F12) aperti nella scheda "Console"? All'interno di quella pagina dovrebbero essere elencati tutti gli errori trovati, inclusi quelli relativi alla protezione da contenuto misto.
Zane ha scritto:L'unica circostanza in cui anche Firefox blocca è quando provi a caricare un'immagine via HTTPS da un image hoster con certificato non-valido
Questa circostanza non viene invece bloccata da IE di default (sembra che l'immagine venga scaricata comunque, ma dall'URL con http), ma fa scattare l'eliminazione del lucchetto dalla barra degli indirizzi.
EDIT: Contrariamente a quanto detto sopra, pulendo la cache, ora neanche IE (sia desktop che mobile) carica il contenuto fornito da HTTPS con un certificato errato.
Se invece si carica questa pagina con gli strumenti di sviluppo avviati, vengono segnalati, nella scheda "Console", due errori relativi alla sicurezza HTTPS, uno per la risorsa non servibile tramite HTTPS per via del certificato, l'altro per l'immagine servita tramite HTTP.
Servire tutte le immagini in HTTPS comunque, migliora l'esperienza anche con IE in default, perché viene mantenuto il "lucchetto" nella barra degli indirizzi, confermando la sicurezza della connessione all'utente.
Riflettendo sul problema, avrei una domanda da porti: hai aggiunto TurboLab.it all'elenco dei siti attendibili in Internet Explorer?
Mi sembra di ricordare che le zone di sicurezza di IE abbiano un ruolo, che non ricordo di preciso, nella visualizzazione dei messaggi sul contenuto misto, pertanto potrebbe essere per questo che vedi quell'avviso.
Ho provato a fare il reset completo di IE e confermo che adesso nemmeno a me IE blocca più le immagini in mixed-content (se non sull'hoster con certificato invalido). Ad averlo saputo prima non averei perso tutto questo tempo, maledizione!!!!!!
Grazie Dev per avermelo segnalato, almeno ora sto davvero come stanno le cose!!!!
Procedo a spostare tutto nella discussione apposita.
@Doc: sono i miei capelli "al naturale"! Effettivamente in quelle foto avevo particolarmente bisogno di una spuntatina
Internet Explorer Team ha scritto:There are two important changes that impact users on sites using HSTS. First, when there is a certification error with a HSTS server, the user will not be able to click through and ignore the certificate error; they must abort their connection. Second, mixed content is not supported on servers supporting HSTS; all the content must be secure.
La 1) potrebbe crearci problemi sul bugtracker?
La 2) potrebbe comportare problemi nel forum?
Finalmente! E' l'unico browser con una diffusione rilevante che ne è ancora sprovvisto (QUI).
developerwinme ha scritto:La 1) potrebbe crearci problemi sul bugtracker?
No, abbiamo esplicitamente elaborato una policy che sia valida solo per il dominio principale (non sotto-domini): nessun problema.
Se tutto andrà bene, in futuro, dovremmo avere un certificato valido sia per il dominio principale che per sotto-dominio (bug.turbolab.it) e CDN; a quel punto sarà possibile aggiornare la policy (includendo anche i sotto-domini) senza incorrere in malfunzionamenti.
developerwinme ha scritto:La 2) potrebbe comportare problemi nel forum?
Se quanto è riportato nel blog post (tutti i contenuti misti vengono bloccati, compresi i file d'immagine), l'inconveniente maggiore sarebbe quello relativo alle immagini inserite dagli utenti nei messaggi tramite url http (ospitate da servizi che non offrono la possibilità di reperirle via https) e, limitatamente, i video di YouTube incorporati utilizzando un url http.
P.S.: Riguardo al punto 2, per valutare l'impatto del futuro blocco di tutti i contenuti misti in Internet Explorer, basta navigare (utilizzando un qualsiasi browser che supporti lo standard CSP 1.0), applicando (in locale) la seguente policy:
Inserendo un messaggio, dichiari di aver letto e accettato il regolamento di partecipazione.
Nello specifico, sei consapevole che ti stai assumendo personalmente la totale responsabilità delle tue affermazioni, anche in sede civile e/o penale,
manlevando i gestori di questo sito da ogni coinvolgimento e/o pretesa di rivalsa.
Dichiari inoltre di essere consapevole che il messaggio sarà visibile pubblicamente, accetti di diffonderlo con licenza
CC BY-NC-SA 3.0 (con attribuzione a "TurboLab.it") e rinunci ad ogni forma di compensazione (economica o altro).
Rinunci inoltre esplicitamente a qualsiasi pretesa di cancellazione del messaggio.
Re: Errore di "contenuto misto" HTTP/HTTPS sul forum
