On 31/08/2018 18:16, Simone Basso wrote:
Il giorno gio 30 ago 2018 alle ore 16:33 Alberto Cammozzo <ac+nexa@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@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@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@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-firefox...> > > >>>> > >>>> > > >>>> > 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@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@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@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@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@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@server-nexa.polito.it <mailto:nexa@server-nexa.polito.it> > https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa
_______________________________________________ nexa mailing list 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@server-nexa.polito.it https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa