mirror of
https://github.com/privacyguides/privacyguides.org.git
synced 2025-07-29 06:41:03 +00:00
Download Translations from Crowdin (#2054)
This commit is contained in:
Crowdin Bot
104
i18n/it/advanced/communication-network-types.md
Normal file
104
i18n/it/advanced/communication-network-types.md
Normal file
@@ -0,0 +1,104 @@
|
||||
---
|
||||
title: "Tipi di reti di comunicazione"
|
||||
icon: 'material/transit-connection-variant'
|
||||
---
|
||||
|
||||
Esistono diverse architetture di rete comunemente usate per trasmettere messaggi tra le persone. Queste reti possono fornire garanzie di privacy diverse, motivo per cui vale la pena considerare il [modello di minaccia](../basics/threat-modeling.md) quando si decide quale app utilizzare.
|
||||
|
||||
[Messaggistica istantanea consigliata](../real-time-communication.md ""){.md-button}
|
||||
|
||||
## Reti centralizzate
|
||||
|
||||
{ align=left }
|
||||
|
||||
I servizi di messaggistica centralizzati sono quelli in cui tutti i partecipanti si trovano sullo stesso server o rete di server controllati dalla stessa organizzazione.
|
||||
|
||||
Alcuni servizi di messaggistica self-hosted consentono di configurare il proprio server. Il self-hosting può fornire ulteriori garanzie di privacy, come l'assenza di log o l'accesso limitato ai metadati (dati su chi parla con chi). I servizi centralizzati self-hosted sono isolati e tutti devono essere sullo stesso server per comunicare.
|
||||
|
||||
**Vantaggi:**
|
||||
|
||||
- Le nuove funzionalità e le modifiche possono essere implementate più rapidamente.
|
||||
- È più facile iniziare e trovare contatti.
|
||||
- Gli ecosistemi con le caratteristiche più mature e stabili sono più facili da programmare in un software centralizzato.
|
||||
- I problemi di privacy possono essere ridotti quando ci si affida a un server in self-hosting.
|
||||
|
||||
**Svantaggi:**
|
||||
|
||||
- Possono includere [controllo o accesso limitato](https://drewdevault.com/2018/08/08/Signal.html). Questo può includere cose come:
|
||||
- Il [divieto di connettere client di terze parti](https://github.com/LibreSignal/LibreSignal/issues/37#issuecomment-217211165) alla rete centralizzata che potrebbero fornire una migliore personalizzazione o esperienza. Spesso definito nei Termini e condizioni d'uso.
|
||||
- Documentazione scarsa o assente per gli sviluppatori di terze parti.
|
||||
- La [proprietà](https://web.archive.org/web/20210729191953/https://blog.privacytools.io/delisting-wire/), la politica sulla privacy e le operazioni del servizio possono cambiare facilmente quando un'unica entità lo controlla, compromettendo potenzialmente il servizio in un secondo momento.
|
||||
- Il self-hosting richiede impegno e conoscenza di come impostare un servizio.
|
||||
|
||||
## Reti federate
|
||||
|
||||
{ align=left }
|
||||
|
||||
Federated messengers use multiple, independent, decentralized servers that are able to talk to each other (email is one example of a federated service). Federation allows system administrators to control their own server and still be a part of the larger communications network.
|
||||
|
||||
When self-hosted, members of a federated server can discover and communicate with members of other servers, although some servers may choose to remain private by being non-federated (e.g., work team server).
|
||||
|
||||
**Vantaggi:**
|
||||
|
||||
- Allows for greater control over your own data when running your own server.
|
||||
- Allows you to choose whom to trust your data with by choosing between multiple "public" servers.
|
||||
- Often allows for third-party clients which can provide a more native, customized, or accessible experience.
|
||||
- Server software can be verified that it matches public source code, assuming you have access to the server or you trust the person who does (e.g., a family member).
|
||||
|
||||
**Svantaggi:**
|
||||
|
||||
- Adding new features is more complex because these features need to be standardized and tested to ensure they work with all servers on the network.
|
||||
- Due to the previous point, features can be lacking, or incomplete or working in unexpected ways compared to centralized platforms, such as message relay when offline or message deletion.
|
||||
- Some metadata may be available (e.g., information like "who is talking to whom," but not actual message content if E2EE is used).
|
||||
- Federated servers generally require trusting your server's administrator. They may be a hobbyist or otherwise not a "security professional," and may not serve standard documents like a privacy policy or terms of service detailing how your data is used.
|
||||
- Server administrators sometimes choose to block other servers, which are a source of unmoderated abuse or break general rules of accepted behavior. This will hinder your ability to communicate with members of those servers.
|
||||
|
||||
## Reti peer-to-peer
|
||||
|
||||
{ align=left }
|
||||
|
||||
P2P messengers connect to a [distributed network](https://en.wikipedia.org/wiki/Distributed_networking) of nodes to relay a message to the recipient without a third-party server.
|
||||
|
||||
Clients (peers) usually find each other through the use of a [distributed computing](https://en.wikipedia.org/wiki/Distributed_computing) network. Examples of this include [Distributed Hash Tables](https://en.wikipedia.org/wiki/Distributed_hash_table) (DHT), used by [torrents](https://en.wikipedia.org/wiki/BitTorrent_(protocol)) and [IPFS](https://en.wikipedia.org/wiki/InterPlanetary_File_System) for example. Another approach is proximity based networks, where a connection is established over WiFi or Bluetooth (for example, Briar or the [Scuttlebutt](https://www.scuttlebutt.nz) social network protocol).
|
||||
|
||||
Once a peer has found a route to its contact via any of these methods, a direct connection between them is made. Although messages are usually encrypted, an observer can still deduce the location and identity of the sender and recipient.
|
||||
|
||||
P2P networks do not use servers, as peers communicate directly between each other and hence cannot be self-hosted. However, some additional services may rely on centralized servers, such as user discovery or relaying offline messages, which can benefit from self-hosting.
|
||||
|
||||
**Vantaggi:**
|
||||
|
||||
- Minimal information is exposed to third-parties.
|
||||
- Modern P2P platforms implement E2EE by default. There are no servers that could potentially intercept and decrypt your transmissions, unlike centralized and federated models.
|
||||
|
||||
**Svantaggi:**
|
||||
|
||||
- Reduced feature set:
|
||||
- Messages can only be sent when both peers are online, however, your client may store messages locally to wait for the contact to return online.
|
||||
- Generally increases battery usage on mobile devices, because the client must stay connected to the distributed network to learn about who is online.
|
||||
- Some common messenger features may not be implemented or incompletely, such as message deletion.
|
||||
- Your IP address and that of the contacts you're communicating with may be exposed if you do not use the software in conjunction with a [VPN](../vpn.md) or [Tor](../tor.md). Many countries have some form of mass surveillance and/or metadata retention.
|
||||
|
||||
## Instradamento anonimo
|
||||
|
||||
{ align=left }
|
||||
|
||||
A messenger using [anonymous routing](https://doi.org/10.1007/978-1-4419-5906-5_628) hides either the identity of the sender, the receiver, or evidence that they have been communicating. Ideally, a messenger should hide all three.
|
||||
|
||||
There are [many](https://doi.org/10.1145/3182658) different ways to implement anonymous routing. One of the most famous is [onion routing](https://en.wikipedia.org/wiki/Onion_routing) (i.e. [Tor](tor-overview.md)), which communicates encrypted messages through a virtual [overlay network](https://en.wikipedia.org/wiki/Overlay_network) that hides the location of each node as well as the recipient and sender of each message. The sender and recipient never interact directly and only meet through a secret rendezvous node so that there is no leak of IP addresses nor physical location. Nodes cannot decrypt messages, nor the final destination; only the recipient can. Each intermediary node can only decrypt a part that indicates where to send the still encrypted message next, until it arrives at the recipient who can fully decrypt it, hence the "onion layers."
|
||||
|
||||
Self-hosting a node in an anonymous routing network does not provide the hoster with additional privacy benefits, but rather contributes to the whole network's resilience against identification attacks for everyone's benefit.
|
||||
|
||||
**Vantaggi:**
|
||||
|
||||
- Minimal to no information is exposed to other parties.
|
||||
- Messages can be relayed in a decentralized manner even if one of the parties is offline.
|
||||
|
||||
**Svantaggi:**
|
||||
|
||||
- Slow message propagation.
|
||||
- Often limited to fewer media types, mostly text, since the network is slow.
|
||||
- Less reliable if nodes are selected by randomized routing, some nodes may be very far from the sender and receiver, adding latency or even failing to transmit messages if one of the nodes goes offline.
|
||||
- More complex to get started, as the creation and secured backup of a cryptographic private key is required.
|
||||
- Just like other decentralized platforms, adding features is more complex for developers than on a centralized platform. Hence, features may be lacking or incompletely implemented, such as offline message relaying or message deletion.
|
||||
|
||||
--8<-- "includes/abbreviations.it.txt"
|
||||
307
i18n/it/advanced/dns-overview.md
Normal file
307
i18n/it/advanced/dns-overview.md
Normal file
@@ -0,0 +1,307 @@
|
||||
---
|
||||
title: "Panoramica DNS"
|
||||
icon: material/dns
|
||||
---
|
||||
|
||||
Il [Domain Name System](https://it.wikipedia.org/wiki/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](https://en.wikipedia.org/wiki/Domain_Name_System#History) 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](https://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol).
|
||||
|
||||
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](https://en.wikipedia.org/wiki/DNS_blocking). 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](https://it.wikipedia.org/wiki/Deep_packet_inspection) 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](https://it.wikipedia.org/wiki/Porta_(reti)) 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](#what-is-encrypted-dns) e non.
|
||||
|
||||
### DNS non crittografato
|
||||
|
||||
1. Utilizzando [`tshark`](https://www.wireshark.org/docs/man-pages/tshark.html) (parte del progetto [Wireshark](https://it.wikipedia.org/wiki/Wireshark)) possiamo monitorare e registrare il flusso di pacchetti Internet. Il comando registra pacchetti che soddisfano le regole specificate:
|
||||
|
||||
```bash
|
||||
tshark -w /tmp/dns.pcap udp port 53 and host 1.1.1.1 or host 8.8.8.8
|
||||
```
|
||||
|
||||
2. Possiamo poi utilizzare il comando [`dig`](https://it.wikipedia.org/wiki/Domain_Information_Groper) (Linux, MacOS ecc.) o [`nslookup`](https://it.wikipedia.org/wiki/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
|
||||
```
|
||||
|
||||
3. Successivamente vogliamo [analizzare](https://www.wireshark.org/docs/wsug_html_chunked/ChapterIntroduction.html#ChIntroWhatIs) 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](https://en.wikipedia.org/wiki/Ethernet_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**](https://en.wikipedia.org/wiki/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)](https://it.wikipedia.org/wiki/Internet_Engineering_Task_Force), né è passato attraverso il processo di [Request for Comments (RFC, "richiesta di commenti")](https://it.wikipedia.org/wiki/Request_for_Comments); non è mai stato quindi ampiamente utilizzato al di fuori di alcune [implementazioni](https://dnscrypt.info/implementations). DI conseguenza, è stato largamente rimpiazzato dal più popolare [DNS over HTTPS](#dns-over-https-doh).
|
||||
|
||||
### DNS over TLS (DoT)
|
||||
|
||||
[**DNS over TLS**](https://en.wikipedia.org/wiki/DNS_over_TLS) è un altro metodo per criptare le comunicazioni DNS, definito in [RFC 7858](https://datatracker.ietf.org/doc/html/rfc7858). Il supporto è stato implementato per la prima volta in Android 9, iOS 14 e su Linux in [systemd-resolved](https://www.freedesktop.org/software/systemd/man/resolved.conf.html#DNSOverTLS=) nella versione 237. Negli ultimi anni la preferenza del settore si è spostata da DoT a DoH, in quanto DoT è [protocollo complesso](https://dnscrypt.info/faq/) 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**](https://it.wikipedia.org/wiki/DNS_over_HTTPS) come definito in [RFC 8484](https://datatracker.ietf.org/doc/html/rfc8484) pacchettizza le query nel protocollo [HTTP/2](https://it.wikipedia.org/wiki/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](https://android-review.googlesource.com/c/platform/packages/modules/DnsResolver/+/1833144)). Il supporto generale per i desktop Linux è in attesa dell'implementazione di systemd [](https://github.com/systemd/systemd/issues/8639) quindi [l'installazione di software di terze parti è ancora necessaria](../dns.md#linux).
|
||||
|
||||
## Cosa può vedere un esterno?
|
||||
|
||||
In questo esempio registreremo ciò che accade quando facciamo una richiesta al DoH:
|
||||
|
||||
1. Per prima cosa, avviare `tshark`:
|
||||
|
||||
```bash
|
||||
tshark -w /tmp/dns_doh.pcap -f "tcp port https and host 1.1.1.1"
|
||||
```
|
||||
|
||||
2. In secondo luogo, fare una richiesta con `curl`:
|
||||
|
||||
```bash
|
||||
curl -vI --doh-url https://1.1.1.1/dns-query https://privacyguides.org
|
||||
```
|
||||
|
||||
3. Dopo aver effettuato la richiesta, possiamo interrompere la cattura dei pacchetti con <kbd>CTRL</kbd> + <kbd>C</kbd>.
|
||||
|
||||
4. Analizzare i risultati con Wireshark:
|
||||
|
||||
```bash
|
||||
wireshark -r /tmp/dns_doh.pcap
|
||||
```
|
||||
|
||||
Possiamo vedere l'[instaurazione della connessione](https://en.wikipedia.org/wiki/Transmission_Control_Protocol#Connection_establishment) e l'[handshake TLS](https://www.cloudflare.com/learning/ssl/what-happens-in-a-tls-handshake/) 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](../basics/threat-modeling.md). Noi **non** suggeriamo l'uso di DNS criptati per questo scopo. Utilizza [Tor](https://torproject.org) o una [VPN](../vpn.md). 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 [](https://it.wikipedia.org/wiki/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](https://it.wikipedia.org/wiki/Denial_of_service).
|
||||
|
||||
1. Avviare nuovamente la cattura con `tshark`. Abbiamo aggiunto un filtro con il nostro indirizzo IP in modo da non catturare molti pacchetti:
|
||||
|
||||
```bash
|
||||
tshark -w /tmp/pg.pcap port 443 and host 198.98.54.105
|
||||
```
|
||||
|
||||
2. Poi visitiamo [https://privacyguides.org](https://privacyguides.org).
|
||||
|
||||
3. Dopo aver visitato il sito web, vogliamo interrompere la cattura dei pacchetti con <kbd>CTRL</kbd> + <kbd>C</kbd>.
|
||||
|
||||
4. Poi vogliamo analizzare i risultati:
|
||||
|
||||
```bash
|
||||
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".
|
||||
|
||||
5. Espandi il triangolo ▸ accanto a ciascun campo:
|
||||
|
||||
```text
|
||||
▸ 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ò fornire direttamente il valore per tutti i pacchetti contenenti un valore SNI:
|
||||
|
||||
```bash
|
||||
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](https://en.wikipedia.org/wiki/Transport_Layer_Security#TLS_1.3) porta con sé [Encrypted Client Hello](https://blog.cloudflare.com/encrypted-client-hello/), che impedisce questo tipo di fuga d'informazioni.
|
||||
|
||||
I governi, in particolare [Cina](https://www.zdnet.com/article/china-is-now-blocking-all-encrypted-https-traffic-using-tls-1-3-and-esni/) e [Russia](https://www.zdnet.com/article/russia-wants-to-ban-the-use-of-secure-protocols-such-as-tls-1-3-doh-dot-esni/), hanno[già iniziato a bloccarlo](https://en.wikipedia.org/wiki/Server_Name_Indication#Encrypted_Client_Hello) o hanno espresso il desiderio di farlo. Recentemente, la Russia ha [iniziato a bloccare i siti web](https://github.com/net4people/bbs/issues/108) stranieri che utilizzano lo standard [HTTP/3](https://it.wikipedia.org/wiki/HTTP/3). Questo perché il protocollo [QUIC](https://it.wikipedia.org/wiki/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](https://it.wikipedia.org/wiki/Online_Certificate_Status_Protocol). Quando si visita un sito web HTTPS, il browser potrebbe verificare se il [certificato](https://it.wikipedia.org/wiki/Certificato_digitale) 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](https://it.wikipedia.org/wiki/Certificato_digitale#Struttura_dei_Certificati)", che è unico. Viene inviato al "responder OCSP" per verificarne lo stato.
|
||||
|
||||
Possiamo simulare quello che farebbe un browser usando il comando [`openssl`](https://it.wikipedia.org/wiki/OpenSSL).
|
||||
|
||||
1. Ottenere il certificato del server e utilizzare [`sed`](https://it.wikipedia.org/wiki/Sed_(Unix)) per conservare solo la parte importante e scriverla in un file:
|
||||
|
||||
```bash
|
||||
openssl s_client -connect privacyguides.org:443 < /dev/null 2>&1 |
|
||||
sed -n '/^-*BEGIN/,/^-*END/p' > /tmp/pg_server.cert
|
||||
```
|
||||
|
||||
2. Ottenere il certificato intermedio. [Autorità di certificazione (CA)](https://it.wikipedia.org/wiki/Certificate_authority) di solito non firmano direttamente un certificato, ma utilizzano un cosiddetto certificato "intermedio".
|
||||
|
||||
```bash
|
||||
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 passo 1. Possiamo usare di nuovo `sed` per cancellare fino alla prima istanza di END:
|
||||
|
||||
```bash
|
||||
sed -n '/^-*END CERTIFICATE-*$/!d;:a n;p;ba' \
|
||||
/tmp/pg_and_intermediate.cert > /tmp/intermediate_chain.cert
|
||||
```
|
||||
|
||||
4. Ottenere il responder OCSP per il certificato del server:
|
||||
|
||||
```bash
|
||||
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:
|
||||
|
||||
```bash
|
||||
openssl x509 -text -noout -in /tmp/pg_server.cert
|
||||
```
|
||||
|
||||
5. Avviare l'acquisizione dei pacchetti:
|
||||
|
||||
```bash
|
||||
tshark -w /tmp/pg_ocsp.pcap -f "tcp port http"
|
||||
```
|
||||
|
||||
6. Effettuare la richiesta OCSP:
|
||||
|
||||
```bash
|
||||
openssl ocsp -issuer /tmp/intermediate_chain.cert \
|
||||
-cert /tmp/pg_server.cert \
|
||||
-text \
|
||||
-url http://r3.o.lencr.org
|
||||
```
|
||||
|
||||
7. Aprire l'acquisizione:
|
||||
|
||||
```bash
|
||||
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:
|
||||
|
||||
```bash
|
||||
▸ Online Certificate Status Protocol
|
||||
▸ tbsRequest
|
||||
▸ requestList: 1 item
|
||||
▸ Request
|
||||
▸ reqCert
|
||||
serialNumber
|
||||
```
|
||||
|
||||
Per la "Risposta" possiamo vedere anche il "numero seriale":
|
||||
|
||||
```bash
|
||||
▸ Online Certificate Status Protocol
|
||||
▸ responseBytes
|
||||
▸ BasicOCSPResponse
|
||||
▸ tbsResponseData
|
||||
▸ responses: 1 item
|
||||
▸ SingleResponse
|
||||
▸ certID
|
||||
serialNumber
|
||||
```
|
||||
|
||||
8. Oppure utilizzare `tshark` per filtrare i pacchetti per il numero seriale:
|
||||
|
||||
```bash
|
||||
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](https://en.wikipedia.org/wiki/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:
|
||||
|
||||
``` mermaid
|
||||
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](https://en.wikipedia.org/wiki/DNS_blocking) 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](../dns.md ""){.md-button}
|
||||
|
||||
## Che cosa sono le DNSSEC?
|
||||
|
||||
Le [Domain Name System Security Extensions](https://it.wikipedia.org/wiki/DNSSEC) (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`.
|
||||
|
||||
<small>Adattato da [DNS Security Extensions (DNSSEC) overview (Panoramica delle DNS Security Extensions (DNSSEC))](https://cloud.google.com/dns/docs/dnssec) di Google e [DNSSEC: An Introduction (DNSSEC: una introduzione)](https://blog.cloudflare.com/dnssec-an-introduction/) di Cloudflare, entrambi con licenza [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/).</small>
|
||||
|
||||
## 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](https://en.wikipedia.org/wiki/Name_server#Authoritative_name_server).
|
||||
|
||||
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](https://datatracker.ietf.org/doc/html/rfc7816).
|
||||
|
||||
## Che cos'è la sottorete client EDNS (EDNS Client Subnet, ECS)?
|
||||
|
||||
La [sottorete client EDNS](https://en.wikipedia.org/wiki/EDNS_Client_Subnet) è un metodo che consente a un resolver DNS ricorsivo di specificare una [sottorete](https://it.wikipedia.org/wiki/Sottorete) per l'host o il [client](https://it.wikipedia.org/wiki/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 [](https://it.wikipedia.org/wiki/Content_Delivery_Network), 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.
|
||||
|
||||
--8<-- "includes/abbreviations.it.txt"
|
||||
81
i18n/it/advanced/tor-overview.md
Normal file
81
i18n/it/advanced/tor-overview.md
Normal file
@@ -0,0 +1,81 @@
|
||||
---
|
||||
title: "Panoramica Tor"
|
||||
icon: 'simple/torproject'
|
||||
---
|
||||
|
||||
Tor è una rete decentralizzata e gratuita progettata per utilizzare Internet con la massima privacy possibile. Se utilizzata correttamente, la rete consente di navigare e comunicare in modo privato e anonimo.
|
||||
|
||||
## Costruzione del percorso
|
||||
|
||||
Tor funziona instradando il traffico attraverso una rete composta da migliaia di server gestiti da volontari e chiamati nodi (o relay).
|
||||
|
||||
Ogni volta che ci si connette a Tor, questo sceglie tre nodi per costruire un percorso verso Internet: questo percorso è chiamato "circuito". Ciascuno di questi nodi ha una propria funzione:
|
||||
|
||||
### Il nodo di ingresso
|
||||
|
||||
Il nodo di ingresso, spesso chiamato nodo di guardia, è il primo nodo a cui si connette il client Tor. Il nodo di ingresso è in grado di vedere il tuo indirizzo IP, ma non è in grado di vedere a cosa ti stai connettendo.
|
||||
|
||||
A differenza degli altri nodi, il client Tor seleziona casualmente un nodo di ingresso e vi rimane per due o tre mesi per proteggerti da alcuni attacchi.[^1]
|
||||
|
||||
### Il nodo centrale
|
||||
|
||||
Il nodo centrale è il secondo nodo a cui si connette il client Tor. Può vedere da quale nodo proviene il traffico, il nodo di ingresso, e a quale nodo va successivamente. Il nodo centrale non può vedere il tuo indirizzo IP o il dominio a cui ti stai connettendo.
|
||||
|
||||
Per ogni nuovo circuito, il nodo centrale viene selezionato a caso tra tutti i nodi Tor disponibili.
|
||||
|
||||
### Il nodo di uscita
|
||||
|
||||
Il nodo di uscita è il punto in cui il traffico web lascia la rete Tor e viene inoltrato alla destinazione desiderata. Il nodo di uscita non è in grado di vedere l'indirizzo IP, ma sa a quale sito ti stai collegando.
|
||||
|
||||
Il nodo di uscita sarà scelto a caso tra tutti i nodi Tor disponibili con un flag di uscita.[^2]
|
||||
|
||||
<figure markdown>
|
||||
|
||||
|
||||
<figcaption>Percorso del circuito Tor</figcaption>
|
||||
</figure>
|
||||
|
||||
## Encryption
|
||||
|
||||
Tor encrypts each packet (a block of transmitted data) three times with the keys from the exit, middle, and entry node—in that order.
|
||||
|
||||
Once Tor has built a circuit, data transmission is done as follows:
|
||||
|
||||
1. Firstly: when the packet arrives at the entry node, the first layer of encryption is removed. In this encrypted packet, the entry node will find another encrypted packet with the middle node’s address. The entry node will then forward the packet to the middle node.
|
||||
|
||||
2. Secondly: when the middle node receives the packet from the entry node, it too will remove a layer of encryption with its key, and this time finds an encrypted packet with the exit node's address. The middle node will then forward the packet to the exit node.
|
||||
|
||||
3. Lastly: when the exit node receives its packet, it will remove the last layer of encryption with its key. The exit node will see the destination address and forward the packet to that address.
|
||||
|
||||
Below is an alternative diagram showing the process. Each node removes its own layer of encryption, and when the destination server returns data, the same process happens entirely in reverse. For example, the exit node does not know who you are, but it does know which node it came from, and so it adds its own layer of encryption and sends it back.
|
||||
|
||||
<figure markdown>
|
||||
|
||||
|
||||
<figcaption>Sending and receiving data through the Tor Network</figcaption>
|
||||
</figure>
|
||||
|
||||
Tor allows us to connect to a server without any single party knowing the entire path. The entry node knows who you are, but not where you are going; the middle node doesn’t know who you are or where you are going; and the exit node knows where you are going, but not who you are. Because the exit node is what makes the final connection, the destination server will never know your IP address.
|
||||
|
||||
## Caveats
|
||||
|
||||
Though Tor does provide strong privacy guarantees, one must be aware that Tor is not perfect:
|
||||
|
||||
- Well-funded adversaries with the capability to passively watch most network traffic over the globe have a chance of deanonymizing Tor users by means of advanced traffic analysis. Nor does Tor protect you from exposing yourself by mistake, such as if you share too much information about your real identity.
|
||||
- Tor exit nodes can also monitor traffic that passes through them. This means traffic which is not encrypted, such as plain HTTP traffic, can be recorded and monitored. If such traffic contains personally identifiable information, then it can deanonymize you to that exit node. Thus, we recommend using HTTPS over Tor where possible.
|
||||
|
||||
If you wish to use Tor for browsing the web, we only recommend the **official** Tor Browser—it is designed to prevent fingerprinting.
|
||||
|
||||
- [Tor Browser :material-arrow-right-drop-circle:](../tor.md#tor-browser)
|
||||
|
||||
## Risorse aggiuntive
|
||||
|
||||
- [Manuale d'uso del Tor browser](https://tb-manual.torproject.org)
|
||||
- [How Tor Works - Computerphile](https://invidious.privacyguides.net/embed/QRYzre4bf7I?local=true) <small>(YouTube)</small>
|
||||
- [Tor Onion Services - Computerphile](https://invidious.privacyguides.net/embed/lVcbq_a5N9I?local=true) <small>(YouTube)</small>
|
||||
|
||||
--8<-- "includes/abbreviations.it.txt"
|
||||
|
||||
[^1]: The first relay in your circuit is called an "entry guard" or "guard". It is a fast and stable relay that remains the first one in your circuit for 2-3 months in order to protect against a known anonymity-breaking attack. The rest of your circuit changes with every new website you visit, and all together these relays provide the full privacy protections of Tor. For more information on how guard relays work, see this [blog post](https://blog.torproject.org/improving-tors-anonymity-changing-guard-parameters) and [paper](https://www-users.cs.umn.edu/~hoppernj/single_guard.pdf) on entry guards. ([https://support.torproject.org/tbb/tbb-2/](https://support.torproject.org/tbb/tbb-2/))
|
||||
|
||||
[^2]: Relay flag: a special (dis-)qualification of relays for circuit positions (for example, "Guard", "Exit", "BadExit"), circuit properties (for example, "Fast", "Stable"), or roles (for example, "Authority", "HSDir"), as assigned by the directory authorities and further defined in the directory protocol specification. ([https://metrics.torproject.org/glossary.html](https://metrics.torproject.org/glossary.html))
|
||||
Reference in New Issue
Block a user