Link alla notizia: https://www.hwupgrade.it/news/software-business/chrome-si-fa-poliziotto-dalla-versione-82-segnalera-e-blocchera-i-download-non-sicuri_87032.html

Nel tentativo di indurre sempre più gli sviluppatori a passare ad HTTPS, Chrome partirà dalla primavera con una nuova politica di segnalazione e successivo blocco di download non-HTTPS in pagine HTTPS

Click sul link per visualizzare la notizia.

Primo download bloccato per salvarci da noi stessi? Quello di firefox :D

Il primo download che mi blocca e lo disinstallo, già gli AV FREE con il 90% di falsi positivi bastano, manca solo il browser che blocca i download a suo parere.

nella versione 83 scaricherà solo quel che vuole lui, quando vuole lui.

Non diciamo eresie ragazzi, il blocco riguarda solo contenuti http (o esposti in https con evidenti problemi, es certificati non trustati e scaduti, che non rispettano il minimo sindacale in fatto di hardening etc etc) inseriti in pagine https, e deo gratias che qualcuno si è preso la responsabilità di segnare un punto di svolta per spingere il mondo del web in questa direzione.

Quelli che dovranno preoccuparsi sono semmai coloro che ospitano servizi o ne rispondono, per loro si che sarà "pianto e stridore di denti", e lo dico da diretto interessato che ha a perimetro presso svariati clienti dei servizi arcaici su cui i clienti non vogliono spendere un euro per adeguamenti di sicurezza.

L'unico appunto che mi sento di fare alla strategia di Chrome è che forse è eccessivamente restrittiva, nel senso che segnala come non sicura una risorsa per il fatto stesso che essa sia referenziata in http nel codice renderizzato dalle pagine, a prescindere dal fatto che uno riscriva la richiesta del browser da http ad https (ad esempio con una banale regola di rewrite).

Per fortuna esistono moduli (almeno per Apache c'è il mod_substitute) che riscrivono la response http, ma come è facilmente intuibile questo avrà un impatto non indifferente dal punto di vista computazionale (significa in sostanza fare un find&replace su tutto il body della response http per qualsiasi risorsa).

Mi verrebbe da dire no comment.

HTTPS (rispetto a HTTP) non è la panacea a tutti i mali. Il traffico può essere tranquillamente intercettato tramite TLS/SSL inspection e varie agenzie statali o parastatali (e/o spionaggio industriale) sono già in grado di superare la protezione offerta da TLS.
E' solo un modo per Google di proteggere i dati personali che acquisisce tramite il vostro uso di Chrome o Android. Gratis sì, ma al prezzo dei possedere dati da incrociare per offrirti pubblicità mirata o rivendere/monetizzare in qualche modo.

Non diciamo eresie ragazzi, il blocco riguarda solo contenuti http (o esposti in https con evidenti problemi, es certificati non trustati e scaduti, che non rispettano il minimo sindacale in fatto di hardening etc etc) inseriti in pagine https, e deo gratias che qualcuno si è preso la responsabilità di segnare un punto di svolta per spingere il mondo del web in questa direzione.

Ciao, personalmente non sono d'accordo con l'approccio di Google, per almeno due motivi:

a) un download HTTPS non è certo garanzia di qualità (specie con il proliferare dei vari servizi SSL gratis, come letsencrypt)

b) è più difficile e invasivo fare deep inspection / content filter a livello perimetrale (la classica soluzione di SSL injection, che prevede di rompere il tunnel SSL "on demand" riscrivendo al volo il certificato tramite una CA condivisa è un processo pesante e invasivo).

Senza poi parlare di *come* i vari browser stanno implementando policy SSL sempre più restrittive: passi per l'impostazione di default, ma che non si possa riabilitare un accesso specifico (magari tramite whitelist) neanche tramite le impostazioni interne (chrome://flags, about:config e simili) mi sembra davvero assurdo, specie quando devi gestire un dispositivo che magari supporta solo l'RC4 o SHA1 :rolleyes:

Sinceramente credo che l'unico motivo dell'accanimento di Google (e quindi Chrome) verso i protocolli non criptati sia la volontà di rendere difficile filtrare i loro contenuti: l'SSL filtering, proprio per le criticità segnalate sopra, è ancora scarsamente utilizzato e questo significa che molte aziende non possono filtrare/limitare l'uso dei servizi di Google. Ancora più significativo, in tal senso, è l'uso del wildcard *.google.com per siti come youtube.com: dato che bloccare Google come motore di ricerca è fuori discussione, e quindi non si può bannare il CN=*.google.com, anche youtube (così come drive, gmail, ecc) risultano generalmente fruibili anche in realtà dove se ne farebbe volentieri a meno.

E mi sembra molto triste che Firefox segua a ruota molte delle discutibili scelte di Chrome... ma ormai è tardi per lamentarsi, il web è diventato di Google :stordita:

Seriamente… anche se lo intercettano il mio download (privacy a parte) quale danno ho alla fine? Che avrò potenzialmente un file corrotto? Faccio questa domanda per i soli contenuti che non riguardano dati sensibili ovviamente.

Ma cosa cambia a scaricare un file infetto in https invece che http? Che essendo tramite https può dare la falsa illusione che sia sicuro al 100%?

Ma cosa cambia a scaricare un file infetto in https invece che http? Che essendo tramite https può dare la falsa illusione che sia sicuro al 100%?
Appunto, non cambia nulla.

mi pare che confondano l'oggetto con il mezzo. Se scarico un virus tramite http o https, sempre un virus rimane..

Mha... Spero si possa disabilitare... Sinceramente... Come direbbe il grande Razzi... "amico caro, fatti li ca**i tuoi!"

mi sfugge la "pericolosità" di immagini png o jpg trasmesse via http anzichè https... :mbe:

Mi verrebbe da dire no comment.

HTTPS (rispetto a HTTP) non è la panacea a tutti i mali. Il traffico può essere tranquillamente intercettato tramite TLS/SSL inspection e varie agenzie statali o parastatali (e/o spionaggio industriale) sono già in grado di superare la protezione offerta da TLS.
E' solo un modo per Google di proteggere i dati personali che acquisisce tramite il vostro uso di Chrome o Android. Gratis sì, ma al prezzo dei possedere dati da incrociare per offrirti pubblicità mirata o rivendere/monetizzare in qualche modo.Lasciando perdere le teorie del complotto per un momento, avresti qualche esempio di questa "inspection" fatta da agenzie statali o parastatali?

Perchè se escludiamo casi di compromissione di chiavi private o installazione di certificati nel trust store del client (voluta, come può essere nel caso di una rete aziendale, o non voluta come nel caso di un malware o un sw che lo fa per esigenze specifiche, penso ad es a un web application firewall), quello che tu descrivi non è semplicemente possibile.

Ciao, personalmente non sono d'accordo con l'approccio di Google, per almeno due motivi:

a) un download HTTPS non è certo garanzia di qualità (specie con il proliferare dei vari servizi SSL gratis, come letsencrypt)Sono d'accordo, ma questa errata percezione di "qualità" è un problema degli utenti, non del protocollo, l'errore è stato associare cifratura a garanzia di sicurezza da parte degli utenti, mentre invece sappiamo bene che questa sicurazza vale solo per il canale di comunicazione punto-punto tra client e server, se poi il server veicola contenuti non sicuri questo è un altro paio di maniche.

Poi si può discutere da dove sia nata questa errata percezione, e qui i fattori sono molteplici: ignoranza (nel senso di scarsa informazione), strategie comunicative catastrofiche (pensiamo alla scemenza dei vari "lucchetti" dei colori più disparati), interesse economico da parte delle CA (pensiamo all'altra grande idiozia dell'extended validation).

Riguardo a Let's Encrypt io non condivido per nulla certe posizioni che ho trovato a volte in rete riguardo al fatto che sarebbero "colpevoli" di aver fatto passare per sicuri siti che non lo sono, stesso discorso di prima, errata percezione della finalità del protocollo https.
Piuttosto Let's Encrypt è stato al contrario una molla spaventosa e positiva, e non parlo solo della diffusione del protocollo o di aver reso accessibile a tutti qualcosa che prima era costoso (le CA ragazzi! Dimentichiamo quanti soldi ha munto questa gente per qualcosa che di fatto ha un costo ZERO) e riservato a chi poteva/voleva spendere dei soldi (e bei quattrini eh...), ma anche al fatto che ha di fatto costretto un'intero comparto ad automatizzare un processo che prima era totalmente manuale con gravi rischi, già solo il fatto di limitare la durata dei certificati a 3 mesi è un enorme incentivo a monitorare, manutenere, isolare i casi di compromissione delle chiavi (o per lo meno limitare fortemente il loro impatto nel tempo).

b) è più difficile e invasivo fare deep inspection / content filter a livello perimetrale (la classica soluzione di SSL injection, che prevede di rompere il tunnel SSL "on demand" riscrivendo al volo il certificato tramite una CA condivisa è un processo pesante e invasivo).

Senza poi parlare di *come* i vari browser stanno implementando policy SSL sempre più restrittive: passi per l'impostazione di default, ma che non si possa riabilitare un accesso specifico (magari tramite whitelist) neanche tramite le impostazioni interne (chrome://flags, about:config e simili) mi sembra davvero assurdo, specie quando devi gestire un dispositivo che magari supporta solo l'RC4 o SHA1 :rolleyes:

Sinceramente credo che l'unico motivo dell'accanimento di Google (e quindi Chrome) verso i protocolli non criptati sia la volontà di rendere difficile filtrare i loro contenuti: l'SSL filtering, proprio per le criticità segnalate sopra, è ancora scarsamente utilizzato e questo significa che molte aziende non possono filtrare/limitare l'uso dei servizi di Google. Ancora più significativo, in tal senso, è l'uso del wildcard *.google.com per siti come youtube.com: dato che bloccare Google come motore di ricerca è fuori discussione, e quindi non si può bannare il CN=*.google.com, anche youtube (così come drive, gmail, ecc) risultano generalmente fruibili anche in realtà dove se ne farebbe volentieri a meno.

E mi sembra molto triste che Firefox segua a ruota molte delle discutibili scelte di Chrome... ma ormai è tardi per lamentarsi, il web è diventato di Google :stordita:Assolutamente d'accordo sul fatto che sarebbe preferibile inserire un'opzione per whitelistare, come dicevo si tratta di approcci, Chrome ne sta seguendo uno più restrittivo, Firefox un po' più morbido (vedi ad es quello che scrivevo a proposito dell'identificazione del mixed content).

Sull'accesso a dispositivi o servizi datati capisco perfettamente, io stesso ho parecchi casi del genere (anche inversi, ad es servizi che girano su vecchie JDK che non possono fare handshake con TLS 1.1 e successivi, risolti tramite reverse proxy interno), però lasciami dire che si tratta pur sempre di casi specifici, con un target generalmente ristretto, si tiene una vecchia versione del browser e la si usa solo per quello (io ad es ho sempre un vecchio Firefox sul mio pc da lavoro, così come ho delle vecchie Java Runtime, che chiaramente attivo al bisogno per specifiche necessità).

Per il filtraggio dei contenuti francamente non la vedo come una cosa catastrofica, non hanno certo tolto il supporto ai proxy http, se si vuol bloccare l'accesso a certi siti si forzano gli utenti ad usarne uno (ad esempio tramite proxy trasparente), si blocca tutto in outbound e si gestisce tutto tramite white/blacklist sul proxy.
Poi sia chiaro, il filtraggio perfetto non esiste, solo i manager che non sanno di cosa parlano (un buon 99,9% periodico :rolleyes: ) pensano che si possa bloccare veramente qualcosa, se uno ha giusto giusto i rudimenti di networking può far passare qualsiasi cosa tramite un proxy http, anche se fa packet inspection (io ci faccio passare persino le vpn...).

Siamo rovinati. Dietro la scusa del proteggerci avranno pieni poteri su cosa puoi e cosa non puoi fare...e sarà tutto legale. Ma cacciatevela dove dico io questa prevenzione, io e chi sa quello che deve fare ci pensiamo da soli a noi stessi

Ciao, innanzitutto è sempre un piacere parlare con te :)

Sono d'accordo, ma questa errata percezione di "qualità" è un problema degli utenti, non del protocollo, l'errore è stato associare cifratura a garanzia di sicurezza da parte degli utenti, mentre invece sappiamo bene che questa sicurazza vale solo per il canale di comunicazione punto-punto tra client e server, se poi il server veicola contenuti non sicuri questo è un altro paio di maniche.

Poi si può discutere da dove sia nata questa errata percezione, e qui i fattori sono molteplici: ignoranza (nel senso di scarsa informazione), strategie comunicative catastrofiche (pensiamo alla scemenza dei vari "lucchetti" dei colori più disparati), interesse economico da parte delle CA (pensiamo all'altra grande idiozia dell'extended validation).


Assolutamente d'accordo.


Riguardo a Let's Encrypt io non condivido per nulla certe posizioni che ho trovato a volte in rete riguardo al fatto che sarebbero "colpevoli" di aver fatto passare per sicuri siti che non lo sono, stesso discorso di prima, errata percezione della finalità del protocollo https.
Piuttosto Let's Encrypt è stato al contrario una molla spaventosa e positiva, e non parlo solo della diffusione del protocollo o di aver reso accessibile a tutti qualcosa che prima era costoso (le CA ragazzi! Dimentichiamo quanti soldi ha munto questa gente per qualcosa che di fatto ha un costo ZERO) e riservato a chi poteva/voleva spendere dei soldi (e bei quattrini eh...), ma anche al fatto che ha di fatto costretto un'intero comparto ad automatizzare un processo che prima era totalmente manuale con gravi rischi, già solo il fatto di limitare la durata dei certificati a 3 mesi è un enorme incentivo a monitorare, manutenere, isolare i casi di compromissione delle chiavi (o per lo meno limitare fortemente il loro impatto nel tempo).


Mmm, forse mi sono espresso male: letsencrypt è stata davvero una boccata di aria fresca che, come giustamente dici tu, ha smosso parecchio le acque di un mercato che spesso vendeva aria fritta. Io stesso lo uso ogni volta che è possibile ;)
Tuttavia, proprio perchè di diventato semplicissimo avere certificati HTTPS validi, ormai da anni il semplice certificato non è affatto garanzia di qualità/affidabilità dei contenuti. Ovviamente questo li operatori del settore lo sanno benissimo, così come lo sa benissimo Google.


Assolutamente d'accordo sul fatto che sarebbe preferibile inserire un'opzione per whitelistare, come dicevo si tratta di approcci, Chrome ne sta seguendo uno più restrittivo, Firefox un po' più morbido (vedi ad es quello che scrivevo a proposito dell'identificazione del mixed content).
Sull'accesso a dispositivi o servizi datati capisco perfettamente, io stesso ho parecchi casi del genere (anche inversi, ad es servizi che girano su vecchie JDK che non possono fare handshake con TLS 1.1 e successivi, risolti tramite reverse proxy interno), però lasciami dire che si tratta pur sempre di casi specifici, con un target generalmente ristretto, si tiene una vecchia versione del browser e la si usa solo per quello (io ad es ho sempre un vecchio Firefox sul mio pc da lavoro, così come ho delle vecchie Java Runtime, che chiaramente attivo al bisogno per specifiche necessità).


Ok, siamo sulla stessa barca :stordita:


Per il filtraggio dei contenuti francamente non la vedo come una cosa catastrofica, non hanno certo tolto il supporto ai proxy http, se si vuol bloccare l'accesso a certi siti si forzano gli utenti ad usarne uno (ad esempio tramite proxy trasparente), si blocca tutto in outbound e si gestisce tutto tramite white/blacklist sul proxy.


Vero, ma il filtraggio via proxy è una cosa che vedo morire un po' dappertutto, anche in aziende piuttosto grandi (per la realtà italiana), a favore dei servizi UTM di border firewall. Che poi il proxy probabilmente sia, almeno sotto certi aspetti, l'approccio migliore non ci piove; tuttavia, bisognare fare i conti con fatto che è un approccio sempre meno utilizzato. E i vari servizi UTM dei next-generation firewall diventano quasi completamente inutili in presenza di traffico SSL, a meno che a) non si rompa il tunnel via SSL injection o b) si filtri a livello DNS (che è ancora in chiaro ma che, con DNSSEC, si vuole criptare anch'esso).

Riguardo ad agenzie o enti statali che vogliano filtrare il traffico SSL: in alcuni casi viene già fatto. Non è una prassi comune (in quanto invasiva e poco trasparente nei confronti dell'utente) ma la possibilità esiste, e io stesso ho ricevuto diverse richieste in proposito (dove poi non si è proceduto proprio perchè l'impatto sarebbe stato alto). E' qui il paradosso dell'approccio di Google: chi ha le risorse potrà comunque continuare a filtrare ma, dato che questo richiede dispositivi di fascia alta e parecchio lavoro da parte del reparto IT, molti semplicemente non potranno/vorranno filtrare. Ecco quindi che tutti i servizi di Google (e la relativa raccolta dati) saranno fruibili praticamente dappertutto ;)


Poi sia chiaro, il filtraggio perfetto non esiste, solo i manager che non sanno di cosa parlano (un buon 99,9% periodico :rolleyes: ) pensano che si possa bloccare veramente qualcosa, se uno ha giusto giusto i rudimenti di networking può far passare qualsiasi cosa tramite un proxy http, anche se fa packet inspection (io ci faccio passare persino le vpn...).


Qualcuno ha detto stunnel sulla porta DNS? coff coff ... :sofico: :banned: