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

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

by Giacomo Tesio

Il 31 agosto 2018 10:51, Marco Ciurcina <ciurcina(a)studiolegale.it> ha scritto: > Certamente, se fossi un legale che si occupa di un caso di questo tipo, > proverei ad utilizzare la tua segnalazione (insieme ad altri elementi) per > argomentare che sapevano o, quanto meno, avrebbero dovuto sapere. Aggiungi questo alle prove: https://twitter.com/giacomotesio/status/1035661109938806784 Non mi era proprio venuto in mente prima di contattare W3C e WHATWG! Giacomo

Aug. 31, 2018

Re: [nexa] nexa Digest, Vol 112, Issue 32

by Marco Mellia

Ciao Simone, Non c’e’ molto da indagare - e’ una cosa nota che Vodafone implementi il transparent DNS Proxy — ovvero tutto il traffico verso porta 53 viene mandato ai suoi server DNS, indipendentemente dal IP del server contattato. Basta una ricerca con google “Vodafone dns”. Tornando a DoH - dal punto di vista tecnico e’ una porcata immensa. Per di piu’, in opzione “opt-out” e’ una di quelle cose che farà impazzire gli amministratori di rete. Lato consumer, già vedo i forum pieni di “ho messo 8.8.8.8 come server dns, ma ancora non mi funziona con firefox”. Lato business, tutte le precauzioni che si usano in ambito corporate che fanno leva sul DNS improvvisamente non funzioneranno più, con bella pace della sicurezza e policy. Non oso immaginare che cosa succederà quando i DNS di clodflare non funzioneranno a dovere. Con buona pace del troubleshooting. Senza neanche citare i problemi per la magistratura quando dovrà indagare, o richiedere il blocco di qualche sito (che piaccia o no). Ultimo, dal punto di vista della privacy, mi chiedo perche’ google, cloudflare e altri siano così generosi da implementare ed offrire “gratis” un servizio DNS. Come sappiamo bene — se non paghi per un prodotto, il prodotto sei tu. Grazie al DNS, ora google sa anche quale shop online frequenti, quale sito porno preferisci, e se anche se usi duckduckgo come motore di ricerca. Per non parlare del potere che ha nel modificare a suo piacere quali server di quale CDN indirizzare il tuo traffico, e decidere se e quali servizi puoi accedere. Parliamo di censura — ma qui mi viene voglia di parlare di grandissimo fratello! Internet e’ nata come una rete distribuita, e ora e’ diventata sempre piu’ il dominio di 3/4 grandi aziende. Gestiscono il traffico, controllano l’informazione, e ora, si impossessano anche del DNS. Senza che alcuno possa fare alcun controllo. Un caro saluto M -- Marco Mellia - Associate Professor SmartData@PoliTO coordinator - https://smartdata.polito.it <https://smartdata.polito.it/> Dipartimento di Elettronica e Telecomunicazioni Politecnico di Torino Corso Duca Degli Abruzzi 24 10129 - Torino - IT Tel: +39-011-090-4173 Cel: +39-331-6714789 Skype: mgmellia Home page: http://www.tlc-networks.polito.it/mellia <http://www.tlc-networks.polito.it/mellia> > On 31 Aug 2018, at 17:16, nexa-request(a)server-nexa.polito.it wrote: > >> 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ì? >> > > Corretto! > > >> 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... >> > > Ha senso. La cosa che mi chiedevo e' se il pacchetto della richiesta arriva > davvero al server. Non trovandomi più nel posto con Vodafone dove mi > trovavo ieri (TM), ho avuto un po' di difficoltà nell'eseguire esperimenti. > > Nei limiti consentiti dal rompere le scatole ad altre persone, ho potuto > constatare che apparentemente la richiesta non arriva al server. > > Per investigare ho scritto un client DNS minimale ( > https://github.com/bassosimone/verrocchio <https://github.com/bassosimone/verrocchio>) che invia una richiesta DNS a un > server TopIX che usiamo per Neubot dove stavo eseguendo netcat su ' > 0.0.0.0:53/udp`. Eseguendo questo test dalla rete Wind in cui mi trovo, non > ho ricevuto ovviamente risposta e ho visto la query arrivare. Quando il mio > uomo con Vodafone (TM) ha eseguito questo test, non ho visto arrivare > richieste DNS sul server ma in compenso è arrivata una risposta corretta > lato client. > > Questa potrebbe essere una cosa interessante da misurare più su larga scala > con OONI quando torno dalle vacanze. > > Bye, > > Simone >

Aug. 31, 2018

Re: [nexa] Improving DNS Privacy in Firefox

by Alberto Cammozzo

On 31/08/2018 18:16, Simone Basso wrote: > Il giorno gio 30 ago 2018 alle ore 16:33 Alberto Cammozzo > <ac+nexa(a)zeromx.net <mailto:ac%2Bnexa@zeromx.net>> ha scritto: > > 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ì? > > > Corretto! > > 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... > > > Ha senso. La cosa che mi chiedevo e' se il pacchetto della richiesta > arriva davvero al server. Non trovandomi più nel posto con Vodafone > dove mi trovavo ieri (TM), ho avuto un po' di difficoltà nell'eseguire > esperimenti. > > Nei limiti consentiti dal rompere le scatole ad altre persone, ho > potuto constatare che apparentemente la richiesta non arriva al server. > > Per investigare ho scritto un client DNS minimale > (https://github.com/bassosimone/verrocchio) che invia una richiesta > DNS a un server TopIX che usiamo per Neubot dove stavo eseguendo > netcat su '0.0.0.0:53/udp` <http://0.0.0.0:53/udp%60>. Eseguendo > questo test dalla rete Wind in cui mi trovo, non ho ricevuto > ovviamente risposta e ho visto la query arrivare. Quando il mio uomo > con Vodafone (TM) ha eseguito questo test, non ho visto arrivare > richieste DNS sul server ma in compenso è arrivata una risposta > corretta lato client. Quindi in sostanza Vodafone intercetta tutto il traffico DNS. Si potrebbe verificare se manipola solo le richieste DNS *ben formate* o se intercetta *indiscriminatamente* il traffico su porta 53/UDP (o TCP). Nel primo caso potrebbe giustificare il proprio comportamento come "caching" delle richieste DNS del cliente. Nel secondo non vedo giustificazione possibile: infatti io posso legittimamente usare 53/UDP per traffico non DNS. Non vedo motivo legittimo per intercettarlo. > > Questa potrebbe essere una cosa interessante da misurare più su larga > scala con OONI quando torno dalle vacanze. Certamente! ciao, Alberto > > Bye, > > Simone > > > 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> > > <http://slashdot.org> > > > > ``` > > ventimiglia$ host www.slashdot.org <http://www.slashdot.org> > <http://www.slashdot.org> > > www.slashdot.org <http://www.slashdot.org> > <http://www.slashdot.org> has address 216.105.38.15 > > > > ventimiglia$ dig @216.105.38.15 <http://216.105.38.15> > <http://216.105.38.15> www.google.com <http://www.google.com> > > <http://www.google.com> > > > > ; <<>> DiG 9.10.6 <<>> @216.105.38.15 <http://216.105.38.15> > <http://216.105.38.15> > > www.google.com <http://www.google.com> <http://www.google.com> > > [...] > > ;; QUESTION SECTION: > > ;www.google.com <http://www.google.com> <http://www.google.com>.INA > > > > ;; ANSWER SECTION: > > www.google.com <http://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> > <http://216.105.38.15> > > www.google.com <http://www.google.com> <http://www.google.com> > > > > ; <<>> DiG 9.10.3-P4-Debian <<>> @216.105.38.15 > <http://216.105.38.15> <http://216.105.38.15> > > www.google.com <http://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> > <http://216.105.38.15> www.google.com <http://www.google.com> > > <http://www.google.com> > > > > ; <<>> DiG 9.9.5-9+deb8u10-Debian <<>> @216.105.38.15 > <http://216.105.38.15> > > <http://216.105.38.15> www.google.com <http://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> > <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> > <mailto:ac%2Bnexa@zeromx.net <mailto:ac%252Bnexa@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>> > > <mailto:marco.mellia@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>> > > >>>> <mailto:nexa-request@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>> > > <mailto:nexa@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> > <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> > <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> > <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> > <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 > https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa

Aug. 31, 2018

Re: [nexa] Improving DNS Privacy in Firefox

by Simone Basso

Il giorno gio 30 ago 2018 alle ore 16:33 Alberto Cammozzo < ac+nexa(a)zeromx.net> ha scritto: > 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ì? > Corretto! > 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... > Ha senso. La cosa che mi chiedevo e' se il pacchetto della richiesta arriva davvero al server. Non trovandomi più nel posto con Vodafone dove mi trovavo ieri (TM), ho avuto un po' di difficoltà nell'eseguire esperimenti. Nei limiti consentiti dal rompere le scatole ad altre persone, ho potuto constatare che apparentemente la richiesta non arriva al server. Per investigare ho scritto un client DNS minimale ( https://github.com/bassosimone/verrocchio) che invia una richiesta DNS a un server TopIX che usiamo per Neubot dove stavo eseguendo netcat su ' 0.0.0.0:53/udp`. Eseguendo questo test dalla rete Wind in cui mi trovo, non ho ricevuto ovviamente risposta e ho visto la query arrivare. Quando il mio uomo con Vodafone (TM) ha eseguito questo test, non ho visto arrivare richieste DNS sul server ma in compenso è arrivata una risposta corretta lato client. Questa potrebbe essere una cosa interessante da misurare più su larga scala con OONI quando torno dalle vacanze. Bye, Simone > 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 > > > _______________________________________________ > nexa mailing list > nexa(a)server-nexa.polito.it > https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa >

Aug. 31, 2018

NLP’s generalization problem, and how researchers are tackling it

by Giacomo Tesio

Salve, vi propongo un articolo molto interessante sullo stato dell'arte nella NLP. E' utilissimo anche solo come indice di riferimenti a diversi paper ancora più interessanti. https://thegradient.pub/frontiers-of-generalization-in-natural-language-pro… Da un lato penso che sia un bell'esempio di come il linguaggio antropomorfico che usiamo in AI influenza (e rallenta) la ricerca. Dall'altro lo trovato veramente onesto in questo passaggio: Workshop attendees raised worries that stress test sets could slow down > progress. What are good stress tests that will give us better insights into > true generalization power and encourage researchers to build more > generalizable systems, but *will not cause funding to decline* and *researchers > to be stressed* with the low results? The workshop did not provide an > answer to this question. > Sebbene non sia citata nelle conclusioni, io credo che questo sia una questione dirimente. Continuiamo a parlare di "apprendimento", di "intelligenza artificiale" e di "senso comune" (qualcuno dovrebbe far notare agli anglofoni che c'è una profonda differenza fra senso comune e buon senso... ma questa è un'altra storia) perché abbiamo paura di perdere finanziamenti? Giacomo

Aug. 31, 2018

Interesting article on digitization and outsourcing

by Roberto Dolci

https://www.wsj.com/articles/the-end-of-employees-1486050443?mod=djmc_pkt_f…

Aug. 31, 2018

Five Country Ministerial 2018

by J.C. DE MARTIN

https://www.homeaffairs.gov.au/about/national-security/five-country-ministe… Five Country Ministerial 2018 Official Communiqué We, the Homeland Security, Public Safety, and Immigration Ministers of Australia, Canada, New Zealand, the United Kingdom, and the United States met on the Gold Coast, Australia, on August 28-29 2018, to discuss how we can better collaborate to meet our common security challenges. We reaffirmed that the close and enduring five country partnership, developed following the Second World War, remains fundamental to the security and prosperity of our nations. The 2018 Five Country Ministerial (FCM), which in previous years has achieved advancements in information and intelligence sharing on border protection and counter-terrorism, has matured to become the pre-eminent forum for collaboration among the five countries on domestic security issues. This year's FCM meeting recalibrated the forum to focus on tangible deliverables and practical collaboration on counter-terrorism, countering violent extremism, cyber security, countering foreign interference, protecting critical infrastructure, border management and law enforcement. A free, open, safe and secure internet [...] (Sent from my wireless device; please excuse brevity and typos (if any))

Aug. 31, 2018

Here’s the Conversation We Really Need to Have About Bias at Google - The New York Times

by J.C. DE MARTIN

https://www.nytimes.com/2018/08/30/technology/bias-google-trump.html Here’s the Conversation We Really Need to Have About Bias at Google Aug. 30, 2018 Let’s get this out of the way first: There is no basis for the charge that President Trump leveled against Google this week — that the search engine, for political reasons, favored anti-Trump news outlets in its results. None. Mr. Trump also claimed that Google advertised President Barack Obama’s State of the Union addresses on its home page but did not highlight his own. That, too, was false, as screenshots show that Google did link to Mr. Trump’s address this year. But that concludes the “defense of Google” portion of this column. Because whether he knew it or not, Mr. Trump’s false charges crashed into a longstanding set of worries about Google, its biases and its power. When you get beyond the president’s claims, you come upon a set of uncomfortable facts — uncomfortable for Google and for society, because they highlight how in thrall we are to this single company, and how few checks we have against the many unseen ways it is influencing global discourse. [...] Email: farhad.manjoo(a)nytimes.com; Twitter: @fmanjoo. Interested in All Things Tech? Get the Bits newsletter delivered to your inbox weekly for the latest from Silicon Valley and the technology industry. (Sent from my wireless device; please excuse brevity and typos (if any))

Aug. 31, 2018

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

by Marco Ciurcina

In data venerdì 31 agosto 2018 03:02:17 CEST, hai scritto: > Marco, possiamo assumere che siano ormai tutti informati? Senz'altro gli utenti del forum che ti hanno risposto. :-) > (lo sono... > ma tu parlavi di "provare" È difficile prevedere in astratto cosa si può provare in un processo: dipende dalle regole di procedura dello specifico processo (che dipendono dalla giurisdizione, dalla materia, dalla sensibilità del giudice, ecc.). Certamente, se fossi un legale che si occupa di un caso di questo tipo, proverei ad utilizzare la tua segnalazione (insieme ad altri elementi) per argomentare che sapevano o, quanto meno, avrebbero dovuto sapere. m.c.

Aug. 31, 2018

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

by Giacomo Tesio

PS: so che dovrei aprire la stessa segnalazione anche a Microsoft e Apple, ma... non ho voglia di affrontare il loro supporto tecnico. Marco, possiamo assumere che siano ormai tutti informati? (lo sono... ma tu parlavi di "provare"... IANAL... etc...) Il 31 agosto 2018 02:54, Giacomo Tesio <giacomo(a)tesio.it> ha scritto: > 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