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