August 2018 - nexa - server-nexa.polito.it

Re: [nexa] The Web is still a DARPA weapon.

by Giacomo Tesio

Ciao, riprendo da questo thread per evitare di deragliare quello sul DoH di Firefox che merita le proprie riflessioni. 2018-08-30 18:31 GMT+02:00 Marco Ciurcina <ciurcina(a)studiolegale.it>: > Come utente di Firefox, grazie dell'accuratissimo lavoro: mi piacerebbe molto > che Firefox implementi delle policy raffinate di gestione del codice JS. Ho aggiunto ulteriori suggerimenti su come proteggere gli utenti di Firefox dagli attacchi indicati (a quanto pare da alcune comunicazioni private che ho ricevuto, non sono l'unico ad avere l'impressione che non abbiano capito il problema). Li ho riordinati in questa risposta ad un utente che mi chiedeva esattamente come risolvere il problema: https://medium.com/@giacomo_59737/i-compiled-a-detailed-bug-report-for-mozi… L'idea di fondo comunque e' semplice: eseguire un programma controllato da estranei dovrebbe essere una scelta consapevole fatta volta per volta. Opt-in, non Opt-out. (soprattutto considerata la totale assenza di usabilità dell'interfaccia utente che ti permette di disabilitare JavaScript e WebAssembly su Firefox!) > Trovo preoccupante che si scriva "It is incorrect to report this as a bug in > firefox because this is intended behavior.". Se e' per questo, in quel thread Mozilla Security mi ha anche spiegato cosa significa Turing complete! Devo sembrare davvero... giovane? Deve essere il mio inglese... :-) Io trovo preoccupante che Mozilla, che tutti considerano paladina della privacy (oggi su diversi social network erano tutti a celebrarla https://blog.mozilla.org/futurereleases/2018/08/30/changing-our-approach-to… ) non risponda ad una domanda semplice come: i vostri utenti possono essere vittima di tutti questi attacchi o no? Ancor prima che preoccupato per gli utenti, sono rimasto SBALORDITO dalla mancanza di professionalità di questi sviluppatori. Comunque per Chromium (aka Google Chrome) non sono da meno: hanno chiuso la issue in meno di 10 minuti: https://bugs.chromium.org/detail?id=879381 visibile se non siete membri del SecurityTeam a https://shamar.github.io/documents/Mozilla-Bug1487081-Attachments/ChromiumB… Si parla tanto di insegnare l'etica delle AI, ma qui abbiamo un enorme problema a monte: riscoprire l'etica delle persone. Giacomo Il 29 agosto 2018 16:11, Stefano Quintarelli <stefano(a)quintarelli.it> ha scritto: > > > On 29/08/2018 16:04, Giacomo Tesio wrote: >> >> Non vorrei essere nei panni dell'imputato. > > > questo vale in generale... > penso che solo chi conosce il penale ha una idea dei modi in cui puoi essere > trascinato tuo malgrado in un procedimento... > > ciao, s.

Aug. 31, 2018

Re: [nexa] Improving DNS Privacy in Firefox

by Stefano Quintarelli

On 30/08/2018 20:16, Stefano Zacchiroli wrote: >> non e' roba da denuncia, in assenza di uno specifico ordine motivato >> dell'autorita' giudiziaria ? > > Hit me. Perché dovrebbe esserlo? Immagino sia un comportamento > documentato (vagamente..., ma tant'è) nelle condizioni del contratto di > accesso a Internet che il provider ti da. O mangi la man-in-the-middle > minestra, oppure salti dalla finestra. Ti prego, stupiscimi, e dimmi che > c'è una legga che renderebbe clausole di quel tipo caduche! credo sia la direttiva 2002/58/EC ma i giuristi possono essere piu' precisi... ciao!, s.

Aug. 30, 2018

Re: [nexa] Improving DNS Privacy in Firefox

by Stefano Zacchiroli

On Thu, Aug 30, 2018 at 03:30:11PM +0200, Stefano Quintarelli wrote: > non sapevo che ci fossero provider che fanno man in the middle sul > DNS. sei certo di cio' ? (il mio non lo fa) Non vivo più in Italia da anni, ma ricordo le reazioni indignate di molti amici geek italiani anni fa, quando Vodafone e altri provider iniziarono a fare cose di questo tipo. > non e' roba da denuncia, in assenza di uno specifico ordine motivato > dell'autorita' giudiziaria ? Hit me. Perché dovrebbe esserlo? Immagino sia un comportamento documentato (vagamente..., ma tant'è) nelle condizioni del contratto di accesso a Internet che il provider ti da. O mangi la man-in-the-middle minestra, oppure salti dalla finestra. Ti prego, stupiscimi, e dimmi che c'è una legga che renderebbe clausole di quel tipo caduche! -- Stefano Zacchiroli . zack(a)upsilon.cc . upsilon.cc/zack . . o . . . o . o Computer Science Professor . CTO Software Heritage . . . . . o . . . o o Former Debian Project Leader & OSI Board Director . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club »

Aug. 30, 2018

Re: [nexa] Improving DNS Privacy in Firefox

by Marco Ciurcina

In data giovedì 30 agosto 2018 16:32:07 CEST, Giacomo Tesio ha scritto: > Oggi però ho finito il tempo. E sono stanco. Esausto. > > https://bugzilla.mozilla.org/show_bug.cgi?id=1487081 > https://lobste.rs/s/vwcetz/undetectable_remote_arbitrary_code > (cachata su > https://shamar.github.io/documents/Mozilla-Bug1487081-Attachments/Undetecta > ble_Remote_Arbitrary_Code_Execution_Attacks_through_JavaScript_and_HTTP_head > ers_trickery__Lobsters.html perché temporaneamente bloccata) Come utente di Firefox, grazie dell'accuratissimo lavoro: mi piacerebbe molto che Firefox implementi delle policy raffinate di gestione del codice JS. Trovo preoccupante che si scriva "It is incorrect to report this as a bug in firefox because this is intended behavior.". m.c.

Aug. 30, 2018

Re: [nexa] Improving DNS Privacy in Firefox

by Alberto Cammozzo

Se ho capito bene Vodafone risponde sempre a tutte le query DNS al posto del server che hai indicato tu: questo lo dimostri indicando dei server DNS inesistenti. E' così? Come dire: il tuo server DNS di preferenza viene ignorato, e risponde sempre V? Se fosse così forse questo viola qualcosa di più di una manciata di RFC... Ciao, A On 30/08/2018 16:15, Simone Basso wrote: > Ciao Stefano, ciao Alberto, > > Segue esempio da Vodafone, che sto appunto usando in questo momento. > Mi trovo a Ventimiglia, IT e sto usando Vodafone (ma avevo verificato > questo stesso comportamento anche a Torino, dove pure ho Vodafone - in > particolare mi si rompevano degli unit test di OONI in locale): > > ``` > ventimiglia$ whois `curl -sq https://ifconfig.io` > [...] > inetnum: 93.70.0.0 - 93.70.255.255 > netname: VODAFONE-IT > ``` > > Eseguo query usando come name server un degli IP di slashdot.org > <http://slashdot.org> > > ``` > ventimiglia$ host www.slashdot.org <http://www.slashdot.org> > www.slashdot.org <http://www.slashdot.org> has address 216.105.38.15 > > ventimiglia$ dig @216.105.38.15 <http://216.105.38.15> www.google.com > <http://www.google.com> > > ; <<>> DiG 9.10.6 <<>> @216.105.38.15 <http://216.105.38.15> > www.google.com <http://www.google.com> > [...] > ;; QUESTION SECTION: > ;www.google.com <http://www.google.com>.INA > > ;; ANSWER SECTION: > www.google.com <http://www.google.com>.274INA216.58.205.132 > > ;; Query time: 49 msec > ;; SERVER: 216.105.38.15#53(216.105.38.15) > ;; WHEN: Thu Aug 30 15:43:48 CEST 2018 > ;; MSG SIZE rcvd: 59 > ``` > > Risposta in 49 ms. Tuttavia quell'indirizzo IP sembra molto piu' > distante dalla mia postazione: > > ``` > > ventimiglia$ ping -c 10 216.105.38.15 > PING 216.105.38.15 (216.105.38.15): 56 data bytes > 64 bytes from 216.105.38.15 <http://216.105.38.15>: icmp_seq=0 ttl=46 > time=242.573 ms > [...] > 64 bytes from 216.105.38.15 <http://216.105.38.15>: icmp_seq=9 ttl=46 > time=432.009 ms > > --- 216.105.38.15 ping statistics --- > 10 packets transmitted, 10 packets received, 0.0% packet loss > round-trip min/avg/max/stddev = 175.887/208.606/432.009/77.035 ms > ``` > > Riprovo a eseguire la stessa query da un server di controllo (una > macchina di build che sta nel cloud di Google): > > ``` > sbs-build-ndt$ dig @216.105.38.15 <http://216.105.38.15> > www.google.com <http://www.google.com> > > ; <<>> DiG 9.10.3-P4-Debian <<>> @216.105.38.15 <http://216.105.38.15> > www.google.com <http://www.google.com> > ; (1 server found) > ;; global options: +cmd > ;; connection timed out; no servers could be reached > ``` > > Questa invece e' una macchina usata da Neubot che si trova in TopIX: > > ``` > topix$ dig @216.105.38.15 <http://216.105.38.15> www.google.com > <http://www.google.com> > > ; <<>> DiG 9.9.5-9+deb8u10-Debian <<>> @216.105.38.15 > <http://216.105.38.15> www.google.com <http://www.google.com> > ; (1 server found) > ;; global options: +cmd > ;; connection timed out; no servers could be reached > ``` > > In OONI mobile abbiamo una implementazione di questo test ma non e' > esposto direttamente all'utente. Se avete OONI per desktop installato > sulla vostra macchina - brew install ooniprobe su macOS altrimenti > vedere https://ooni.torproject.org/install/ - potete eseguire questo > comando: > > ``` > ventimiglia$ ooniprobe dns_injection -r 216.105.38.15 -f FILE > ``` > > Dove FILE e' un file che deve contenere una riga per ogni dominio da > testare (ad esempio www.google.com <http://www.google.com> per > riprodurre il caso di sopra). E dove si puo' omettere "-r > 216.105.38.15" per usare un server DNS non esistente di default. > > AFAICT, una delle ragioni per intercettare le richieste DNS potrebbe > essere che vogliono risolvere "vodafone.station" per permettere a un > utente di accedere al pannello di controllo della Vodafone station > (per quanto ne so - > https://en.wikipedia.org/wiki/List_of_Internet_top-level_domains - > ".station" non sembra un TLD valido). Esempio: > > ``` > ventimiglia$ host vodafone.station > vodafone.station has address 192.168.1.1 > ``` > > Questo ovviamente non funzia da TopIX > > ``` > topix$ host vodafone.station > Host vodafone.station not found: 3(NXDOMAIN) > ``` > > Simone > > > > > Il giorno gio 30 ago 2018 alle ore 15:42 Alberto Cammozzo > <ac+nexa(a)zeromx.net <mailto:ac%2Bnexa@zeromx.net>> ha scritto: > > Io me ne sono accorto anni fa (a occhio e croce 4/5) quando ero > cliente > Vodafone ADSL. > Feci tutte le prove con vari DNS, sia del provider che esterni, e il > risultato era certo. > Aggirato il problema (e abbandonato Vodafone) non ho più > verificato cosa > facciano altri provider. > Il mio traffico DNS non è più visibile al provider. > A > > > On 30/08/2018 15:30, Stefano Quintarelli wrote: > > capito tutto > > > > non sapevo che ci fossero provider che fanno man in the middle > sul DNS. > > sei certo di cio' ? > > (il mio non lo fa) > > > > non e' roba da denuncia, in assenza di uno specifico ordine > motivato > > dell'autorita' giudiziaria ? > > > > ciao, s. > > > > On 30/08/2018 15:24, Alberto Cammozzo wrote: > >> Ciao Stefano, > >> a meno di usare DNsCrypt, DNScurve o altri protocolli DNS > cifrati, i > >> resolver DNS "comuni" non cifrano il payload, per cui i > provider più > >> zelanti (anche in Italia) modificano il traffico anche se nono > sono i > >> loro DNS a rispondere alla query (cioè fanno Deep Packet > Inspectio -- > >> anche se sarebbe più corretto dire che è un attacco Man In The > Middle) > >> Per esempio, se hai configurato come server DNS un server di > Google e > >> chiedi l'indirizzo di Pirate Bay, otterrai 127.0.0.1 o l'indirizzo > >> del banner di censura perché il tuo provider modifica al volo il > >> contenuto del pacchetto e sostituisce l'indirizzo corretto > >> (censurato) con quello "di censura". > >> Il comportamento varia da provider a provider, alcuni non fanno DPI > >> Per evitare la censura serve una cifratura del traffico ce lo > renda > >> inalterabile. > >> Neanche a me piace HTTPS e meno che meno la centralizzazione. I > >> protocolli di cifratura DNS sono complicati. > >> Una soluzione efficace che tecnicamente non è alla portata di > tutti è > >> dirottare tutto (e solo) il traffico DNS su una o più VPN > verso un > >> server DNS proprio (o sicuro). > >> DoH è più facile, anche se condivido le critiche esposte in lista. > >> > >> ciao, > >> Alberto > >> > >> > >> On 30/08/2018 12:16, Stefano Quintarelli wrote: > >>> perche non usare uno qualsiasi degli N (grandissimo) DNS che > ci sono > >>> in giro per il mondo ? (o uno proprio) > >>> > >>> On 30/08/2018 12:12, Simone Basso wrote: > >>>> Ciao Marco, > >>>> > >>>> Il giorno gio 30 ago 2018 alle ore 10:50 Marco Mellia > >>>> <marco.mellia(a)polito.it <mailto:marco.mellia@polito.it> > <mailto:marco.mellia@polito.it <mailto:marco.mellia@polito.it>>> > ha scritto: > >>>> > >>>> Qualcuno mi deve spiegare perché il DNS di cloudflare o di > >>>> Google o > >>>> di Amazon (note no profit organization che non paghiamo) > dovrebbe > >>>> essere più sicuro/veloce/affidabile del DNS del ISP (che > >>>> paghiamo)... > >>>> > >>>> > >>>> Perché ci sono vari stati nel mondo dove usare il DNS che il tuo > >>>> provider ti fornisce significa censura. Questo implica cose come > >>>> essere indirizzati su 127.0.0.1 oppure su una block page che ti > >>>> spiega perché non puoi accedere a un contenuto. > >>>> > >>>> Anche qualora non vi fosse alcun tipo di manipolazione del > DNS, vi > >>>> potrebbe essere sorveglianza, monitorando le query DNS. > >>>> > >>>> Implementando il DNS-over-HTTPS (che è la soluzione descritta > >>>> nell'articolo che è stato postato) si aumenta il costo > richiesto a > >>>> uno stato per continuare a implementare censura e/o > sorveglianza. > >>>> Questo è bene per un individuo, organizzazione, o entità X, se > >>>> negli obiettivi di X c'è aiutare le persone che stanno su > internet > >>>> ad accedere liberamente ai contenuti cui desiderano accedere. > >>>> > >>>> Questo trend per cui tutto passa per i soliti big player > dovrebbe > >>>> fare più paura. Invece tutti a gridare al miracolo perché ci > >>>> propinano un obbrobrio tecnico come la panacea ad un non > >>>> problema... > >>>> > >>>> > >>>> Non sono d'accordo che sia un "non problema". Ci sono aree del > >>>> mondo dove questo probabilmente non è un problema e devo inviare > >>>> più traffico a un ristretto numero di player potrebbe essere un > >>>> problema. E aree del mondo dove questa tecnica è utile per > superare > >>>> la censura. > >>>> > >>>> Bye, > >>>> > >>>> Simone > >>>> > >>>> > >>>> My 2c > >>>> M > >>>> > >>>> > >>>> Inviato da iPad > >>>> > >>>> > Il giorno 29 ago 2018, alle ore 21:24, > >>>> nexa-request(a)server-nexa.polito.it > <mailto:nexa-request@server-nexa.polito.it> > >>>> <mailto:nexa-request@server-nexa.polito.it > <mailto:nexa-request@server-nexa.polito.it>> ha scritto: > >>>> > > >>>> > Questo dovrebbe essere dirompente per molti degli > schemi di > >>>> censura in > >>>> > Italia, basati su DNS DPI > >>>> > > >>>> > > >>>> > <https://blog.nightly.mozilla.org/2018/06/01/improving-dns-privacy-in-firefo…> > > >>>> > >>>> > > >>>> > Domain Name Service (DNS) is one of the oldest parts of > >>>> internet > >>>> > architecture, and remains one that has largely been > >>>> untouched by > >>>> efforts > >>>> > to make the web safer and more private. On the Firefox > >>>> network and > >>>> > security teams, we’re working to change that by > encrypting DNS > >>>> queries > >>>> > and by testing a service that keeps DNS providers from > >>>> collecting > >>>> and > >>>> > sharing your browsing history. > >>>> > >>>> _______________________________________________ > >>>> nexa mailing list > >>>> nexa(a)server-nexa.polito.it > <mailto:nexa@server-nexa.polito.it> > <mailto:nexa@server-nexa.polito.it > <mailto:nexa@server-nexa.polito.it>> > >>>> https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> nexa mailing list > >>>> nexa(a)server-nexa.polito.it <mailto:nexa@server-nexa.polito.it> > >>>> https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa > >>>> > >>> _______________________________________________ > >>> nexa mailing list > >>> nexa(a)server-nexa.polito.it <mailto:nexa@server-nexa.polito.it> > >>> https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa > >> > >> > >> _______________________________________________ > >> nexa mailing list > >> nexa(a)server-nexa.polito.it <mailto:nexa@server-nexa.polito.it> > >> https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa > > > _______________________________________________ > nexa mailing list > nexa(a)server-nexa.polito.it <mailto:nexa@server-nexa.polito.it> > https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa > > > > _______________________________________________ > nexa mailing list > nexa(a)server-nexa.polito.it > https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa

Aug. 30, 2018

Re: [nexa] Improving DNS Privacy in Firefox

by Giacomo Tesio

Il punto con il DoH è se sia più una soluzione o più un nuovo problema. Potrei scrivere un bel po' sui possibili attacchi. E anche quanto a censura, non cambia nulla. Il tuo ISP può comunque bloccare l'IP, sia di PirateBay che di CloudFlare. O effettuare il NAT verso un sito ad hoc. E per la stessa ragione, il tuo ISP sa esattamente quali IP contatti, su quali porte (dunque che servizi usi di quei server). Un bell'articolo a proposito dell'HTTPS per il contrasto alla censura è stato pubblicato dal Internet Monitor del Berkman Klein Center: https://medium.com/berkman-klein-center/the-uncertain-effects-of-https-adop… Oggi però ho finito il tempo. E sono stanco. Esausto. https://bugzilla.mozilla.org/show_bug.cgi?id=1487081 https://lobste.rs/s/vwcetz/undetectable_remote_arbitrary_code (cachata su https://shamar.github.io/documents/Mozilla-Bug1487081-Attachments/Undetecta… perché temporaneamente bloccata) Non so più se si tratti di mala fede o incompetenza degli "esperti". Ma sono entrambe molto pericolose. Giacomo Il 30 agosto 2018 16:15, Simone Basso <bassosimone(a)gmail.com> ha scritto: > Ciao Stefano, ciao Alberto, > > Segue esempio da Vodafone, che sto appunto usando in questo momento. Mi > trovo a Ventimiglia, IT e sto usando Vodafone (ma avevo verificato questo > stesso comportamento anche a Torino, dove pure ho Vodafone - in particolare > mi si rompevano degli unit test di OONI in locale): > > ``` > ventimiglia$ whois `curl -sq https://ifconfig.io` > [...] > inetnum: 93.70.0.0 - 93.70.255.255 > netname: VODAFONE-IT > ``` > > Eseguo query usando come name server un degli IP di slashdot.org > > ``` > ventimiglia$ host www.slashdot.org > www.slashdot.org has address 216.105.38.15 > > ventimiglia$ dig @216.105.38.15 www.google.com > > ; <<>> DiG 9.10.6 <<>> @216.105.38.15 www.google.com > [...] > ;; QUESTION SECTION: > ;www.google.com. IN A > > ;; ANSWER SECTION: > www.google.com. 274 IN A 216.58.205.132 > > ;; Query time: 49 msec > ;; SERVER: 216.105.38.15#53(216.105.38.15) > ;; WHEN: Thu Aug 30 15:43:48 CEST 2018 > ;; MSG SIZE rcvd: 59 > ``` > > Risposta in 49 ms. Tuttavia quell'indirizzo IP sembra molto piu' distante > dalla mia postazione: > > ``` > > ventimiglia$ ping -c 10 216.105.38.15 > PING 216.105.38.15 (216.105.38.15): 56 data bytes > 64 bytes from 216.105.38.15: icmp_seq=0 ttl=46 time=242.573 ms > [...] > 64 bytes from 216.105.38.15: icmp_seq=9 ttl=46 time=432.009 ms > > --- 216.105.38.15 ping statistics --- > 10 packets transmitted, 10 packets received, 0.0% packet loss > round-trip min/avg/max/stddev = 175.887/208.606/432.009/77.035 ms > ``` > > Riprovo a eseguire la stessa query da un server di controllo (una macchina > di build che sta nel cloud di Google): > > ``` > sbs-build-ndt$ dig @216.105.38.15 www.google.com > > ; <<>> DiG 9.10.3-P4-Debian <<>> @216.105.38.15 www.google.com > ; (1 server found) > ;; global options: +cmd > ;; connection timed out; no servers could be reached > ``` > > Questa invece e' una macchina usata da Neubot che si trova in TopIX: > > ``` > topix$ dig @216.105.38.15 www.google.com > > ; <<>> DiG 9.9.5-9+deb8u10-Debian <<>> @216.105.38.15 www.google.com > ; (1 server found) > ;; global options: +cmd > ;; connection timed out; no servers could be reached > ``` > > In OONI mobile abbiamo una implementazione di questo test ma non e' esposto > direttamente all'utente. Se avete OONI per desktop installato sulla vostra > macchina - brew install ooniprobe su macOS altrimenti vedere > https://ooni.torproject.org/install/ - potete eseguire questo comando: > > ``` > ventimiglia$ ooniprobe dns_injection -r 216.105.38.15 -f FILE > ``` > > Dove FILE e' un file che deve contenere una riga per ogni dominio da testare > (ad esempio www.google.com per riprodurre il caso di sopra). E dove si puo' > omettere "-r 216.105.38.15" per usare un server DNS non esistente di > default. > > AFAICT, una delle ragioni per intercettare le richieste DNS potrebbe essere > che vogliono risolvere "vodafone.station" per permettere a un utente di > accedere al pannello di controllo della Vodafone station (per quanto ne so - > https://en.wikipedia.org/wiki/List_of_Internet_top-level_domains - > ".station" non sembra un TLD valido). Esempio: > > ``` > ventimiglia$ host vodafone.station > vodafone.station has address 192.168.1.1 > ``` > > Questo ovviamente non funzia da TopIX > > ``` > topix$ host vodafone.station > Host vodafone.station not found: 3(NXDOMAIN) > ``` > > Simone > > > > > Il giorno gio 30 ago 2018 alle ore 15:42 Alberto Cammozzo > <ac+nexa(a)zeromx.net> ha scritto: >> >> Io me ne sono accorto anni fa (a occhio e croce 4/5) quando ero cliente >> Vodafone ADSL. >> Feci tutte le prove con vari DNS, sia del provider che esterni, e il >> risultato era certo. >> Aggirato il problema (e abbandonato Vodafone) non ho più verificato cosa >> facciano altri provider. >> Il mio traffico DNS non è più visibile al provider. >> A >> >> >> On 30/08/2018 15:30, Stefano Quintarelli wrote: >> > capito tutto >> > >> > non sapevo che ci fossero provider che fanno man in the middle sul DNS. >> > sei certo di cio' ? >> > (il mio non lo fa) >> > >> > non e' roba da denuncia, in assenza di uno specifico ordine motivato >> > dell'autorita' giudiziaria ? >> > >> > ciao, s. >> > >> > On 30/08/2018 15:24, Alberto Cammozzo wrote: >> >> Ciao Stefano, >> >> a meno di usare DNsCrypt, DNScurve o altri protocolli DNS cifrati, i >> >> resolver DNS "comuni" non cifrano il payload, per cui i provider più >> >> zelanti (anche in Italia) modificano il traffico anche se nono sono i >> >> loro DNS a rispondere alla query (cioè fanno Deep Packet Inspectio -- >> >> anche se sarebbe più corretto dire che è un attacco Man In The Middle) >> >> Per esempio, se hai configurato come server DNS un server di Google e >> >> chiedi l'indirizzo di Pirate Bay, otterrai 127.0.0.1 o l'indirizzo >> >> del banner di censura perché il tuo provider modifica al volo il >> >> contenuto del pacchetto e sostituisce l'indirizzo corretto >> >> (censurato) con quello "di censura". >> >> Il comportamento varia da provider a provider, alcuni non fanno DPI >> >> Per evitare la censura serve una cifratura del traffico ce lo renda >> >> inalterabile. >> >> Neanche a me piace HTTPS e meno che meno la centralizzazione. I >> >> protocolli di cifratura DNS sono complicati. >> >> Una soluzione efficace che tecnicamente non è alla portata di tutti è >> >> dirottare tutto (e solo) il traffico DNS su una o più VPN verso un >> >> server DNS proprio (o sicuro). >> >> DoH è più facile, anche se condivido le critiche esposte in lista. >> >> >> >> ciao, >> >> Alberto >> >> >> >> >> >> On 30/08/2018 12:16, Stefano Quintarelli wrote: >> >>> perche non usare uno qualsiasi degli N (grandissimo) DNS che ci sono >> >>> in giro per il mondo ? (o uno proprio) >> >>> >> >>> On 30/08/2018 12:12, Simone Basso wrote: >> >>>> Ciao Marco, >> >>>> >> >>>> Il giorno gio 30 ago 2018 alle ore 10:50 Marco Mellia >> >>>> <marco.mellia(a)polito.it <mailto:marco.mellia@polito.it>> ha scritto: >> >>>> >> >>>> Qualcuno mi deve spiegare perché il DNS di cloudflare o di >> >>>> Google o >> >>>> di Amazon (note no profit organization che non paghiamo) dovrebbe >> >>>> essere più sicuro/veloce/affidabile del DNS del ISP (che >> >>>> paghiamo)... >> >>>> >> >>>> >> >>>> Perché ci sono vari stati nel mondo dove usare il DNS che il tuo >> >>>> provider ti fornisce significa censura. Questo implica cose come >> >>>> essere indirizzati su 127.0.0.1 oppure su una block page che ti >> >>>> spiega perché non puoi accedere a un contenuto. >> >>>> >> >>>> Anche qualora non vi fosse alcun tipo di manipolazione del DNS, vi >> >>>> potrebbe essere sorveglianza, monitorando le query DNS. >> >>>> >> >>>> Implementando il DNS-over-HTTPS (che è la soluzione descritta >> >>>> nell'articolo che è stato postato) si aumenta il costo richiesto a >> >>>> uno stato per continuare a implementare censura e/o sorveglianza. >> >>>> Questo è bene per un individuo, organizzazione, o entità X, se >> >>>> negli obiettivi di X c'è aiutare le persone che stanno su internet >> >>>> ad accedere liberamente ai contenuti cui desiderano accedere. >> >>>> >> >>>> Questo trend per cui tutto passa per i soliti big player dovrebbe >> >>>> fare più paura. Invece tutti a gridare al miracolo perché ci >> >>>> propinano un obbrobrio tecnico come la panacea ad un non >> >>>> problema... >> >>>> >> >>>> >> >>>> Non sono d'accordo che sia un "non problema". Ci sono aree del >> >>>> mondo dove questo probabilmente non è un problema e devo inviare >> >>>> più traffico a un ristretto numero di player potrebbe essere un >> >>>> problema. E aree del mondo dove questa tecnica è utile per superare >> >>>> la censura. >> >>>> >> >>>> Bye, >> >>>> >> >>>> Simone >> >>>> >> >>>> >> >>>> My 2c >> >>>> M >> >>>> >> >>>> >> >>>> Inviato da iPad >> >>>> >> >>>> > Il giorno 29 ago 2018, alle ore 21:24, >> >>>> nexa-request(a)server-nexa.polito.it >> >>>> <mailto:nexa-request@server-nexa.polito.it> ha scritto: >> >>>> > >> >>>> > Questo dovrebbe essere dirompente per molti degli schemi di >> >>>> censura in >> >>>> > Italia, basati su DNS DPI >> >>>> > >> >>>> > >> >>>> >> >>>> <https://blog.nightly.mozilla.org/2018/06/01/improving-dns-privacy-in-firefo…> >> >>>> >> >>>> > >> >>>> > Domain Name Service (DNS) is one of the oldest parts of >> >>>> internet >> >>>> > architecture, and remains one that has largely been >> >>>> untouched by >> >>>> efforts >> >>>> > to make the web safer and more private. On the Firefox >> >>>> network and >> >>>> > security teams, we’re working to change that by encrypting DNS >> >>>> queries >> >>>> > and by testing a service that keeps DNS providers from >> >>>> collecting >> >>>> and >> >>>> > sharing your browsing history. >> >>>> >> >>>> _______________________________________________ >> >>>> nexa mailing list >> >>>> nexa(a)server-nexa.polito.it <mailto:nexa@server-nexa.polito.it> >> >>>> https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa >> >>>> >> >>>> >> >>>> >> >>>> _______________________________________________ >> >>>> nexa mailing list >> >>>> nexa(a)server-nexa.polito.it >> >>>> https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa >> >>>> >> >>> _______________________________________________ >> >>> nexa mailing list >> >>> nexa(a)server-nexa.polito.it >> >>> https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa >> >> >> >> >> >> _______________________________________________ >> >> nexa mailing list >> >> nexa(a)server-nexa.polito.it >> >> https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa >> >> >> _______________________________________________ >> nexa mailing list >> nexa(a)server-nexa.polito.it >> https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa > > > _______________________________________________ > nexa mailing list > nexa(a)server-nexa.polito.it > https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa >

Aug. 30, 2018

Re: [nexa] Improving DNS Privacy in Firefox

by Simone Basso

Ciao Stefano, ciao Alberto, Segue esempio da Vodafone, che sto appunto usando in questo momento. Mi trovo a Ventimiglia, IT e sto usando Vodafone (ma avevo verificato questo stesso comportamento anche a Torino, dove pure ho Vodafone - in particolare mi si rompevano degli unit test di OONI in locale): ``` ventimiglia$ whois `curl -sq https://ifconfig.io` [...] inetnum: 93.70.0.0 - 93.70.255.255 netname: VODAFONE-IT ``` Eseguo query usando come name server un degli IP di slashdot.org ``` ventimiglia$ host www.slashdot.org www.slashdot.org has address 216.105.38.15 ventimiglia$ dig @216.105.38.15 www.google.com ; <<>> DiG 9.10.6 <<>> @216.105.38.15 www.google.com [...] ;; QUESTION SECTION: ;www.google.com. IN A ;; ANSWER SECTION: www.google.com. 274 IN A 216.58.205.132 ;; Query time: 49 msec ;; SERVER: 216.105.38.15#53(216.105.38.15) ;; WHEN: Thu Aug 30 15:43:48 CEST 2018 ;; MSG SIZE rcvd: 59 ``` Risposta in 49 ms. Tuttavia quell'indirizzo IP sembra molto piu' distante dalla mia postazione: ``` ventimiglia$ ping -c 10 216.105.38.15 PING 216.105.38.15 (216.105.38.15): 56 data bytes 64 bytes from 216.105.38.15: icmp_seq=0 ttl=46 time=242.573 ms [...] 64 bytes from 216.105.38.15: icmp_seq=9 ttl=46 time=432.009 ms --- 216.105.38.15 ping statistics --- 10 packets transmitted, 10 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 175.887/208.606/432.009/77.035 ms ``` Riprovo a eseguire la stessa query da un server di controllo (una macchina di build che sta nel cloud di Google): ``` sbs-build-ndt$ dig @216.105.38.15 www.google.com ; <<>> DiG 9.10.3-P4-Debian <<>> @216.105.38.15 www.google.com ; (1 server found) ;; global options: +cmd ;; connection timed out; no servers could be reached ``` Questa invece e' una macchina usata da Neubot che si trova in TopIX: ``` topix$ dig @216.105.38.15 www.google.com ; <<>> DiG 9.9.5-9+deb8u10-Debian <<>> @216.105.38.15 www.google.com ; (1 server found) ;; global options: +cmd ;; connection timed out; no servers could be reached ``` In OONI mobile abbiamo una implementazione di questo test ma non e' esposto direttamente all'utente. Se avete OONI per desktop installato sulla vostra macchina - brew install ooniprobe su macOS altrimenti vedere https://ooni.torproject.org/install/ - potete eseguire questo comando: ``` ventimiglia$ ooniprobe dns_injection -r 216.105.38.15 -f FILE ``` Dove FILE e' un file che deve contenere una riga per ogni dominio da testare (ad esempio www.google.com per riprodurre il caso di sopra). E dove si puo' omettere "-r 216.105.38.15" per usare un server DNS non esistente di default. AFAICT, una delle ragioni per intercettare le richieste DNS potrebbe essere che vogliono risolvere "vodafone.station" per permettere a un utente di accedere al pannello di controllo della Vodafone station (per quanto ne so - https://en.wikipedia.org/wiki/List_of_Internet_top-level_domains - ".station" non sembra un TLD valido). Esempio: ``` ventimiglia$ host vodafone.station vodafone.station has address 192.168.1.1 ``` Questo ovviamente non funzia da TopIX ``` topix$ host vodafone.station Host vodafone.station not found: 3(NXDOMAIN) ``` Simone Il giorno gio 30 ago 2018 alle ore 15:42 Alberto Cammozzo < ac+nexa(a)zeromx.net> ha scritto: > Io me ne sono accorto anni fa (a occhio e croce 4/5) quando ero cliente > Vodafone ADSL. > Feci tutte le prove con vari DNS, sia del provider che esterni, e il > risultato era certo. > Aggirato il problema (e abbandonato Vodafone) non ho più verificato cosa > facciano altri provider. > Il mio traffico DNS non è più visibile al provider. > A > > > On 30/08/2018 15:30, Stefano Quintarelli wrote: > > capito tutto > > > > non sapevo che ci fossero provider che fanno man in the middle sul DNS. > > sei certo di cio' ? > > (il mio non lo fa) > > > > non e' roba da denuncia, in assenza di uno specifico ordine motivato > > dell'autorita' giudiziaria ? > > > > ciao, s. > > > > On 30/08/2018 15:24, Alberto Cammozzo wrote: > >> Ciao Stefano, > >> a meno di usare DNsCrypt, DNScurve o altri protocolli DNS cifrati, i > >> resolver DNS "comuni" non cifrano il payload, per cui i provider più > >> zelanti (anche in Italia) modificano il traffico anche se nono sono i > >> loro DNS a rispondere alla query (cioè fanno Deep Packet Inspectio -- > >> anche se sarebbe più corretto dire che è un attacco Man In The Middle) > >> Per esempio, se hai configurato come server DNS un server di Google e > >> chiedi l'indirizzo di Pirate Bay, otterrai 127.0.0.1 o l'indirizzo > >> del banner di censura perché il tuo provider modifica al volo il > >> contenuto del pacchetto e sostituisce l'indirizzo corretto > >> (censurato) con quello "di censura". > >> Il comportamento varia da provider a provider, alcuni non fanno DPI > >> Per evitare la censura serve una cifratura del traffico ce lo renda > >> inalterabile. > >> Neanche a me piace HTTPS e meno che meno la centralizzazione. I > >> protocolli di cifratura DNS sono complicati. > >> Una soluzione efficace che tecnicamente non è alla portata di tutti è > >> dirottare tutto (e solo) il traffico DNS su una o più VPN verso un > >> server DNS proprio (o sicuro). > >> DoH è più facile, anche se condivido le critiche esposte in lista. > >> > >> ciao, > >> Alberto > >> > >> > >> On 30/08/2018 12:16, Stefano Quintarelli wrote: > >>> perche non usare uno qualsiasi degli N (grandissimo) DNS che ci sono > >>> in giro per il mondo ? (o uno proprio) > >>> > >>> On 30/08/2018 12:12, Simone Basso wrote: > >>>> Ciao Marco, > >>>> > >>>> Il giorno gio 30 ago 2018 alle ore 10:50 Marco Mellia > >>>> <marco.mellia(a)polito.it <mailto:marco.mellia@polito.it>> ha scritto: > >>>> > >>>> Qualcuno mi deve spiegare perché il DNS di cloudflare o di > >>>> Google o > >>>> di Amazon (note no profit organization che non paghiamo) dovrebbe > >>>> essere più sicuro/veloce/affidabile del DNS del ISP (che > >>>> paghiamo)... > >>>> > >>>> > >>>> Perché ci sono vari stati nel mondo dove usare il DNS che il tuo > >>>> provider ti fornisce significa censura. Questo implica cose come > >>>> essere indirizzati su 127.0.0.1 oppure su una block page che ti > >>>> spiega perché non puoi accedere a un contenuto. > >>>> > >>>> Anche qualora non vi fosse alcun tipo di manipolazione del DNS, vi > >>>> potrebbe essere sorveglianza, monitorando le query DNS. > >>>> > >>>> Implementando il DNS-over-HTTPS (che è la soluzione descritta > >>>> nell'articolo che è stato postato) si aumenta il costo richiesto a > >>>> uno stato per continuare a implementare censura e/o sorveglianza. > >>>> Questo è bene per un individuo, organizzazione, o entità X, se > >>>> negli obiettivi di X c'è aiutare le persone che stanno su internet > >>>> ad accedere liberamente ai contenuti cui desiderano accedere. > >>>> > >>>> Questo trend per cui tutto passa per i soliti big player dovrebbe > >>>> fare più paura. Invece tutti a gridare al miracolo perché ci > >>>> propinano un obbrobrio tecnico come la panacea ad un non > >>>> problema... > >>>> > >>>> > >>>> Non sono d'accordo che sia un "non problema". Ci sono aree del > >>>> mondo dove questo probabilmente non è un problema e devo inviare > >>>> più traffico a un ristretto numero di player potrebbe essere un > >>>> problema. E aree del mondo dove questa tecnica è utile per superare > >>>> la censura. > >>>> > >>>> Bye, > >>>> > >>>> Simone > >>>> > >>>> > >>>> My 2c > >>>> M > >>>> > >>>> > >>>> Inviato da iPad > >>>> > >>>> > Il giorno 29 ago 2018, alle ore 21:24, > >>>> nexa-request(a)server-nexa.polito.it > >>>> <mailto:nexa-request@server-nexa.polito.it> ha scritto: > >>>> > > >>>> > Questo dovrebbe essere dirompente per molti degli schemi di > >>>> censura in > >>>> > Italia, basati su DNS DPI > >>>> > > >>>> > > >>>> < > https://blog.nightly.mozilla.org/2018/06/01/improving-dns-privacy-in-firefo…> > > >>>> > >>>> > > >>>> > Domain Name Service (DNS) is one of the oldest parts of > >>>> internet > >>>> > architecture, and remains one that has largely been > >>>> untouched by > >>>> efforts > >>>> > to make the web safer and more private. On the Firefox > >>>> network and > >>>> > security teams, we’re working to change that by encrypting DNS > >>>> queries > >>>> > and by testing a service that keeps DNS providers from > >>>> collecting > >>>> and > >>>> > sharing your browsing history. > >>>> > >>>> _______________________________________________ > >>>> nexa mailing list > >>>> nexa(a)server-nexa.polito.it <mailto:nexa@server-nexa.polito.it> > >>>> https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> nexa mailing list > >>>> nexa(a)server-nexa.polito.it > >>>> https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa > >>>> > >>> _______________________________________________ > >>> nexa mailing list > >>> nexa(a)server-nexa.polito.it > >>> https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa > >> > >> > >> _______________________________________________ > >> nexa mailing list > >> nexa(a)server-nexa.polito.it > >> https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa > > > _______________________________________________ > nexa mailing list > nexa(a)server-nexa.polito.it > https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa >

Aug. 30, 2018

Re: [nexa] Improving DNS Privacy in Firefox

by Alberto Cammozzo

Io me ne sono accorto anni fa (a occhio e croce 4/5) quando ero cliente Vodafone ADSL. Feci tutte le prove con vari DNS, sia del provider che esterni, e il risultato era certo. Aggirato il problema (e abbandonato Vodafone) non ho più verificato cosa facciano altri provider. Il mio traffico DNS non è più visibile al provider. A On 30/08/2018 15:30, Stefano Quintarelli wrote: > capito tutto > > non sapevo che ci fossero provider che fanno man in the middle sul DNS. > sei certo di cio' ? > (il mio non lo fa) > > non e' roba da denuncia, in assenza di uno specifico ordine motivato > dell'autorita' giudiziaria ? > > ciao, s. > > On 30/08/2018 15:24, Alberto Cammozzo wrote: >> Ciao Stefano, >> a meno di usare DNsCrypt, DNScurve o altri protocolli DNS cifrati, i >> resolver DNS "comuni" non cifrano il payload, per cui i provider più >> zelanti (anche in Italia) modificano il traffico anche se nono sono i >> loro DNS a rispondere alla query (cioè fanno Deep Packet Inspectio -- >> anche se sarebbe più corretto dire che è un attacco Man In The Middle) >> Per esempio, se hai configurato come server DNS un server di Google e >> chiedi l'indirizzo di Pirate Bay, otterrai 127.0.0.1 o l'indirizzo >> del banner di censura perché il tuo provider modifica al volo il >> contenuto del pacchetto e sostituisce l'indirizzo corretto >> (censurato) con quello "di censura". >> Il comportamento varia da provider a provider, alcuni non fanno DPI >> Per evitare la censura serve una cifratura del traffico ce lo renda >> inalterabile. >> Neanche a me piace HTTPS e meno che meno la centralizzazione. I >> protocolli di cifratura DNS sono complicati. >> Una soluzione efficace che tecnicamente non è alla portata di tutti è >> dirottare tutto (e solo) il traffico DNS su una o più VPN verso un >> server DNS proprio (o sicuro). >> DoH è più facile, anche se condivido le critiche esposte in lista. >> >> ciao, >> Alberto >> >> >> On 30/08/2018 12:16, Stefano Quintarelli wrote: >>> perche non usare uno qualsiasi degli N (grandissimo) DNS che ci sono >>> in giro per il mondo ? (o uno proprio) >>> >>> On 30/08/2018 12:12, Simone Basso wrote: >>>> Ciao Marco, >>>> >>>> Il giorno gio 30 ago 2018 alle ore 10:50 Marco Mellia >>>> <marco.mellia(a)polito.it <mailto:marco.mellia@polito.it>> ha scritto: >>>> >>>> Qualcuno mi deve spiegare perché il DNS di cloudflare o di >>>> Google o >>>> di Amazon (note no profit organization che non paghiamo) dovrebbe >>>> essere più sicuro/veloce/affidabile del DNS del ISP (che >>>> paghiamo)... >>>> >>>> >>>> Perché ci sono vari stati nel mondo dove usare il DNS che il tuo >>>> provider ti fornisce significa censura. Questo implica cose come >>>> essere indirizzati su 127.0.0.1 oppure su una block page che ti >>>> spiega perché non puoi accedere a un contenuto. >>>> >>>> Anche qualora non vi fosse alcun tipo di manipolazione del DNS, vi >>>> potrebbe essere sorveglianza, monitorando le query DNS. >>>> >>>> Implementando il DNS-over-HTTPS (che è la soluzione descritta >>>> nell'articolo che è stato postato) si aumenta il costo richiesto a >>>> uno stato per continuare a implementare censura e/o sorveglianza. >>>> Questo è bene per un individuo, organizzazione, o entità X, se >>>> negli obiettivi di X c'è aiutare le persone che stanno su internet >>>> ad accedere liberamente ai contenuti cui desiderano accedere. >>>> >>>> Questo trend per cui tutto passa per i soliti big player dovrebbe >>>> fare più paura. Invece tutti a gridare al miracolo perché ci >>>> propinano un obbrobrio tecnico come la panacea ad un non >>>> problema... >>>> >>>> >>>> Non sono d'accordo che sia un "non problema". Ci sono aree del >>>> mondo dove questo probabilmente non è un problema e devo inviare >>>> più traffico a un ristretto numero di player potrebbe essere un >>>> problema. E aree del mondo dove questa tecnica è utile per superare >>>> la censura. >>>> >>>> Bye, >>>> >>>> Simone >>>> >>>> >>>> My 2c >>>> M >>>> >>>> >>>> Inviato da iPad >>>> >>>> > Il giorno 29 ago 2018, alle ore 21:24, >>>> nexa-request(a)server-nexa.polito.it >>>> <mailto:nexa-request@server-nexa.polito.it> ha scritto: >>>> > >>>> > Questo dovrebbe essere dirompente per molti degli schemi di >>>> censura in >>>> > Italia, basati su DNS DPI >>>> > >>>> > >>>> <https://blog.nightly.mozilla.org/2018/06/01/improving-dns-privacy-in-firefo…> >>>> >>>> > >>>> > Domain Name Service (DNS) is one of the oldest parts of >>>> internet >>>> > architecture, and remains one that has largely been >>>> untouched by >>>> efforts >>>> > to make the web safer and more private. On the Firefox >>>> network and >>>> > security teams, we’re working to change that by encrypting DNS >>>> queries >>>> > and by testing a service that keeps DNS providers from >>>> collecting >>>> and >>>> > sharing your browsing history. >>>> >>>> _______________________________________________ >>>> nexa mailing list >>>> nexa(a)server-nexa.polito.it <mailto:nexa@server-nexa.polito.it> >>>> https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa >>>> >>>> >>>> >>>> _______________________________________________ >>>> nexa mailing list >>>> nexa(a)server-nexa.polito.it >>>> https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa >>>> >>> _______________________________________________ >>> nexa mailing list >>> nexa(a)server-nexa.polito.it >>> https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa >> >> >> _______________________________________________ >> nexa mailing list >> nexa(a)server-nexa.polito.it >> https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa

Aug. 30, 2018

Fwd: Copyright: il movimento EUROPE FOR CREATORS a favore della Direttiva

by Masera Anna

Le lobby affilano le armi, vi inoltro per conoscenza questo comunicato fresco fresco che ho appena ricevuto. Chi sa quante probabilità ci siano che la direttiva Ue passi invariata, senza la revisione auspicata degli articoli 11 e 13? Anna Inviato da iPhone Inizio messaggio inoltrato: Da: "Sicolo, Davide" <Davide.Sicolo(a)edelman.com<mailto:Davide.Sicolo@edelman.com>> Data: 30 agosto 2018 15:19:49 CEST A: "anna.masera(a)lastampa.it<mailto:anna.masera@lastampa.it>" <anna.masera(a)lastampa.it<mailto:anna.masera@lastampa.it>> Oggetto: Copyright: al via il movimento EUROPE FOR CREATORS a favore della Direttiva Gentile Anna buongiorno. Le invio qui di seguito il comunicato stampa relativo al lancio della campagna EUROPE FOR CREATORS a sostegno della Direttiva Europea sul Copyright. Il movimento è promosso da GESAC, organizzazione che raccoglie oltre 12 milioni di creativi e autori in Europa e che vuole sensibilizzare cittadini e organizzazioni e parlamentari EU. Siamo a disposizione per eventuali informazioni. Grazie EUROPE FOR CREATOR lancia la campagna a sostegno della Direttiva UE sul Copyright Il nuovo movimento invita tutti i cittadini a preservare la cultura e la democrazia in Europa Parigi, 30 Agosto, 2018 – EUROPE FOR CREATORS, un gruppo di cittadini, creativi e quasi 250 organizzazioni a sostegno della Direttiva Europea per il copyright, lancia oggi un movimento di ampio respiro, per invitare i cittadini e i decision maker a partecipare al dibattito e a far sentire la propria voce. Questa campagna cerca di correggere la disinformazione spiegando l'importanza e i motivi che sono alla base di un voto a favore della Direttiva UE sul diritto d'autore che avrà luogo il 12 settembre. Informare e mobilitare i sostenitori per colmare il cosiddetto “value gap” Contro una campagna propagandistica creata ad hoc e una massiccia azione di lobby, è necessario con urgenza fare chiarezza in maniera approfondita. L'articolo 13 della Direttiva Europea richiederà alle piattaforme online di negoziare accordi di licenza equi con i titolari dei diritti d'autore. Questo è il vero problema che molti giganti della tecnologia come Google e Facebook vogliono nascondere. "Le potenze economiche digitali continuano a trarre profitto mentre gli artisti lottano per arrivare a fine mese. L'equilibrio tra i ricavi generati dalle piattaforme di Internet e il denaro che queste danno ai creatori, responsabili del loro successo, è completamente sbilanciato", ha dichiarato Véronique Desbrosses, direttore generale dell’European Grouping of Societies of Authors and Composers (GESAC). Quali sono le principali problematiche? 1. Creatività. Mentre il dibattito attuale si è concentrato sui "meme" e sulle "Gif", queste forme di espressione creativa sono già protette dalla legislazione esistente<https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32001L0029&f…> e non saranno interessate dalla nuova Direttiva. 2. Trasparenza. Gli accordi di remunerazione che le piattaforme Internet hanno raggiunto con i creatori di contenuti sono poco trasparenti. Queste piattaforme, infatti, non rendono pubblici i dati rispetto a questo aspetto della loro attività e gli accordi raggiunti con i titolari dei diritti d'autore sono siglati da accordi di riservatezza. La trasparenza diventerebbe fondamentale ai sensi della Direttiva. 1. Parità di trattamento. Le piattaforme di Internet gratuite hanno tratto vantaggio dalla mancanza di chiarezza legislativa. Servizi online simili non hanno gli stessi obblighi. Quello che è evidente, tuttavia, è che le piattaforme di streaming gratuito retribuiscono i propri creatori di contenuti 10 volte meno rispetto all’abbonamento pagato dai propri utenti. "L'industria creativa e della cultura nell'Unione Europea vale 536 miliardi di euro all'anno, più della somma del fatturato prodotto dal settore dell’automotive e delle telecomunicazioni e offre lavoro a 12 milioni di persone. Abbiamo arricchito la vita degli europei e ora stiamo chiedendo all'Europa un’azione concreta" ha aggiunto Desbrosses. Lancio di EUROPE FOR CREATORS Quello di oggi è solo il primo passo di una mobilitazione di massa a sostegno della Direttiva. Nelle prossime settimane questo gruppo unirà organizzazioni e sostenitori così come motiverà anche i cittadini di tutta Europa per coinvolgere gli Eurodeputati nella lotta per i diritti di tutti i creatori di contenuti. Le prime azioni comprenderanno: * Una lettera aperta che sarà inviata a tutti i membri del Parlamento Europeo per coinvolgerli in questo movimento. * Dibattiti che saranno organizzati in tutta Europa il 5 settembre dalla categoria degli autori e da altri attori, per fornire informazioni più specifiche ai cittadini, agli artisti e ai creatori di contenuti. Tali discussioni coincideranno con la pubblicazione del nuovo testo della Direttiva. * Eventi di grande impatto che si svolgeranno nelle principali città europee prima del voto del 12 settembre. EUROPE FOR CREATORS ha lanciato un sito web e un account su Twitter dedicati per condividere informazioni sulla Direttiva e incoraggiare i sostenitori a diffonderle. Per saperne di più su EUROPE FOR CREATORS è possibile visitare il sito www.europeforcreators.eu<https://www.europeforcreators.eu/> o seguire la conversazione sull’account Twitter @EUForCreators attraverso #EuropeForCreators. Informazioni su EUROPE FOR CREATORS EUROPE FOR CREATORS riunisce cittadini, creativi e organizzazioni impegnati nel sostegno della Direttiva sul diritto d'autore. Rappresentiamo a livello europeo creatori di contenuti e titolari dei diritti, compresi autori, compositori, musicisti, cantanti, pittori, scultori, registi, produttori, giornalisti, scrittori, ricercatori e accademici, pari a 12 milioni di posti di lavoro legati all'industria creativa. Davide Andrea Sicolo • Senior Vice President • Edelman Italy Via Varese 11, Milano 20121, Italia t: +39 02 63116.1| m: +39 347 6712149 | w: www.edelman.it<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.edelman…> | [cid:image001.png@01D01491.400D20C0] @edelmanitalia<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.co…> In compliance with GDPR, we updated our privacy policy. It's available on our site edelman.it<http://edelman.it> Edelman is a leading global communications marketing firm helping business and organisations evolve, promote and protect their brands and reputations. Digital Consultancies of the Year (2017 EMEA Sabre Award) - Contagious Pioneer (2017) - Best Storytelling (2016 Assorel) - Best Media Relations (2016 Bulldog Award) - PR Agency of the Year (2016 Global Sabre Award) ________________________________ Il presente messaggio (inclusi gli allegati) contiene informazioni riservate esclusivamente al destinatario/ai destinatari indicato/i nel messaggio, ed è protetto dalla legge. La diffusione, distribuzione e/o la copia del contenuto del presente messaggio da parte di qualsiasi soggetto diverso dal destinatario è severamente vietata ai sensi dell’art. 616 c.p. e delle vigenti normative in materia di protezione dei dati personali. Se non siete i destinatari del presente messaggio, vi preghiamo di distruggerlo e di darcene immediata comunicazione inviando un messaggio di ritorno all’indirizzo e-mail del mittente. This message (including any attachments) contains confidential information intended only for the recipient(s) named above, and is protected by law. Any disclosure, distribution and/or copying of this message by any subject different from the named recipient(s) is strictly prohibited according to art. 616 c.p. and to the applicable data protection laws. If you are not the intended recipient, please delete this message and inform us immediately about the deletion by sending a message to the sender’s e-mail address. ________________________________

Aug. 30, 2018

Re: [nexa] Improving DNS Privacy in Firefox

by Stefano Quintarelli

capito tutto non sapevo che ci fossero provider che fanno man in the middle sul DNS. sei certo di cio' ? (il mio non lo fa) non e' roba da denuncia, in assenza di uno specifico ordine motivato dell'autorita' giudiziaria ? ciao, s. On 30/08/2018 15:24, Alberto Cammozzo wrote: > Ciao Stefano, > a meno di usare DNsCrypt, DNScurve o altri protocolli DNS cifrati, i > resolver DNS "comuni" non cifrano il payload, per cui i provider più > zelanti (anche in Italia) modificano il traffico anche se nono sono i > loro DNS a rispondere alla query (cioè fanno Deep Packet Inspectio -- > anche se sarebbe più corretto dire che è un attacco Man In The Middle) > Per esempio, se hai configurato come server DNS un server di Google e > chiedi l'indirizzo di Pirate Bay, otterrai 127.0.0.1 o l'indirizzo del > banner di censura perché il tuo provider modifica al volo il contenuto > del pacchetto e sostituisce l'indirizzo corretto (censurato) con quello > "di censura". > Il comportamento varia da provider a provider, alcuni non fanno DPI > Per evitare la censura serve una cifratura del traffico ce lo renda > inalterabile. > Neanche a me piace HTTPS e meno che meno la centralizzazione. I > protocolli di cifratura DNS sono complicati. > Una soluzione efficace che tecnicamente non è alla portata di tutti è > dirottare tutto (e solo) il traffico DNS su una o più VPN verso un > server DNS proprio (o sicuro). > DoH è più facile, anche se condivido le critiche esposte in lista. > > ciao, > Alberto > > > On 30/08/2018 12:16, Stefano Quintarelli wrote: >> perche non usare uno qualsiasi degli N (grandissimo) DNS che ci sono >> in giro per il mondo ? (o uno proprio) >> >> On 30/08/2018 12:12, Simone Basso wrote: >>> Ciao Marco, >>> >>> Il giorno gio 30 ago 2018 alle ore 10:50 Marco Mellia >>> <marco.mellia(a)polito.it <mailto:marco.mellia@polito.it>> ha scritto: >>> >>> Qualcuno mi deve spiegare perché il DNS di cloudflare o di Google o >>> di Amazon (note no profit organization che non paghiamo) dovrebbe >>> essere più sicuro/veloce/affidabile del DNS del ISP (che >>> paghiamo)... >>> >>> >>> Perché ci sono vari stati nel mondo dove usare il DNS che il tuo >>> provider ti fornisce significa censura. Questo implica cose come >>> essere indirizzati su 127.0.0.1 oppure su una block page che ti >>> spiega perché non puoi accedere a un contenuto. >>> >>> Anche qualora non vi fosse alcun tipo di manipolazione del DNS, vi >>> potrebbe essere sorveglianza, monitorando le query DNS. >>> >>> Implementando il DNS-over-HTTPS (che è la soluzione descritta >>> nell'articolo che è stato postato) si aumenta il costo richiesto a >>> uno stato per continuare a implementare censura e/o sorveglianza. >>> Questo è bene per un individuo, organizzazione, o entità X, se negli >>> obiettivi di X c'è aiutare le persone che stanno su internet ad >>> accedere liberamente ai contenuti cui desiderano accedere. >>> >>> Questo trend per cui tutto passa per i soliti big player dovrebbe >>> fare più paura. Invece tutti a gridare al miracolo perché ci >>> propinano un obbrobrio tecnico come la panacea ad un non problema... >>> >>> >>> Non sono d'accordo che sia un "non problema". Ci sono aree del mondo >>> dove questo probabilmente non è un problema e devo inviare più >>> traffico a un ristretto numero di player potrebbe essere un problema. >>> E aree del mondo dove questa tecnica è utile per superare la censura. >>> >>> Bye, >>> >>> Simone >>> >>> >>> My 2c >>> M >>> >>> >>> Inviato da iPad >>> >>> > Il giorno 29 ago 2018, alle ore 21:24, >>> nexa-request(a)server-nexa.polito.it >>> <mailto:nexa-request@server-nexa.polito.it> ha scritto: >>> > >>> > Questo dovrebbe essere dirompente per molti degli schemi di >>> censura in >>> > Italia, basati su DNS DPI >>> > >>> > >>> <https://blog.nightly.mozilla.org/2018/06/01/improving-dns-privacy-in-firefo…> >>> >>> > >>> > Domain Name Service (DNS) is one of the oldest parts of internet >>> > architecture, and remains one that has largely been untouched by >>> efforts >>> > to make the web safer and more private. On the Firefox >>> network and >>> > security teams, we’re working to change that by encrypting DNS >>> queries >>> > and by testing a service that keeps DNS providers from collecting >>> and >>> > sharing your browsing history. >>> >>> _______________________________________________ >>> nexa mailing list >>> nexa(a)server-nexa.polito.it <mailto:nexa@server-nexa.polito.it> >>> https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa >>> >>> >>> >>> _______________________________________________ >>> nexa mailing list >>> nexa(a)server-nexa.polito.it >>> https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa >>> >> _______________________________________________ >> nexa mailing list >> nexa(a)server-nexa.polito.it >> https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa > > > _______________________________________________ > nexa mailing list > nexa(a)server-nexa.polito.it > https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa

Aug. 30, 2018