Il giorno gio 30 ago 2018 alle ore 16:33 Alberto Cammozzo < ac+nexa@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@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@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>> 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>> >>>> 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 <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
_______________________________________________ nexa mailing list nexa@server-nexa.polito.it https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa