Re: [nexa] Improving DNS Privacy in Firefox
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)... 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... My 2c M Inviato da iPad
Il giorno 29 ago 2018, alle ore 21:24, 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.
Ciao Marco, Il giorno gio 30 ago 2018 alle ore 10:50 Marco Mellia < 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 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 https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa
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
Il giorno gio 30 ago 2018 alle ore 12:16 Stefano Quintarelli < stefano@quintarelli.it> ha scritto:
perche non usare uno qualsiasi degli N (grandissimo) DNS che ci sono in giro per il mondo ? (o uno proprio)
Non ho seguito abbastanza da vicino il dibattito relativo all'implementazione da poterti rispondere sapendo in prima persona le motivazioni per cui questa specifica scelta e' stata implementata in questo modo, e non ho mai investito tempo per approfondire la questione. Riguardo al modo in cui funziona, stando a quanto riporta Daniel Stenberg su Twitter, il menu di configurazione di Firefox ha un default pre-impostato, ossia Cloudflare, e volendo un utente puo' cambiare questa impostazione predefinita [1], "basta" che sappia quali altri provider usare. Basandomi sulla mia esperienza ma ignorando - come dicevo - la discussione sui dettagli di DNS over HTTPS (doh), penso che possa essere ragionevole ipotizzare che usare un fornitore doh di grandi dimensioni per questi due motivi: 1. collateral freedom [2]: se il servizio di doh lo fornisce una entita' relativamente piccola, uno stato puo' permettersi di tirare giu' questa entita' senza causare troppi danni, ma, se si tratta di una entita' molto grande, bloccarla puo' creare molti collaterali all'economia e al funzionamento di internet in quello stato (una delle tecniche piu' efficaci di evasione della censura, meek [3], funziona proprio cosi') 2. performance: se si tratta di un servizio con punti di presenza quasi ovunque, dovrebbe tendenzialmente funzionare bene (si vuole evitare di dare ulteriori problemi di performance a gente che gia' parte spesso con reti che non sono il massimo). Bye, Simone [1] https://twitter.com/bagder/status/1033384089750044672 [2] https://en.wikipedia.org/wiki/Collateral_freedom [3] https://blog.torproject.org/tor-heart-bridges-and-pluggable-transports
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
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
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
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
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
Il punto con il DoH è se sia più una soluzione o più un nuovo problema. Potrei scrivere un bel po' sui possibili attacchi. E anche quanto a censura, non cambia nulla. Il tuo ISP può comunque bloccare l'IP, sia di PirateBay che di CloudFlare. O effettuare il NAT verso un sito ad hoc. E per la stessa ragione, il tuo ISP sa esattamente quali IP contatti, su quali porte (dunque che servizi usi di quei server). Un bell'articolo a proposito dell'HTTPS per il contrasto alla censura è stato pubblicato dal Internet Monitor del Berkman Klein Center: https://medium.com/berkman-klein-center/the-uncertain-effects-of-https-adopt... Oggi però ho finito il tempo. E sono stanco. Esausto. https://bugzilla.mozilla.org/show_bug.cgi?id=1487081 https://lobste.rs/s/vwcetz/undetectable_remote_arbitrary_code (cachata su https://shamar.github.io/documents/Mozilla-Bug1487081-Attachments/Undetectab... perché temporaneamente bloccata) Non so più se si tratti di mala fede o incompetenza degli "esperti". Ma sono entrambe molto pericolose. Giacomo Il 30 agosto 2018 16:15, Simone Basso <bassosimone@gmail.com> ha scritto:
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
_______________________________________________ nexa mailing list nexa@server-nexa.polito.it https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa
In data giovedì 30 agosto 2018 16:32:07 CEST, Giacomo Tesio ha scritto:
Oggi però ho finito il tempo. E sono stanco. Esausto.
https://bugzilla.mozilla.org/show_bug.cgi?id=1487081 https://lobste.rs/s/vwcetz/undetectable_remote_arbitrary_code (cachata su https://shamar.github.io/documents/Mozilla-Bug1487081-Attachments/Undetecta ble_Remote_Arbitrary_Code_Execution_Attacks_through_JavaScript_and_HTTP_head ers_trickery__Lobsters.html perché temporaneamente bloccata) Come utente di Firefox, grazie dell'accuratissimo lavoro: mi piacerebbe molto che Firefox implementi delle policy raffinate di gestione del codice JS. Trovo preoccupante che si scriva "It is incorrect to report this as a bug in firefox because this is intended behavior.".
m.c.
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
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
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
On Thu, Aug 30, 2018 at 03:30:11PM +0200, Stefano Quintarelli wrote:
non sapevo che ci fossero provider che fanno man in the middle sul DNS. sei certo di cio' ? (il mio non lo fa)
Non vivo più in Italia da anni, ma ricordo le reazioni indignate di molti amici geek italiani anni fa, quando Vodafone e altri provider iniziarono a fare cose di questo tipo.
non e' roba da denuncia, in assenza di uno specifico ordine motivato dell'autorita' giudiziaria ?
Hit me. Perché dovrebbe esserlo? Immagino sia un comportamento documentato (vagamente..., ma tant'è) nelle condizioni del contratto di accesso a Internet che il provider ti da. O mangi la man-in-the-middle minestra, oppure salti dalla finestra. Ti prego, stupiscimi, e dimmi che c'è una legga che renderebbe clausole di quel tipo caduche! -- Stefano Zacchiroli . zack@upsilon.cc . upsilon.cc/zack . . o . . . o . o Computer Science Professor . CTO Software Heritage . . . . . o . . . o o Former Debian Project Leader & OSI Board Director . . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club »
On 30/08/2018 20:16, Stefano Zacchiroli wrote:
non e' roba da denuncia, in assenza di uno specifico ordine motivato dell'autorita' giudiziaria ?
Hit me. Perché dovrebbe esserlo? Immagino sia un comportamento documentato (vagamente..., ma tant'è) nelle condizioni del contratto di accesso a Internet che il provider ti da. O mangi la man-in-the-middle minestra, oppure salti dalla finestra. Ti prego, stupiscimi, e dimmi che c'è una legga che renderebbe clausole di quel tipo caduche!
credo sia la direttiva 2002/58/EC ma i giuristi possono essere piu' precisi... ciao!, s.
Il 29/08/18 22:45, Marco Mellia 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)...
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...
My 2c M
A casa si puo usare un raspberry con unbound installato e fare dns server ricorsivo in modo indipendente (sostituirsi in blocco a Google o IPS locali). Con lo smartphone la questione si complica ma puoi usare un fornitore di fiducia alternativo a titolo di esempio: https://www.privacyfoundation.ch/de/service/server.html#dns-server o https://www.ccc.de/de/censorship/dns-howto
https://uk.pi-supply.com/products/pi-hole-kit-network-wide-ad-blocker e sul mobile vpn che fa girare tutto il traffico da casa... ciao!, s. On 21/10/2018 12:50, Luca Cappelletti wrote:
Il 29/08/18 22:45, Marco Mellia 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)...
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...
My 2c M
A casa si puo usare un raspberry con unbound installato e fare dns server ricorsivo in modo indipendente (sostituirsi in blocco a Google o IPS locali). Con lo smartphone la questione si complica ma puoi usare un fornitore di fiducia alternativo a titolo di esempio:
https://www.privacyfoundation.ch/de/service/server.html#dns-server
o
https://www.ccc.de/de/censorship/dns-howto
_______________________________________________ nexa mailing list nexa@server-nexa.polito.it https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa
participants (8)
-
Alberto Cammozzo -
Giacomo Tesio -
Luca Cappelletti -
Marco Ciurcina -
Marco Mellia -
Simone Basso -
Stefano Quintarelli -
Stefano Zacchiroli