Vai al contenuto

Panoramica DNS

Il Sistema dei Nomi di Dominio (DNS) è la 'rubrica dell'Internet'. Il DNS traduce i nomi di dominio in indirizzi IP, così che i browser e altri servizi possano caricare le risorse di Internet, tramite una rete decentralizzata di server.

Cos'è il DNS?

Quando visiti un sito web, è restituito un indirizzo numerico. Ad esempio, quando visiti privacyguides.com, è restituito l'indirizzo 192.98.54.105.

Il DNS esiste dagli albori di Internet. Le richieste DNS da e verso i server DNS non sono generalmente crittografate. In un ambiente residenziale, un cliente riceve dei server dall'ISP tramite DHCP.

Le richieste DNS non crittografate sono facilmente sorvegliabili e modificabili durante il transito. In alcune parti del mondo, gli ISP devono eseguire un primitivo filtraggio DNS. Quando richiedi il blocco dell'indirizzo IP di un dominio, il server potrebbe non rispondere o fornire un indirizzo IP differente. Poiché il protocollo DNS non è crittografato, l'ISP (o qualsiasi operatore della rete), può utilizzare la DPI per monitorare le richieste. Gli ISP possono inoltre bloccare le richieste secondo caratteristiche comuni, indipendentemente da quale server DNS è utilizzato. Il DNS non crittografato utilizza sempre la porta 53, e utilizza sempre UDP.

Di seguito, discutiamo e forniamo un tutorial per provare ciò che un osservatore esterno possa vedere, utilizzando il DNS non crittografato e il DNS crittografato.

DNS non crittografato

  1. Utilizzando tshark (parte del progetto di Wireshark), possiamo monitorare e registrare il flusso di pacchetti di Internet. Il comando registra i pacchetti che soddisfano le regole specificate:

    tshark -w /tmp/dns.pcap udp port 53 and host 1.1.1.1 or host 8.8.8.8
    
  2. Quindi, possiamo utilizzare dig (Linux, MacOS, etc.) o nslookup (Windows) per inviare la ricerca DNS a entrambi i server. I software come i browser web, svolgono automaticamente tali ricerche, a meno che non siano configurati per utilizzare il DNS crittografato.

    dig +noall +answer privacyguides.org @1.1.1.1
    dig +noall +answer privacyguides.org @8.8.8.8
    
    nslookup privacyguides.org 1.1.1.1
    nslookup privacyguides.org 8.8.8.8
    
  3. Successivamente, vogliamo analizzare i risultati:

    wireshark -r /tmp/dns.pcap
    
    tshark -r /tmp/dns.pcap
    

Se esegui il comando di Wireshark precedente, il pannello superiore mostra i "quadri", mentre quello inferiore mostra tutti i dati sul quadro selezionato. Le soluzioni di filtraggio e monitoraggio aziendali (come quelle acquistate dai governi), possono svolgere il processo automaticamente, senza l'interazione umana, e possono aggregare tali quadri per produrre dati statistici, utili all'osservatore della rete.

N. Tempo Fonte Destinazione Protocollo Lunghezza Info
1 0.000000 192.0.2.1 1.1.1.1 DNS 104 Richiesta standard 0x58ba A privacyguides.org OPT
2 0.293395 1.1.1.1 192.0.2.1 DNS 108 Risposta standard alla richiesta 0x58ba A privacyguides.org A 198.98.54.105 OPT
3 1.682109 192.0.2.1 8.8.8.8 DNS 104 Richiesta standard 0xf1a9 A privacyguides.org OPT
4 2.154698 8.8.8.8 192.0.2.1 DNS 108 Risposta standard alla richiesta 0xf1a9 A privacyguides.org A 198.98.54.105 OPT

Un osservatore potrebbe modificare uno qualsiasi di questi pacchetti.

Cos'è il "DNS crittografato"?

Il DNS crittografato può riferirsi a uno dei numerosi protocolli, i più comuni dei quali sono:

DNSCrypt

DNSCrypt fu uno dei primi metodi per la crittografia delle richieste DNS. DNSCrypt opera sulla porta 443 e funziona con entrambi i protocolli di trasporto TCP e UDP. DNSCrypt non è stato mai inviato alla Task Force Ingegneristica di Internet (IETF), né ha superato il processo di Richiesta dei Commenti (RFC), quindi non è stato utilizzato ampiamente, al di fuori di poche implementazioni. Di conseguenza, è stato ampiamente sostituito dal più popolare DNS-over-HTTPS.

DNS-over-TLS (DoT)

DNS-over-TLS è un altro metodo per crittografare le comunicazioni DNS, definito in RFC 7858. Il supporto è stato implementato per la prima volta in Android 9, iOS 14 e su Linux in systemd-resolved, nella versione 237. La preferenza nel settore è stata allontanarsi dal DoT al DoH negli ultimi anni, poiché DoT è un protocollo complesso, avente una conformità variabile al RFC tra le implementazioni che esistono. Inoltre, DoT opera su una porta 853 dedicata, facilmente bloccabile dai firewall restrittivi.

DNS-over-HTTPS (DoH)

DNS-over-HTTPS, come definito in RFC 8484, impacchetta le richieste nel protocollo HTTP/2 e fornisce sicurezza con HTTPS. Il supporto è stato aggiunto per la prima volta nei browser web come Firefox 60 e Chrome 83.

L'implementazione nativa di DoH è arrivata su iOS 14, macOS 11, Microsoft Windows e Android 13 (tuttavia, non sarà abilitata di default). Il supporto generale per i desktop Linux è in attesa dell'implementazione di systemd, quindi è necessario installare un software di terze parti.

Cosa può vedere una parte esterna?

In questo esempio registreremo cosa si verifica quando effettuiamo una richiesta DoH:

  1. Prima di tutto, avvia tshark:

    tshark -w /tmp/dns_doh.pcap -f "tcp port https and host 1.1.1.1"
    
  2. Poii, effettua una richiesta con curl:

    curl -vI --doh-url https://1.1.1.1/dns-query https://privacyguides.org
    
  3. Dopo aver effettuato la richiesta, possiamo interrompere la cattura del pacchetto con CTRL + C.

  4. Analizza i risultati su Wireshark:

    wireshark -r /tmp/dns_doh.pcap
    

Possiamo vedere l'instaurazione della connessione e l'handshake TLS, che si verificano con qualsiasi connessione crittografata. Osservando i successivi pacchetti di "dati dell'applicazione", nessuno di essi contiene il dominio richiesto o l'indirizzo IP restituito.

Perché non dovrei utilizzare il DNS crittografato?

Nei luoghi in cui esiste il filtraggio (o censura) di Internet, visitare le risorse proibite potrebbe avere delle conseguenze, che dovresti considerare nel tuo modello di minaccia. Noi non suggeriamo di utilizzare il DNS crittografato per tale scopo. Utilizza Tor o una VPN. Se stai utilizzando una VPN, dovresti utilizzare i server DNS della tua VPN. Utilizzando una VPN, stai già affidando loro tutta la tua attività di rete.

Quando effettuiamo una ricerca DNS, generalmente è perché desideriamo accedere a una risorsa. Di seguito, discuteremo di alcuni dei metodi che potrebbero divulgare le tue attività di navigazione, anche utilizzando il DNS crittografato:

Indirizzo IP

Il metodo più semplice per determinare l'attività di navigazione, potrebbe essere quello di esaminare gli indirizzi IP accessibili ai tuoi dispositivi. Ad esempio, se l'osservatore sa che privacyguides.org si trova a 198.98.54.105 e il tuo dispositivo sta richiedendo dei dati da 198.98.54.105, è molto probabile che tu stia visitando Privacy Guides.

Questo metodo è utile soltanto quando l'indirizzo IP appartiene a un server che ospita soltanto alcuni siti web. Non è molto utile se il sito è ospitato su una piattaforma condivisa (es., GitHub Pages, Cloudflare Pages, Netlify, WordPress, Blogger, etc.). Inoltre, non è molto utile se il server è ospitato dietro un proxy inverso, molto comune sull'Internet moderno.

Indicazione del Nome del Server (SNI)

L'Indicazione del Nome del Server è tipicamente utilizzata quando un indirizzo IP ospita molti siti web. Potrebbe trattarsi di un servizio come Cloudflare, o di qualche altra protezione dagli attacchi di Denial-of-service.

  1. Riavvia la cattura con tshark. Abbiamo aggiunto un filtro con il nostro indirizzo IP, così che tu non catturi molti pacchetti:

    tshark -w /tmp/pg.pcap port 443 and host 198.98.54.105
    
  2. Quindi, visitiamo https://privacyguides.org.

  3. Dopo aver visitato il sito web, vogliamo interrrompere la cattura dei pacchetti, con CTRL + C.

  4. Poi, vogliamo analizzare i risultati:

    wireshark -r /tmp/pg.pcap
    

    Vedremo l'instaurazione della connessione, seguita dall'handshake TLS per il sito web di Privacy Guides. Intorno al quadro 5, visualizzerai un "Saluto del Client".

  5. Espandi il triangolo ▸ affianco a ogni campo:

    ▸ Transport Layer Security
      ▸ TLSv1.3 Record Layer: Handshake Protocol: Client Hello
        ▸ Handshake Protocol: Client Hello
          ▸ Extension: server_name (len=22)
            ▸ Server Name Indication extension
    
  6. Possiamo vedere il valore SNI che rivela il sito web che stiamo visitando. Il comando tshark può darti direttamente il valore per tutti i pacchetti contenenti un valore SNI:

    tshark -r /tmp/pg.pcap -Tfields -Y tls.handshake.extensions_server_name -e tls.handshake.extensions_server_name
    

Ciò significa che, anche se stiamo utilizzando dei server "DNS Crittografati", il dominio sarà probabilmente divulgato tramite SNI. Il protocollo TLS v1.3 porta iil Saluto Crittografato del Client, che impedisce questo genere di fughe di dati.

I governi, in particolare la Cina e la Russia, hanno già iniziato a bloccarlo o espresso il desiderio di volerlo fare. Di recente, la Russia ha iniziato a bloccare i siti web stranieri, che utilizzano lo standard HTTP/3. Questo perché il protocollo QUIC, parte di HTTP/3, richiede che anche ClientHello sia crittografato.

Protocollo di Stato del Certificato Online (OCSP)

Un altro modo in cui il tuo browser può divulgare le tue attività di navigazione è con il Protocollo di Stato del Certificato Online. Visitando un sito web HTTPS, il browser potrebbe verificare se il certificato del sito web è stato revocato. Ciò avviene generalmente tramite il protocollo HTTP, a significare che non è crittografato.

La richiesta OCSP contiene il "numero di serie" del certificato, che è univoco. Viene inviato al "risponditore OCSP", per poterne verificare lo stato.

Possiamo simulare ciò che un browser farebbe, utilizzando il comando openssl.

  1. Ottieni il certificato del server e utilizza sed per mantenere soltanto la parte importante e scriverla in un file:

    openssl s_client -connect privacyguides.org:443 < /dev/null 2>&1 |
        sed -n '/^-*BEGIN/,/^-*END/p' > /tmp/pg_server.cert
    
  2. Ottieni il certificato intermedio. Normalmente, le Autorità di Certificazione (CA) non firmano direttamente un certificato; utilizzano ciò che è noto come certificato "intermedio".

    openssl s_client -showcerts -connect privacyguides.org:443 < /dev/null 2>&1 |
        sed -n '/^-*BEGIN/,/^-*END/p' > /tmp/pg_and_intermediate.cert
    
  3. Il primo certificato in pg_and_intermediate-.cert è in realtà il certificato del server dal passaggio 1. Possiamo riutilizzare sed per eliminare fino alla prima istanza di END:

    sed -n '/^-*END CERTIFICATE-*$/!d;:a n;p;ba' \
        /tmp/pg_and_intermediate.cert > /tmp/intermediate_chain.cert
    
  4. Ottieni il risponditore OCSP per il certificato del server:

    openssl x509 -noout -ocsp_uri -in /tmp/pg_server.cert
    

    Il nostro certificato mostra il risponditore del certificato Lets Encrypt. Se desideri visualizzare tutti i dettagli del certificato, puoi utilizzare:

    openssl x509 -text -noout -in /tmp/pg_server.cert
    
  5. Avvia la cattura dei pacchetti:

    tshark -w /tmp/pg_ocsp.pcap -f "tcp port http"
    
  6. Effettua la richiesta OCSP:

    openssl ocsp -issuer /tmp/intermediate_chain.cert \
                 -cert /tmp/pg_server.cert \
                 -text \
                 -url http://r3.o.lencr.org
    
  7. Apri la cattura:

    wireshark -r /tmp/pg_ocsp.pcap
    

    Ci sarranno due pacchetti con il protocollo "OCSP": una "Richiesta" e una "Risposta". Per la "Richiesta", possiamo visualizzare il "numero di serie" espandendo il triangolo ▸ affianco a ogni campo:

     Online Certificate Status Protocol
       tbsRequest
         requestList: 1 item
           Request
             reqCert
              serialNumber
    

    Anche per la "Risposta" possiamo visualizzare il "numero di serie":

     Online Certificate Status Protocol
       responseBytes
         BasicOCSPResponse
           tbsResponseData
             responses: 1 item
               SingleResponse
                 certID
                  serialNumber
    
  8. Altrimenti, utilizza tshark per filtrare i pacchetti per il Numero di Serie:

    tshark -r /tmp/pg_ocsp.pcap -Tfields -Y ocsp.serialNumber -e ocsp.serialNumber
    

Se l'osservatore della rete ha il certificato pubblico, disponibile pubblicamente, può abbinare il numero di serie a tale certificato e, dunque, determinare da ciò il sito che stai visitando. Il processo è automatizzabile e può associare gli indirizzi IP ai numeri di serie. Inoltre, puoi verificare i registri di Trasparenza del Certificato per il numero di serie.

Dovrei utilizzare il DNS crittografato?

Abbiamo creato questo diagramma di flusso per descrivere quando dovresti utilizzare il DNS crittografato:

graph TB
    Inizio[Inizio] --> anonymous{"Cerchi di<br> essere anonimo?"}
    anonymous --> | Sì | tor(Usa Tor)
    anonymous --> | No | censura{"Vuoi evitare<br> la censura?"}
    censura--> | Sì | vpnOrTor(Usa<br> VPN o Tor)
    censura --> | No | privacy{"Vuoi privacy<br> dall'ISP?"}
    privacy --> | Sì | vpnOrTor
    privacy --> | No | obnoxious{"L'ISP fa<br> reindirizzamenti<br> odiosi?"}
    obnoxious --> | Sì | encryptedDNS(Usa<br> DNS criptato<br> di terze parti)
    obnoxious --> | No | ispDNS{"L'ISP supporta<br> DNS criptato?"}
    ispDNS --> | Sì | useISP(Usa<br> DNS criptato<br> con l'ISP)
    ispDNS --> | No | nothing(Non fare nulla)

Il DNS Criittografato con unaa terza parte dovrebbe sempre essere utilizzato per aggirare i reindirizzamenti e il blocco DNS di base, quando puoi assicurarti che non sussisteranno conseguenze, o se sei interessato a un fornitore che svolge del filtraggio rudimentale.

Elenco dei server DNS consigliati

Cosa sono le DNSSEC?

Le Estensioni di Sicurezza del Sistema di Nome del Dominio (DNSSEC), sono una funzionalità del DNS che autentica le risposte per le ricerche del nome di dominio. Non forniscono protezione della privacy per tali ricerche, ma impediscono ai malintenzionati di manipolare o avvelenare le risposte alle richieste DNS.

In altre parole, le DNSSEC firmano digitalmente i dati, per aiutare ad assicurarne la validità. Per poter garantire una ricerca sicura, la firma si verifica a ogni livello nel processo di ricerca del DNS. Di conseguenza, tutte le risposte dal DNS sono affidabili.

Il processo di firma delle DNSSEC è simile a quello di firma di un documento legale, con una penna; il firmatario utilizza una firma univoca, che nessun altro può creare e un esperto del tribunale può osservare tale firma e verificare che il documento sia stato firmato da una data persona. Queste firme digitali garantiscono che i dati non siano stati manomessi.

Le DNSSEC implementano una politica di firma digitale gerarchica, tra tutti i livelli del DNS. Ad esempio, nel caso di una ricerca di privacyguides.com, un server DNS di radice firmerebbe una chiave per il nome del server .org, e il nome del server .org, dunque, firmerebbe un chiave per quello autoritativo di privacyguides.org.

Adattato dalla panoramica sulle Estensioni di Sicurezza DNS (DNSSEC) by Google and DNSSEC: Un'introduzione, di Cloudflare, entrambi sotto licenza CC BY 4.0.

Cos'è la minimizzazione dei QNAME?

Un QNAME è un "nome qualificato", ad esempio, privacyguides.com. La minimizzazione del QNAME riduce la quantità di informazioni inviate dal server DNS all'assistente autoritativo del nome.

Invece di inviare l'intero dominio privacyguides.org, la minimizzazione del QNAME preclude che il server DNS chiederà tutti i registri che terminano per .org. Un'ulteriore descrizione tecnica è definita nel RFC 7816.

Cos'è la Sottorete del Client EDNS (ECS)?

La Sottorete del Client EDNS è un metodo per un risolutore DNS ricorsivo, per specificare una sotto-rete per l'host o il client che sta effettuando la richiesta DNS.

Esiste per "velocizzare" la consegna dei dati, dando al client una risposta appartenente a un server nei suoi pressi, come una rete di consegna dei contenuti, spesso utilizzate nello streaming di video e per servire app web in JavaScript.

Questa funzionalità non ha un costo in termini di privacy, poiché comunica al server DNS alcune informazioni sulla posizione del client.

*[2FA] (A2F): Autenticazione a 2 Fattori

Stai visualizzando la versione italiana di Privacy Guides, tradotta dal nostro fantastico team linguistico su Crowdin. Se noti un errore o vedi sezioni non tradotte in questa pagina, ti invitiamo a dare una mano! Per ulteriori informazioni e consigli consulta la nostra guida alla traduzione.

You're viewing the Italian copy of Privacy Guides, translated by our fantastic language team on Crowdin. If you notice an error, or see any untranslated sections on this page, please consider helping out! For more information and tips see our translation guide.