privacyguides.org/dns-overview.it.md at 4da25bc39a4138eb2422c9e0ed34519c303ce0bd

mirror of https://github.com/privacyguides/privacyguides.org.git synced 2024-10-01 01:35:57 -04:00

Privacy Guides [bot] 7b6a158e4d

Add Crowdin Translations (#2026 )

Co-authored-by: Crowdin Bot <support+bot@crowdin.com>
Co-authored-by: Jonah Aragon <jonah@triplebit.net>

2023-02-24 16:47:54 -06:00

20 KiB

Raw Blame History

title	icon
Panoramica DNS	material/dns

Il Domain Name System è 'l'elenco telefonico di Internet'. Il DNS traduce i nomi di dominio in indirizzi IP, in modo che i browser e altri servizi possano caricare le risorse internet mediante un network decentralizzato di server.

Che cos'è il DNS?

Quando visiti un sito, viene restituito un indirizzo numerico. Per esempio, quando visiti privacyguides.org,viene restituito l'indirizzo 192.98.54.105.

Il DNS esiste dai primi giorni di Internet. Le richieste DNS fatte da e verso i server DNS non sono crittografate generalmente. In un ambiente residenziale, un cliente riceve i server dall'ISP mediante DHCP.

Le richieste DNS non crittografate possono essere facilmente sorvegliate e modificate in transito. In alcune parti del mondo, agli ISP viene ordinato di eseguire un filtraggio primitivo del DNS. Quando viene effettuata una richiesta dell'indirizzo IP di un dominio bloccato, il server potrebbe non rispondere o fornire un indirizzo IP differente. Dato che il protocollo DNS non è crittografato, l'ISP (o qualsiasi operatore di rete) può utilizzare la DPI per monitorare le richieste. Gli ISP possono inoltre bloccare richieste aventi caratteristiche comuni, indipendentemente dal server DNS utilizzato. DNS non crittografato utilizza sempre la porta 53 e l'UDP.

Di seguito, discutiamo e foniamo un tutorial per dimostrare cosa un osservatore esterno potrebbe vedere in entrambi i casi di DNS crittografato e non.

DNS non crittografato

Utilizzando tshark (parte del progetto Wireshark) possiamo monitorare e registrare il flusso di pacchetti Internet. Il comando registra 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
```
Possiamo poi utilizzare il comando dig (Linux, MacOS ecc.) o nslookup (Windows) per inviare la ricerca DNS ad entrambi i server. Software come i browser web effettuano queste ricerche automaticamente, a meno che non venga specificato di utilizzare DNS crittografato.

=== "Linux, macOS"
```
 ```
 dig +noall +answer privacyguides.org @1.1.1.1
 dig +noall +answer privacyguides.org @8.8.8.8
 ```
```
=== "Windows"
```
 ```
 nslookup privacyguides.org 1.1.1.1
 nslookup privacyguides.org 8.8.8.8
 ```
```

Successivamente vogliamo analizzare i risultati:

=== "Wireshark"

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

=== "tshark"

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

Se esegui il comando Wireshark sopra citato, il pannello superiora mostra i "frame", mentre quello inferiore mostra tutti i dati riguardanti il "frame" selezionato. Soluzioni di filtraggio e monitoraggio aziendali (come quelle acquistate dalle amministrazioni pubbliche) possono eseguire il processo automaticamente, senza interazione umana, e aggregare i "frame" per produrre dati statistici utili all'osservatore della rete.

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

Un osservatore potrebbe modificare uno qualsiasi di questi pacchetti.

Che cos'è il "DNS crittografato"?

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

DNSCrypt

DNSCrypt fu uno dei primi metodi per la crittografia delle query DNS. DNSCrypt opera sulla porta 443 e funziona con entrambi i protocolli di trasporto TCP e UDP. DNSCrypt non è mai stato sottoposto alla Internet Engineering Task Force (IETF), né è passato attraverso il processo di Request for Comments (RFC, "richiesta di commenti"); non è mai stato quindi ampiamente utilizzato al di fuori di alcune implementazioni. DI conseguenza, è stato largamente rimpiazzato dal più popolare DNS over HTTPS.

DNS over TLS (DoT)

DNS over TLS è un altro metodo per criptare 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. Negli ultimi anni la preferenza del settore si è spostata da DoT a DoH, in quanto DoT è protocollo complesso e presenta una conformità variabile all'RFC tra le implementazioni esistenti. DoT opera anche su una porta dedicata 853 che può essere facilmente bloccata da firewall restrittivi.

DNS over HTTPS (DoH)

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

L'implementazione nativa di DoH è presente in iOS 14, macOS 11, Microsoft Windows e Android 13 (tuttavia, non sarà abilitata per impostazione predefinita). Il supporto generale per i desktop Linux è in attesa dell'implementazione di systemd quindi l'installazione di software di terze parti è ancora necessaria.

Cosa può vedere un esterno?

In questo esempio registreremo ciò che accade quando facciamo una richiesta al DoH:

Per prima cosa, avviare tshark:

tshark -w /tmp/dns_doh.pcap -f "tcp port https and host 1.1.1.1"

In secondo luogo, fare una richiesta con curl:

curl -vI --doh-url https://1.1.1.1/dns-query https://privacyguides.org

Dopo aver effettuato la richiesta, possiamo interrompere la cattura dei pacchetti con CTRL + C.
Analizzare i risultati con Wireshark:
```
wireshark -r /tmp/dns_doh.pcap
```

Possiamo vedere l'instaurazione della connessione e l'handshake TLS che si verifica con qualsiasi connessione crittografata. Osservando i pacchetti "application data" che seguono, nessuno di essi contiene il dominio richiesto o l'indirizzo IP restituito.

Perché non dovrei utilizzare un DNS criptato?

Nei luoghi in cui vige il filtraggio (o la censura) di Internet, la visita a risorse proibite può avere conseguenze che vanno considerate nel modello di minaccia. Noi non suggeriamo l'uso di DNS criptati per questo scopo. Utilizza Tor o una VPN. Se utilizzi una VPN, usufruisci dei server DNS della VPN. Quando si utilizza una VPN, ci si affida già a loro per tutte le attività di rete.

Quando si effettua una ricerca DNS, in genere è perché si vuole accedere a una risorsa. Di seguito verranno illustrati alcuni dei metodi che possono rivelare le attività di navigazione dell'utente anche quando si utilizza un DNS crittografato:

Indirizzo IP

Il modo più semplice per determinare l'attività di navigazione potrebbe essere quello di esaminare gli indirizzi IP a cui accedono i dispositivi. Ad esempio, se l'osservatore sa che privacyguides.org si trova all'indirizzo 198.98.54.105, e il tuodispositivo sta richiedendo dati da 198.98.54.105, è molto probabile che tu stia visitando Privacy Guides.

Questo metodo è utile solo quando l'indirizzo IP appartiene a un server che ospita solo pochi siti web. Inoltre, non è molto utile se il sito è ospitato su una piattaforma condivisa (ad esempio, Github Pages, Cloudflare Pages, Netlify, WordPress, Blogger, ecc). Inoltre, non è molto utile se il server è ospitato dietro un reverse proxy , molto comune nella moderna Internet.

Indicazione del nome del server (Server Name Indication, 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 un'altra protezione attacco denial-of-service.

Avviare nuovamente la cattura con tshark. Abbiamo aggiunto un filtro con il nostro indirizzo IP in modo da non catturare molti pacchetti:
```
tshark -w /tmp/pg.pcap port 443 and host 198.98.54.105
```
Poi visitiamo https://privacyguides.org.
Dopo aver visitato il sito web, vogliamo interrompere la cattura dei pacchetti con CTRL + C.
Poi vogliamo analizzare i risultati:
```
wireshark -r /tmp/pg.pcap
```
Vedremo la creazione della connessione, seguita dall'handshake TLS per il sito web di Privacy Guides. Intorno al frame 5. vedrai "Client Hello".

Espandi il triangolo ▸ accanto a ciascun 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

Possiamo vedere il valore SNI che rivela il sito web che stiamo visitando. Il comando tshark può fornire 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 si utilizzano server "DNS criptati", il dominio sarà probabilmente divulgato tramite SNI. Il protocollo TLS v1.3 porta con sé Encrypted Client Hello, che impedisce questo tipo di fuga d'informazioni.

I governi, in particolare Cina e Russia, hannogià iniziato a bloccarlo o hanno espresso il desiderio di farlo. Recentemente, la Russia ha iniziato a bloccare i siti web stranieri che utilizzano lo standard HTTP/3. Questo perché il protocollo QUIC che fa parte di HTTP/3 richiede che anche ClientHello sia criptato.

Online Certificate Status Protocol (OCSP)

Un altro modo in cui il browser può rivelare le attività di navigazione è il protocollo Online Certificate Status Protocol. Quando si visita un sito web HTTPS, il browser potrebbe verificare se il certificato del sito web è stato revocato. Questo avviene generalmente tramite il protocollo HTTP, il che significa che è non crittografato.

La richiesta OCSP contiene il certificato "numero seriale", che è unico. Viene inviato al "responder OCSP" per verificarne lo stato.

Possiamo simulare quello che farebbe un browser usando il comando openssl.

Ottenere il certificato del server e utilizzare sed per conservare solo 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

Ottenere il certificato intermedio. Autorità di certificazione (CA) di solito non firmano direttamente un certificato, ma utilizzano un cosiddetto certificato "intermedio".
```
openssl s_client -showcerts -connect privacyguides.org:443 < /dev/null 2>&1 |
    sed -n '/^-*BEGIN/,/^-*END/p' > /tmp/pg_and_intermediate.cert
```
Il primo certificato in pg_and_intermediate.cert è in realtà il certificato del server dal passo 1. Possiamo usare di nuovo sed per cancellare fino alla prima istanza di END:
```
sed -n '/^-*END CERTIFICATE-*$/!d;:a n;p;ba' \
    /tmp/pg_and_intermediate.cert > /tmp/intermediate_chain.cert
```
Ottenere il responder 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 si desidera visualizzare tutti i dettagli del certificato, è possibile utilizzare:
```
openssl x509 -text -noout -in /tmp/pg_server.cert
```

Avviare l'acquisizione dei pacchetti:

tshark -w /tmp/pg_ocsp.pcap -f "tcp port http"

Effettuare la richiesta OCSP:

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

Aprire l'acquisizione:

wireshark -r /tmp/pg_ocsp.pcap

Il protocollo "OCSP" prevede due pacchetti: una "Richiesta" e una "Risposta". Per la "Richiesta" possiamo vedere il "numero seriale" espandendo il triangolo ▸ accanto a ciascun campo:

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

Per la "Risposta" possiamo vedere anche il "numero seriale":

▸ Online Certificate Status Protocol
  ▸ responseBytes
    ▸ BasicOCSPResponse
      ▸ tbsResponseData
        ▸ responses: 1 item
          ▸ SingleResponse
            ▸ certID
              serialNumber

Oppure utilizzare tshark per filtrare i pacchetti per il numero seriale:

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

Se l'osservatore della rete dispone del certificato pubblico, che è pubblicamente disponibile, può abbinare il numero seriale a quel certificato e quindi determinare il sito che stai visitando. Il processo può essere automatizzato e può associare gli indirizzi IP ai numeri seriali. È anche possibile controllare i log di Certificate Transparency per il numero seriale.

Dovrei utilizzare un DNS criptato?

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

graph TB
    Inizio[Inizio] --> anonymous{Cerchi di<br> essere anonimo?}
    anonymous--> | Sì | tor(Usa Tor)
    anonymous --> | No | censorship{Evitare<br> la censura?}
    censorship --> | Sì | vpnOrTor(Usa<br> VPN o Tor)
    censorship --> | No | privacy{Vuoi privacy<br> dall'ISP?}
    privacy --> | Sì | vpnOrTor
    privacy --> | No | obnoxious{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 criptato con una terza parte dovrebbe essere usato solo per aggirare i reindirizzamenti e il blocco DNS basilare quando puoi essere sicuro che non ci saranno conseguenze o sei interessato a un provider che faccia qualche filtro rudimentale.

Elenco dei server DNS consigliati{.md-button}

Che cosa sono le DNSSEC?

Le Domain Name System Security Extensions (DNSSEC) sono una funzione del DNS che autentica le risposte alle ricerche di nomi di dominio. Non forniscono una protezione della privacy per tali ricerche, ma piuttosto impedisce agli aggressori di manipolare o avvelenare le risposte alle richieste DNS.

In altre parole, le DNSSEC firmano digitalmente i dati per garantirne la validità. Per garantire una ricerca sicura, la firma avviene a ogni livello del processo di ricerca DNS. Di conseguenza, tutte le risposte del DNS sono affidabili.

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

Le DNSSEC implementano una politica di firma digitale gerarchica su tutti i livelli del DNS. Ad esempio, nel caso di una ricerca su privacyguides.org, un server DNS root firmerà una chiave per il server dei nomi .org e il server dei nomi .org firmerà una chiave per il server dei nomi autoritativo privacyguides.org.

Adattato da DNS Security Extensions (DNSSEC) overview (Panoramica delle DNS Security Extensions (DNSSEC)) di Google e DNSSEC: An Introduction (DNSSEC: una introduzione) di Cloudflare, entrambi con licenza CC BY 4.0.

Che cos'è la minimizzazione del QNAME?

Un QNAME è un "nome qualificato", ad esempio privacyguides.org. La minimizzazione del QNAME riduce la quantità di informazioni inviate dal server DNS al server dei nomi autoritativi.

Invece di inviare l'intero dominio privacyguides.org, la minimizzazione del QNAME significa che il server DNS chiederà tutti i record che terminano in .org. Ulteriori descrizioni tecniche sono definite in RFC 7816.

Che cos'è la sottorete client EDNS (EDNS Client Subnet, ECS)?

La sottorete client EDNS è un metodo che consente a un resolver DNS ricorsivo di specificare una sottorete per l'host o il client che sta effettuando la query DNS.

Ha lo scopo di "velocizzare" la consegna dei dati fornendo al client una risposta che appartiene a un server vicino, come ad esempio una rete di distribuzione di contenuti , spesso utilizzata per lo streaming video e per servire applicazioni web in JavaScript.

Questa funzione ha un costo in termini di privacy, in quanto comunica al server DNS alcune informazioni sulla posizione del client.

20 KiB Raw Blame History