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