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@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