Re: [nexa] nexa Digest, Vol 112, Issue 32
Ciao Simone, Non c’e’ molto da indagare - e’ una cosa nota che Vodafone implementi il transparent DNS Proxy — ovvero tutto il traffico verso porta 53 viene mandato ai suoi server DNS, indipendentemente dal IP del server contattato. Basta una ricerca con google “Vodafone dns”. Tornando a DoH - dal punto di vista tecnico e’ una porcata immensa. Per di piu’, in opzione “opt-out” e’ una di quelle cose che farà impazzire gli amministratori di rete. Lato consumer, già vedo i forum pieni di “ho messo 8.8.8.8 come server dns, ma ancora non mi funziona con firefox”. Lato business, tutte le precauzioni che si usano in ambito corporate che fanno leva sul DNS improvvisamente non funzioneranno più, con bella pace della sicurezza e policy. Non oso immaginare che cosa succederà quando i DNS di clodflare non funzioneranno a dovere. Con buona pace del troubleshooting. Senza neanche citare i problemi per la magistratura quando dovrà indagare, o richiedere il blocco di qualche sito (che piaccia o no). Ultimo, dal punto di vista della privacy, mi chiedo perche’ google, cloudflare e altri siano così generosi da implementare ed offrire “gratis” un servizio DNS. Come sappiamo bene — se non paghi per un prodotto, il prodotto sei tu. Grazie al DNS, ora google sa anche quale shop online frequenti, quale sito porno preferisci, e se anche se usi duckduckgo come motore di ricerca. Per non parlare del potere che ha nel modificare a suo piacere quali server di quale CDN indirizzare il tuo traffico, e decidere se e quali servizi puoi accedere. Parliamo di censura — ma qui mi viene voglia di parlare di grandissimo fratello! Internet e’ nata come una rete distribuita, e ora e’ diventata sempre piu’ il dominio di 3/4 grandi aziende. Gestiscono il traffico, controllano l’informazione, e ora, si impossessano anche del DNS. Senza che alcuno possa fare alcun controllo. Un caro saluto M -- Marco Mellia - Associate Professor SmartData@PoliTO coordinator - https://smartdata.polito.it <https://smartdata.polito.it/> Dipartimento di Elettronica e Telecomunicazioni Politecnico di Torino Corso Duca Degli Abruzzi 24 10129 - Torino - IT Tel: +39-011-090-4173 Cel: +39-331-6714789 Skype: mgmellia Home page: http://www.tlc-networks.polito.it/mellia <http://www.tlc-networks.polito.it/mellia>
On 31 Aug 2018, at 17:16, nexa-request@server-nexa.polito.it wrote:
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 <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
Marco Mellia wrote:
Ciao Simone,
Ciao Marco,
Non c’e’ molto da indagare - e’ una cosa nota che Vodafone implementi il transparent DNS Proxy — ovvero tutto il traffico verso porta 53 viene mandato ai suoi server DNS, indipendentemente dal IP del server contattato. Basta una ricerca con google “Vodafone dns”. Bisogna mettersi d'accordo su cosa è interessante e su cosa si vuole indagare, altrimenti arriviamo a conclusioni divergenti.
Dal mio punto di vista: - posso usare il fatto di avere Vodafone per migliorare l'engine DNS di OONI per rilevare i proxy DNS trasparenti e per meglio distinguere questi casi da quelli che noi chiamiamo di DNS injection (i.e. i casi "man in the middle" dai casi "man on the side") - posso abilitare questo test di default (o in caso ci siano specifiche condizioni) affinché OONI esegua questo test in alcuni o in tutti gli ISP in cui eseguiamo misure di censura e net neutrality - posso magari identificare nuovi ISP in cui è implementato un proxy DNS trasparente anche se questa cosa non è documentata per tali ISP - posso informare gli utenti, facendo vedere che è deployato un proxy DNS trasparente e quali sono le implicazioni, suggerendo anche loro in quale modo possono bypassare questa restrizione - posso ottenere un ulteriore data point che penso sarà utile per caratterizzare le altre misure di censura che raccogliamo Spiegati questi punti, non penso si possa concludere che non ci sia molto da indagare. Inoltre, anche per Vodafone per cui è noto che sia implementata questa tecnologia, come abbiamo visto, la discussione su questa lista è stata utile per coinvolgere più persone alcune delle quali non erano a conoscenza di questa informazione, anche se stava a una ricerca su Google di distanza.
Tornando a DoH - dal punto di vista tecnico e’ una porcata immensa.
Prima di introdurre una metrica ("immensa", "piccole", etc.) sarebbe utile capire quale sia la tua definizione di porcata. Altrimenti, come nel caso sopra, rischiamo di arrivare a conclusioni divergenti perché partiamo da definizioni differenti :-). Assumo che si tenda in generale a definire porcata una cosa di cui non si capiscono appieno le finalità. Inoltre, una tecnologia può in generale non essere considerata una porcata, ma una sua implementazione in uno specifico contesto potrebbe sembrarlo. Parlando del proxy DNS trasparente, mi vengono in mente casi in cui può avere senso implementarlo, per esempio per impedire di evadere alcuni tipi di censura (o "policy") usando un tunnel DNS. Come dicevo in un thread precedente e come postulato anche da altri su forum che parlano del proxy trasparente di Vodafone, è possibile che una ragione tecnica per implementare un proxy DNS trasparente sia quella di rendere più facile l'accesso alla Vodafone station da browser agli utenti (via "voda.station") e quindi semplificare la configurazione. Tu per caso hai idea di quali potrebbero essere le ragioni tecniche per le quali Vodafone ha implementato questo tipo di policy? (Come utente internet, questa policy mi fa imbestialire perché sono abituato a poter configurare io manualmente, se lo desidero, il DNS; mi trovo quindi molto sorpreso se qualunque mio tentativo di configurazione di sistema viene ignorato dalla rete o da altri software.)
Per di piu’, in opzione “opt-out” e’ una di quelle cose che farà impazzire gli amministratori di rete. Mi chiedo se hanno previsto una qualche forma di on-boarding per informare l'utente dell'uso del DNS over HTTPS di Cloudflare.
Lato consumer, già vedo i forum pieni di “ho messo 8.8.8.8 come server dns, ma ancora non mi funziona con firefox”. In questo caso, però, uno può rispondergli sul forum dicendo "guarda, Johnny, che c'è un'opzione che puoi disabilitare".
Mi sembra più facile come problema, da gestire, rispetto al problema di bypassare il proxy trasparente di Vodafone, che è una cosa che si può implementare su Linux, stando a quello che leggo sui forum, installando e configurando dnsmasq oppure usando dnscrypt. Mi viene da ridere, BTW, se penso al cortocircuito di uno che risponde su un forum dicendo "guarda, per bypassare il DNS di Vodafone, puoi scaricare Firefox che usa direttamente un altro server DNS cifrato e non hai bisogno di sgozzare nessun gallo o avere Linux installato".
Lato business, tutte le precauzioni che si usano in ambito corporate che fanno leva sul DNS improvvisamente non funzioneranno più, con bella pace della sicurezza e policy. L'argomentazione che ho usato sopra ("mi stupisce che Vodafone ignori la mia configurazione DNS di sistema") si applica anche in questo caso: mi stupisce che Firefox ignori la mia configurazione DNS di sistema!
Sono però perplesso riguardo all'esistenza di corporation che hanno implementato "precauzioni che fanno leva sul DNS" e al tempo stesso non hanno un controllo centralizzato del software installato sulla flotta di macchine e sulla loro configurazione. In casi di questo tipo, in effetti, il problema principale non mi sembra sia questo cambiamento DNS introdotto da Firefox.
Non oso immaginare che cosa succederà quando i DNS di clodflare non funzioneranno a dovere. Per rispondere correttamente a questa domanda bisognerebbe vedere se, in tal caso, Firefox farà fallback sul DNS di sistema. Altrimenti la discussione rischia di essere basata più su speculazioni che su fatti.
FWIW, posso documentare un molto frustrante incidente avvenuto a casa mia a Torino (dove, come dicevo, ho Vodafone) circa sei mesi fa, nel quale, per mezz'ora, ho avuto il DNS non funzionante e non potevo navigare, pur avendo connettività IP verso 8.8.8.8 e 1.1.1.1 che avevo (vanamente!) configurato come miei DNS di sistema. Come vedi, si tratta di problemi simmetrici e altrettanto frustranti. Tranne che, indipendentemente dal fatto che l'opzione sia opt-in o opt-out, mi posso immaginare lo scenario in cui tale opzione è abilitata, Firefox si accorge che il DNS di Cloudflare è giù, notifica l'utente, e gli chiede se per caso vuole usare un altro DNS o il DNS di sistema, magari informandolo dei rischi (visto che Mozilla sta usando l'argomentazione rischi per implementare questo servizio). Nel caso di Vodafone, invece, non vedo bene in quale modo la Vodafone Station mi poteva informare del problema del DNS giù.
Con buona pace del troubleshooting. Si. Come ho detto sopra, sia la soluzione di Vodafone sia la soluzione di Firefox pongono problemi perché deviano rispetto a quello che come utenti siamo abituati ad aspettarci (i.e. se vogliamo possiamo configurarlo noi, altrimenti c'è un qualche default).
Senza neanche citare i problemi per la magistratura quando dovrà indagare, o richiedere il blocco di qualche sito (che piaccia o no).
In Dungeons & Dragons, questo atteggiamento porta a identificare il tuo allineamento come legale. Io ho un altro allineamento per il quale preferisco che l'azione della magistratura sia un po' più difficile - avendo visto quello che fa la magistratura in altri paesi e essendo convinto che - dato abbastanza potere - "non ci sono poteri buoni". Questi sono punti di vista personali di cui potremmo discutere fino allo sfinimento ma che sono forse più adatti per una birra o forse più un paio di birre che per una discussione in mailing list :-).
Ultimo, dal punto di vista della privacy, mi chiedo perche’ google, cloudflare e altri siano così generosi da implementare ed offrire “gratis” un servizio DNS. Come sappiamo bene — se non paghi per un prodotto, il prodotto sei tu. Grazie al DNS, ora google sa anche quale shop online frequenti, quale sito porno preferisci, e se anche se usi duckduckgo come motore di ricerca. Per non parlare del potere che ha nel modificare a suo piacere quali server di quale CDN indirizzare il tuo traffico, e decidere se e quali servizi puoi accedere. Limito la mia risposta a Cloudflare e al servizio integrato in Firefox.
Sono andato a leggere qualcosa in più e, stando a quanto dicono loro, a questo servizio DNS non si applicano le privacy policy standard di Cloudflare, ma policy più restrittive che sono state negoziate apposta con Mozilla. Cito in blocco, visto che penso possa essere funzionale alla discussione: | As part of its agreement with Firefox, Cloudflare has agreed to | collect only a limited amount of data about the DNS requests that | are sent to the Cloudflare Resolver for Firefox via the Firefox | browser. Cloudflare will collect only the following information | from Firefox users: | | - Timestamp | - IP Version (IPv4 vs IPv6) | - Resolver IP address + Port the Query Originated From | - Protocol (TCP, UDP, TLS or HTTPS) | - Query Name | - Query Type | - Query Class | - Query Rd bit set | - Query Do bit set | - Query Size Query EDNS | - EDNS Version | - EDNS Payload | - EDNS Nsid | - Response Type (normal, timeout, blocked) | - Response Code | - Response Size | - Response Count | - Response Time in Milliseconds | - Response Cached | - DNSSEC Validation State (secure, insecure, bogus, indeterminate) | - Colo ID | - Server ID | | All of the above information will be stored briefly as part of | Cloudflare’s temporary logs, and then permanently deleted within 24 | hours of Cloudflare’s receipt of such information. In addition to | the above information, Cloudflare will also collect and store the | following information as part of its permanent logs. | | - Total number of requests processed by each Cloudflare | co-location facility | - Aggregate list of all domain names requested | - Samples of domain names queried along with the times of such queries | | Information stored in Cloudflare’s permanent logs will be anonymized | and may be held indefinitely by Cloudflare for its own internal | research and development purposes. Continua qui: https://developers.cloudflare.com/1.1.1.1/commitment-to-privacy/privacy-poli...
Parliamo di censura — ma qui mi viene voglia di parlare di grandissimo fratello! Nel caso specifico di Cloudflare per Firefox non mi sembra, nel senso che i dati che si tiene Cloudflare sembrano pochi.
Al netto del problema che sollevava Stefano Quintarelli (perché non permettere anche altri fornitori?), e che secondo me è sacrosanto, mi sembra che questo servizio di Firefox non abbia una brutta policy. Non so, forse è meglio usare Cloudflare via Firefox di configurare il DNS di Cloudflare come proprio resolver di sistema?
Internet e’ nata come una rete distribuita, e ora e’ diventata sempre piu’ il dominio di 3/4 grandi aziende. Gestiscono il traffico, controllano l’informazione, e ora, si impossessano anche del DNS. Senza che alcuno possa fare alcun controllo. Questo mi sembra un ottimo spunto per un'altra (lunga e super interessante) discussione, anche se mi sembra di aver capito leggendo e approfondendo che questo DNS di Firefox non sia probabilmente uno degli aspetti peggiori della centralizzazione in atto.
A presto, Simone
Il giorno 9 settembre 2018 14:53, Simone Basso <bassosimone@gmail.com> ha scritto:
Prima di introdurre una metrica ("immensa", "piccole", etc.) sarebbe utile capire quale sia la tua definizione di porcata.
Dicesi "porcata" qualunque attività umana che mi vergognerei di spiegare a mia figlia. (A scanso di equivoci, la riproduzione umana non rientra in questa categoria.) Un esempio: "Papà, perché avete deciso di incapsulare un protocollo binario (il DNS) dentro un protocollo binario crittografato (HTTP2 su SSL) progettato per trasferire ipertesti attraverso connessioni persistenti?" "Amore... sono cose da grandi..." "E' complicato?" "No... è idiota!" IMHO è una soluzione - troppo complicata - parziale (solo su un browser! e anche fossero tutti i browser, solo sui browser!) - contro intuitiva - sub ottimale: perché non progettare un protocollo migliore del DNS, invece? - genera un single point of failure / accentra in oligopoli - non mi fido di CloudFlare (che ha anche accesso ad altri dati personali, in quanto CDN) Se l'obbiettivo è proteggere gli utenti da MitM DNS da parte di ISP come Vodafone, la soluzione non è tecnica, ma politica: bisogna semplicemente vietare il MitM DNS. Giacomo
Giacomo Tesio ha scritto:
Il giorno 9 settembre 2018 14:53, Simone Basso <bassosimone@gmail.com> ha scritto:
Prima di introdurre una metrica ("immensa", "piccole", etc.) sarebbe utile capire quale sia la tua definizione di porcata.
Dicesi "porcata" qualunque attività umana che mi vergognerei di spiegare a mia figlia.
Mumble mumble... mi sembra un processo che si basa sulle tue conoscenze e sui tuoi postulati in un dato momento. Secondo me sarebbe meglio un processo in cui si cerca di dare una definizione condivisa e poi si vede se mappa su quelle che consideriamo essere porcate. In ogni caso, non e' assolutamente la parte piu' importante di questa discussione.
(A scanso di equivoci, la riproduzione umana non rientra in questa categoria.)
LOL
Un esempio:
"Papà, perché avete deciso di incapsulare un protocollo binario (il DNS) dentro un protocollo binario crittografato (HTTP2 su SSL) progettato per trasferire ipertesti attraverso connessioni persistenti?"
Stai usando come punto di partenza la tecnologia: HTTP2 e' un protocollo progettato per trasferire ipertesti attraverso connessioni persistenti quindi usarlo per trasferire il DNS e' incosistente con la mission originale del protocollo (aka "una porcata"). Sono in disaccordo con questo punto di vista, che mi sembra molto rigido. Considero un punto di partenza migliore pensare ai problemi che gli esseri umani vogliono (o hanno voluto) risolvere dato un certo tool, in questo contesto HTTP, dati anche altri vincoli posti dalla societa'. Quindi, per esempio, il fatto che sempre piu' funzionalita' siano state trasportate usando HTTP (penso a cose come il video, la chat, la condivisione di file, etc.) e' anche legato al fatto che spesso (a) usare HTTP era il modo piu' sicuro (inteso come "bullet proof") di far funzionare una applicazione (pensa a tutti i casi in cui certe porte sono bloccate, pensa a come BitTorrent e' stato combattuto a fine anni '00) e (b) in molti contesti - e fino almeno all'avvento del modello app e app store - il browser era il posto migliore dove implementare una applicazione distribuita che funzionasse "quasi ovunque" (modulo Internet Explorer, in alcuni casi, ma comunque c'erano un tot di workaround, come testimoniato dal fatto che sono state implementate applicazioni distribuite molto complesse). Questa evoluzione non era quella che forse era stata prevista all'inizio. Quindi alcune cose sono andate diversamente e alcuni protocolli sono stati adattati ed evoluti di conseguenza. (FTR, nemmeno TCP era pronto per essere TCP, prima di Jacobson, e siamo arrivati - noi umani - solo qualche anno fa scrivere una implementazione del controllo di flusso che non genera code enormi per andare veloce <https://queue.acm.org/detail.cfm?id=3022184>). La mia tesi e' che questo tipo di evoluzione sia abbastanza tipica di molti contesti umani (in alcuni casi seguiamo il percorso di minima resistenza e in altri reinventiamo la ruota, per divertimento, per profitto, per mancata conoscenza, o per ottime ragioni). Per cui ci troviamo oggi con, tra l'altro, un insieme di componenti che non funzionano esattamente nel modo era stato previsto inizialmente. Tra questi, se posso fare un crossover con un altro thread, anche JavaScript che e' passato da essere inizialmente un (tendenzialmente bel) linguaggio toy (ma privo di manico <https://9gag.com/gag/anXEbe0/if-programming-languages-were-weapons>) a uno degli strumenti principe con cui creare applicazioni distribuite (con problemi creati anche da questa evoluzione, alcuni dei quali sono stati citati appunto in altri thread in questa lista). Che le cose siano cresciute in un modo non previsto e' un problema che sicuramente va affrontato, ma e' anche difficile immaginarsi tutto in modo perfetto all'inizio e non avere cambiamenti successivi. Anche iterando su uno stesso protocollo, sperando di migliorarlo (e non sempre questo avviene, lo dico solo come nota a margine per sottolineare che non ho una visione progressista), puo' succedere che entrino in gioco altri problemi legati alla societa' che rendono complesso passare alla versione migliore. Un caso che mi viene in mente e' IPv6. Passare tutti a IPv6 quando siamo in cosi' tanti a essere connessi e' complicato, perche' richiede di mettere d'accordo un tot di persone, di coordinarsi. E i problemi di coordinamento sono sempre difficili da risolvere. Lo sono per una ventina di persone, figurati se non lo diventano per migliaia di reti che si devono mettere d'accordo e parlarsi. Questo porta a usare un minimo comun denominatore e a implementare sopra a questo soluzioni successive, e quindi in alcuni casi a una stratificazione (di protocolli nel caso che stiamo discutendo, di API se pensiamo che molti OS oggigiorno eseguono come prima applicazione un browser).
"Amore... sono cose da grandi..." "E' complicato?" "No... è idiota!"
Dire che e' idiota mi sembra (crossover con altro thread) un po' Linus-like. Non risolve la questione dal punto di vista razionale. Ci sta solo comunicando che tu hai dei feeling forti nei confronti di questa soluzione. E' una risposta emotiva e, come tale, non credo che vada neanche nella direzione auspicata da una persona con la sindrome di Asperger (per citare uno dei thread in LKML che hai linkato altrove). Il tipo di discussioni a cui mi piace partecipare e' diverso ed e' del tipo "questo cosa secondo me non va bene per ${ragione_razionale}". Le discussioni in cui non mi piace partecipare sono quelle in cui uno dice "questa cosa e' idiota". Mi fanno passare la voglia di discutere.
IMHO è una soluzione - troppo complicata
Rispetto a quali parametri? Ho letto l'RFC draft <https://datatracker.ietf.org/doc/draft-ietf-doh-dns-over-https/?include_text...>. Introduce il tipo MIME "message/dns" che riusa di base i messaggi DNS esistenti. Una frase del draft su cui IMHO riflettere, su questa lista, e' questa "Utilizing the full set of HTTP features enables DoH to be more than an HTTP tunnel, but at the cost of opening up implementations to the full set of privacy considerations of HTTP". Non amo i messaggi DNS perche' non sono word aligned, contengono dei salti, e non e' triviale scrivere un decoder sicuro. Ma mi rendo conto delle ragioni per cui probabilmente hanno riutilizzato i messaggi DNS invece di inventare un nuovo formato. In breve (ci torno anche dopo): meno colla da mantenere per utilizzare il sistema che al momento tutti usano (ossia il DNS). Non ho ancora controllato se questa funzionalita' e' anche disponibile via JavaScript e sono molto curioso di vedere se questo e' possibile e che tipo di messaggi siano disponibili in JavaScript. Un aspetto su cui sicuramente riflettere, parzialmente anticipato dalla frase che ho citato sopra, e' l'interazione tra doh e le cache HTTP. Non sono un esperto di cache, ma mi sembra quantomeno che l'RFC draft faccia un lavoro interessante di enumerazione di vari casi di interazione con le cache, anche se il diavolo sta nell'interazione tra tecnologie complesse (i.e. come dice a un certo punto l'RFC draft "The DoH protocol design allows applications to fully leverage the HTTP ecosystem, including features that are not enumerated here.") Il problema del bootstrap e' probabilmente meno interessante da discutere, almeno qua. Puoi usare un IP hardcodato oppure usare il DNS di sistema per risolvere il nome di dominio che sta nella URL di doh. Usare il DNS di sistema in qualche modo comunque rivela che stai usando uno specifico ISP per fare doh, che comunque e' meglio di rivelare tutte le query (dove "meglio" e' definito rispetto al threat model). (Cmq l'RFC draft e' una lettura molto interessante, che consiglio!)
- parziale (solo su un browser! e anche fossero tutti i browser, solo sui browser!)
Esiste una implementazione per libcurl che sto leggendo mentre ti rispondo. Sono 800 righe di codice C. Mi sembra abbastanza semplice da capire, considerando che probabilmente si assume che uno che si interessi di una implementazione DNS conosca il DNS. All'inizio non ero entusiasta dal fatto che avessero riusato il formato del DNS ma IMO ci sta [*]. Da un lato c'e' l'argomento della minimizzazione della colla (almeno a livello di codice C) e dall'altro c'e' che riusare lo stesso formato aiuta a riusare codice e espone chi rivede il codice cercando bug a una palestra simile a quella in cui si era allenato in precedenza (ossia verificare se un certo codice e' una implementazione robusta del parsing DNS). [*] Trasportando su [0..1] la mia scala di entusiasmo per qualcosa, "ci sta" e' 0.56.
- contro intuitiva
Ho speso gia' molti cicli-Simone per rispondere ad altri punti. Qua non riesco a guessare facilmente cosa intendi. Meglio se espandi.
- sub ottimale: perché non progettare un protocollo migliore del DNS, invece?
Implementare un sistema nuovo di questo tipo che rimpiazzi il DNS su scala mondiale e' un task massivo. Un ragionevole punto di partenza iniziale, quindi, specie se si vuole che questa feature funzioni, potrebbe essere "nascondere" questo protocollo dentro qualcosa che tendenzialmente viene fatto passare anche nei casi piu' rough (ho parlato altrove in questo thread di "collateral freedom"). Visto che questo sistema probabilmente dovra' interoperare con il DNS , la cosa che costa meno energie nel backend e' tendenzialmente usare lo stesso formato di messaggi DNS. Ne segue che, anche se l'obiettivo fosse quello di creare un altro protocollo, probabilmente alcune scelte sarebbero simili a doh.
- genera un single point of failure / accentra in oligopoli
Questa e' la direzione che sta prendendo internet, pero'. Non ho a disposizione un controfattuale e non posso giungere a conclusioni razionali, ma comunque mi chiedo se la struttura di internet - almeno in Occidente - sarebbe stata diversa se BitTorrent non fosse stato aggredito cosi' tanto in passato. Ma sono considerazioni romantiche, perche' internet e il mondo vero (cit.) sono strettamente interlacciati, quindi era abbastanza utopico credere (come facevo io) che i rapporti di forza del mondo vero non avrebbero contribuito a modellare internet.
- non mi fido di CloudFlare (che ha anche accesso ad altri dati personali, in quanto CDN)
Se ti fidi dei ToS, come ho scritto in questo thread, puoi constatare che sono dei ToS abbastanza buoni. Se non ti fidi dei ToS, puoi vedere se c'e' un servizio alternativo oppure puoi deciderti di fidarti di piu' del tuo ISP. (Alla fine, di qualcuno ti devi fidare per quasi tutte le applicazioni piu' complesse di `ping 127.0.0.1`, ed e' giusto che sia tu a decidere di chi fidarti e di chi non fidarti.) Per la cronaca, su macOS, in Nightly doh e' disabilitato e la URL di default e' vuota con hint "https://doh.example.com/dns-query". in Firefox 62 non vedo un setting di alto livello per questa funzionalita', che cmq risulta disabilitata in "about:config". In Firefox 63.0b7 la configurazione e' identica a quella di Firefox Nightly. Stiamo quindi parlando, per il momento, di una feature che e' opt-in.
Se l'obbiettivo è proteggere gli utenti da MitM DNS da parte di ISP come Vodafone, la soluzione non è tecnica, ma politica: bisogna semplicemente vietare il MitM DNS.
Come dicevo in precedenza in questo thread, IMO il problema principale sono i casi in cui il DNS viene usato per fare censura e/o sorveglianza. Parlando di censura, questo problema che stiamo discutendo e' solo un capitolo di un piu' grande problema: ossia che la sovranita' digitale di un paese si estende facilmente fino ai resolver DNS degli ISP che operano in quel paese, mentre e' piu' costoso influenzare i servizi che operano al di fuori di tale paese. Per questo, la censura su base DNS e' una delle tecniche piu' diffuse e meno costose. Parlando di sorveglianza, nascondere il proprio traffico agli ISP locali e al governo, e magari rivelarlo a qualche corporation all'estero, puo' essere un compromesso piu' che accettabile per alcuni threat model. (In realta', anche da noi, alcune informazioni possono essere piu' al sicuro se rivelate a una entita' oltre oceano, piu' difficile da raggiungere e magari piu' ostica in tribunale, rispetto a rivelarle al proprio ISP italiano). Riguardo al vietare il MitM DNS, Quintarelli aveva scritto "non e' roba da denuncia, in assenza di uno specifico ordine motivato dell'autorita' giudiziaria?" e "credo sia la direttiva 2002/58/EC, ma i giuristi possono essere piu' precisi...". Quindi ci serve una mano da un giurista per capire meglio! Simone
Anzitutto grazie per la risposta chiara e precisa. Mi scuso anzitutto per l'ironia se in qualche modo ti ha offeso: visto che obbiettavi alla assenza di definizione per "porcata" ti ho fornito quella che uso nella vita quotidiana. E riportando un dialogo (immaginario, ma assolutamente verosimile) con la mia figlia maggiore, definivo sinteticamente "idiota" una scelta tecnologica che (per le ragioni elencate successivamente) non ritengo efficiente, efficace, sicura o... razionale. Non intendevo (e non credevo di) offendere nessuno ed in realtà non ho alcun sentimento forte nei confronti del DoH (contrariamente a JavaScript, per esempio). Il resto della tua mail è assolutamente interessante, ma temo che siamo in disaccordo su alcuni assunzioni di base. Il giorno 20 settembre 2018 15:24, Simone Basso <bassosimone@gmail.com> ha scritto:
Giacomo Tesio ha scritto:
"Papà, perché avete deciso di incapsulare un protocollo binario (il DNS) dentro un protocollo binario crittografato (HTTP2 su SSL) progettato per trasferire ipertesti attraverso connessioni persistenti?"
Stai usando come punto di partenza la tecnologia: HTTP2 e' un protocollo progettato per trasferire ipertesti attraverso connessioni persistenti quindi usarlo per trasferire il DNS e' incosistente con la mission originale del protocollo (aka "una porcata").
Sono in disaccordo con questo punto di vista, che mi sembra molto rigido. [...] La mia tesi e' che questo tipo di evoluzione sia abbastanza tipica di molti contesti umani (in alcuni casi seguiamo il percorso di minima resistenza e in altri reinventiamo la ruota, per divertimento, per profitto, per mancata conoscenza, o per ottime ragioni).
Io direi invece che fossilizzarsi su una singola porta e veicolare tutto attraverso un singolo protocollo, sia piuttosto rigido. Ora, trattandosi di SOFTware, non abbiamo la scusa che modificare l'infrastruttura dopo l'installazione della stessa è impossibile. E' sempre possibile. Può essere costoso, ma è possibile. Il punto dunque diventa: 1. se i problemi dell'infrastruttura sono così gravi da giustificare l'investimento 2. se i costi generati dai workaround a tali problemi (ovvero nuovi problemi) siano maggiori dei costi dell'intervento. Secondo me, entrambe le condizioni suddette sono vere da tempo. E' ora dunque che smettiamo di buttare pezze su pezze, ci fermiamo un attimo a ragionare e troviamo soluzioni migliori. Questo nell'obbiettivo, che suggerisci e che condivido, di servire l'umanità.
Che le cose siano cresciute in un modo non previsto e' un problema che sicuramente va affrontato, ma e' anche difficile immaginarsi tutto in modo perfetto all'inizio e non avere cambiamenti successivi.
Naturalmente. Purtroppo questo spiega i problemi, ma non giustifica il mancato intervento per risolverli seriamente.
Un caso che mi viene in mente e' IPv6. Passare tutti a IPv6 quando siamo in cosi' tanti a essere connessi e' complicato, perche' richiede di mettere d'accordo un tot di persone, di coordinarsi. E i problemi di coordinamento sono sempre difficili da risolvere.
Anche per questo dico che la Tecnologia è Politica. Le "difficoltà" di IPv6 sono una prova di questo fatto. Coordinarsi è facile al livello giusto. Per assurdo: basta una legge che dice che le comunicazioni Internet via IPv4 sono vietate dal giorno tot. Coordinamento effettuato.
IMHO è una soluzione - troppo complicata
Rispetto a quali parametri?
Rispetto ad un protocollo ad hoc, che è possibile.
Un aspetto su cui sicuramente riflettere, parzialmente anticipato dalla frase che ho citato sopra, e' l'interazione tra doh e le cache HTTP. Non sono un esperto di cache [...]
La questione non è se riescono a considerare tutti i casi (e non riescono, vedi gli standard con cui Mozilla giustifica il suo rifiuto di proteggere i propri utenti dagli attacchi che ho descritto), ma che quel intero albero di possibilità (foresta?) non dovrebbe trovarsi su questa strada. Keep It Simple.
- parziale (solo su un browser! e anche fossero tutti i browser, solo sui browser!)
Esiste una implementazione per libcurl che sto leggendo mentre ti rispondo.
Perché ping dovrebbe dipendere da libcurl? Ti rendi conto? Non è questione di quante righe di codice (molte di più di 800 se includi le dipendenze), è che non ha senso!
- contro intuitiva
Ho speso gia' molti cicli-Simone per rispondere ad altri punti. Qua non riesco a guessare facilmente cosa intendi. Meglio se espandi.
Metti un protocollo binario dentro un'altro progettato per una cosa totalmente diversa, ti pare intuitivo?
- sub ottimale: perché non progettare un protocollo migliore del DNS, invece?
Implementare un sistema nuovo di questo tipo che rimpiazzi il DNS su scala mondiale e' un task massivo.
Allora è meglio iniziare subito! ;-)
- genera un single point of failure / accentra in oligopoli
Questa e' la direzione che sta prendendo internet, pero'.
E speriamo di riuscire a virare in tempo! Non aumenterei ulteriormente l'accentramento, se posso evitarlo. Anzi dovremmo lavorare per ridurlo!
- non mi fido di CloudFlare (che ha anche accesso ad altri dati personali, in quanto CDN)
Se ti fidi dei ToS, come ho scritto in questo thread, puoi constatare che sono dei ToS abbastanza buoni. Se non ti fidi dei ToS, puoi vedere se c'e' un servizio alternativo oppure puoi deciderti di fidarti di piu' del tuo ISP. (Alla fine, di qualcuno ti devi fidare per quasi tutte le applicazioni piu' complesse di `ping 127.0.0.1`, ed e' giusto che sia tu a decidere di chi fidarti e di chi non fidarti.)
Non mi fido del ToS di Cloudflare e mi fido di più del mio ISP.
Se l'obbiettivo è proteggere gli utenti da MitM DNS da parte di ISP come Vodafone, la soluzione non è tecnica, ma politica: bisogna semplicemente vietare il MitM DNS.
Riguardo al vietare il MitM DNS, Quintarelli aveva scritto "non e' roba da denuncia, in assenza di uno specifico ordine motivato dell'autorita' giudiziaria?" e "credo sia la direttiva 2002/58/EC, ma i giuristi possono essere piu' precisi...".
Quindi ci serve una mano da un giurista per capire meglio!
Sottoscrivo. Assolutamente.
Simone
Giacomo
participants (3)
-
Giacomo Tesio -
Marco Mellia -
Simone Basso