privacyguides/privacyguides.org
1
0
Fork 0
mirror of https://github.com/privacyguides/privacyguides.org.git synced 2025-07-25 12:51:14 +00:00
Code Issues Activity

Download Translations from Crowdin (#2054)

Browse Source
This commit is contained in:
Crowdin Bot
2023-02-28 14:22:46 -06:00
committed by Jonah Aragon
parent 4c8cd3f295
commit 1ac4dd75c7
1733 changed files with 199297 additions and 170 deletions
Download Patch File Download Diff File Expand all files Collapse all files

104
i18n/pt/advanced/communication-network-types.md Normal file
View File

@@ -0,0 +1,104 @@
---
title: "Types of Communication Networks"
icon: 'material/transit-connection-variant'
---
There are several network architectures commonly used to relay messages between people. These networks can provide different privacy guarantees, which is why it's worth considering your [threat model](../basics/threat-modeling.md) when deciding which app to use.
[Recommended Instant Messengers](../real-time-communication.md ""){.md-button}
## Centralized Networks
![Centralized networks diagram](../assets/img/layout/network-centralized.svg){ align=left }
Centralized messengers are those where all participants are on the same server or network of servers controlled by the same organization.
Some self-hosted messengers allow you to set up your own server. Self-hosting can provide additional privacy guarantees, such as no usage logs or limited access to metadata (data about who is talking to whom). Self-hosted centralized messengers are isolated and everyone must be on the same server to communicate.
**Advantages:**
- New features and changes can be implemented more quickly.
- Easier to get started with and to find contacts.
- Most mature and stable features ecosystems, as they are easier to program in a centralized software.
- Privacy issues may be reduced when you trust a server that you're self-hosting.
**Disadvantages:**
- Can include [restricted control or access](https://drewdevault.com/2018/08/08/Signal.html). This can include things like:
- Being [forbidden from connecting third-party clients](https://github.com/LibreSignal/LibreSignal/issues/37#issuecomment-217211165) to the centralized network that might provide for greater customization or a better experience. Often defined in Terms and Conditions of usage.
- Poor or no documentation for third-party developers.
- The [ownership](https://web.archive.org/web/20210729191953/https://blog.privacytools.io/delisting-wire/), privacy policy, and operations of the service can change easily when a single entity controls it, potentially compromising the service later on.
- Self-hosting requires effort and knowledge of how to set up a service.
## Federated Networks
![Federated networks diagram](../assets/img/layout/network-decentralized.svg){ 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).
**Advantages:**
- 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).
**Disadvantages:**
- 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.
## Peer-to-Peer Networks
![P2P diagram](../assets/img/layout/network-distributed.svg){ 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.
**Advantages:**
- 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.
**Disadvantages:**
- 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.
## Anonymous Routing
![Anonymous routing diagram](../assets/img/layout/network-anonymous-routing.svg){ 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.
**Advantages:**
- 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.
**Disadvantages:**
- 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.pt.txt"

307
i18n/pt/advanced/dns-overview.md Normal file
View File

@@ -0,0 +1,307 @@
---
title: "DNS Overview"
icon: material/dns
---
O [Domain Name System (DNS)](https://en.wikipedia.org/wiki/Domain_Name_System) é a 'lista telefónica da Internet'. DNS traduz nomes de domínio para [IP](https://en.wikipedia.org/wiki/Internet_Protocol) endereços para que os navegadores e outros serviços possam carregar recursos da Internet, através de uma rede descentralizada de servidores.
## O que é DNS?
Quando você visita um site, um endereço numérico é devolvido. Por exemplo, quando você visita `privacyguides.org`, o endereço `192.98.54.105` é retornado.
O DNS existe desde o [dos primeiros dias](https://en.wikipedia.org/wiki/Domain_Name_System#History) da Internet. Os pedidos DNS feitos para e dos servidores DNS são **não** geralmente encriptados. Em uma configuração residencial, um cliente recebe servidores pelo [ISP](https://en.wikipedia.org/wiki/Internet_service_provider) via [Dynamic Host Configuration Protocol (DHCP)](https://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol).
Os pedidos DNS não encriptados são capazes de ser facilmente **surveilled** e **modificados** em trânsito. Em algumas partes do mundo, os ISPs são solicitados a fazer [filtragem DNS](https://en.wikipedia.org/wiki/DNS_blocking). Quando um usuário solicita o IP de um domínio que está bloqueado, o servidor pode não responder ou pode responder com um endereço IP diferente. Como o protocolo DNS não é criptografado, o ISP (ou qualquer operador de rede) pode usar [deep packet inspection (DPI)](https://en.wikipedia.org/wiki/Deep_packet_inspection) para monitorar as solicitações. Os ISPs também podem bloquear pedidos com base em características comuns, independentemente do servidor DNS utilizado. DNS não encriptado usa sempre [port](https://en.wikipedia.org/wiki/Port_(computer_networking)) 53 e usa sempre o [User Datagram Protocol (UDP)](https://en.wikipedia.org/wiki/User_Datagram_Protocol).
Abaixo, discutimos e fornecemos um tutorial para provar o que um observador externo pode ver usando DNS regular não criptografado e [DNS criptografado](#what-is-encrypted-dns).
### DNS não criptografado
1. Usando [`tshark`](https://www.wireshark.org/docs/man-pages/tshark.html) (parte do [Wireshark](https://en.wikipedia.org/wiki/Wireshark) project) podemos monitorar e gravar o fluxo de pacotes da Internet. Este comando registra os pacotes que atendem às regras especificadas:
```bash
tshark -w /tmp/dns.pcap udp porto 53 e host 1.1.1.1 ou host 8.8.8.8
```
2. Podemos então usar [`dig`](https://en.wikipedia.org/wiki/Dig_(command)) (Linux, MacOS etc) ou [`nslookup`](https://en.wikipedia.org/wiki/Nslookup) (Windows) para enviar a pesquisa DNS para ambos os servidores. Software como navegadores web fazem estas pesquisas automaticamente, a menos que estejam configurados para usar [DNS encriptado](#what-is-encrypted-dns).
=== "Linux, macOS"
```
dig noall answer privacyguides.org @1.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. A seguir, queremos [analisar](https://www.wireshark.org/docs/wsug_html_chunked/ChapterIntroduction.html#ChIntroWhatIs) os resultados:
==== "Wireshark"
```
wireshark -r /tmp/dns.pcap
```
=== "tshark"
```
tshark -r /tmp/dns.pcap
```
Se você executar o comando Wireguard acima, o painel superior mostra o "[frames](https://en.wikipedia.org/wiki/Ethernet_frame)", e o painel inferior mostra todos os dados sobre o frame selecionado. Soluções de filtragem e monitoramento empresarial (como as adquiridas pelos governos) podem fazer o processo automaticamente, sem interação humana, e podem agregar esses quadros para produzir dados estatísticos úteis para o observador da rede.
| Não. | Hora | Fonte | Destino | Protocolo | Comprimento | Informações |
| ---- | -------- | --------- | --------- | --------- | ----------- | -------------------------------------------------------------------------- |
| 1 | 0.000000 | 192.0.2.1 | 1.1.1.1 | DNS | 104 | Consulta padrão 0x58ba A privacyguides.org OPT |
| 2 | 0.293395 | 1.1.1.1 | 192.0.2.1 | DNS | 108 | Resposta de consulta padrão 0x58ba A privacyguides.org A 198.98.54.105 OPT |
| 3 | 1.682109 | 192.0.2.1 | 8.8.8.8 | DNS | 104 | Consulta padrão 0xf1a9 A privacyguides.org OPT |
| 4 | 2.154698 | 8.8.8.8 | 192.0.2.1 | DNS | 108 | Resposta de consulta padrão 0xf1a9 A privacyguides.org A 198.98.54.105 OPT |
Um observador pode modificar qualquer um destes pacotes.
## O que é "DNS criptografado"?
DNS criptografado pode se referir a um de vários protocolos, sendo os mais comuns:
### DNSCrypt
[**DNSCrypt**](https://en.wikipedia.org/wiki/DNSCrypt) foi um dos primeiros métodos de encriptação de consultas DNS. O [protocolo](https://en.wikipedia.org/wiki/DNSCrypt#Protocol) opera em [porta 443](https://en.wikipedia.org/wiki/Well-known_ports) e funciona tanto com o [TCP](https://en.wikipedia.org/wiki/Transmission_Control_Protocol) ou [UDP](https://en.wikipedia.org/wiki/User_Datagram_Protocol) protocolos de transporte. DNSCrypt nunca foi submetido ao processo [Internet Engineering Task Force (IETF)](https://en.wikipedia.org/wiki/Internet_Engineering_Task_Force) nem foi submetido ao processo [Request for Comments (RFC)](https://en.wikipedia.org/wiki/Request_for_Comments) , portanto não tem sido usado amplamente fora de alguns [implementações](https://dnscrypt.info/implementations). Como resultado, foi amplamente substituído pelo mais popular [DNS sobre HTTPS (DoH)](#dns-over-https-doh).
### DNS sobre TLS (DoT)
[**DNS sobre TLS (DoT)**](https://en.wikipedia.org/wiki/DNS_over_TLS) é outro método para encriptar a comunicação DNS que é definida em [RFC 7858](https://datatracker.ietf.org/doc/html/rfc7858). O suporte foi implementado inicialmente em [Android 9](https://en.wikipedia.org/wiki/Android_Pie), [iOS 14](https://en.wikipedia.org/wiki/IOS_14), e no Linux em [systemd-resolved](https://www.freedesktop.org/software/systemd/man/resolved.conf.html#DNSOverTLS=) na versão 237. A preferência na indústria tem se afastado do DoT para [DNS sobre HTTPS](#dns-over-https-doh) nos últimos anos, pois o DoT é um [protocolo complexo](https://dnscrypt.info/faq/) e tem conformidade variável com a RFC nas implementações que existem. DoT também opera em uma porta dedicada 853 e que pode ser facilmente bloqueada por firewalls restritivos.
### DNS sobre HTTPS (DoH)
[**DNS sobre HTTPS**](https://en.wikipedia.org/wiki/DNS_over_HTTPS) como definido em [RFC 8484](https://datatracker.ietf.org/doc/html/rfc8484) consultas de pacotes no protocolo [HTTP/2](https://en.wikipedia.org/wiki/HTTP/2) e fornece segurança com [HTTPS](https://en.wikipedia.org/wiki/HTTPS). O suporte foi adicionado pela primeira vez em navegadores web como [Firefox 60](https://support.mozilla.org/en-US/kb/firefox-dns-over-https) e [Chrome 83](https://blog.chromium.org/2020/05/a-safer-and-more-private-browsing-DoH.html).
Native implementation of DoH showed up in iOS 14, macOS 11, Microsoft Windows, and Android 13 (however, it won't be enabled [by default](https://android-review.googlesource.com/c/platform/packages/modules/DnsResolver/+/1833144)). General Linux desktop support is waiting on the systemd [implementation](https://github.com/systemd/systemd/issues/8639) so [installing third-party software is still required](../dns.md#encrypted-dns-proxies).
## O que é que uma festa exterior pode ver?
Neste exemplo vamos registar o que acontece quando fazemos um pedido DoH:
1. Primeiro, iniciar `tshark`:
```bash
tshark -w /tmp/dns_doh.pcap -f "tcp port https e host 1.1.1.1"
```
2. Segundo, faça um pedido com `curl`:
```bash
curl -vI --doh-url https://1.1.1.1/dns-query https://privacyguides.org
```
3. Após fazer o pedido, podemos parar a captura de pacotes com <kbd>CTRL</kbd> <kbd>C</kbd>.
4. Analisar os resultados em Wireshark:
```bash
wireshark -r /tmp/dns_doh.pcap
```
Podemos ver o estabelecimento de conexão [e](https://en.wikipedia.org/wiki/Transmission_Control_Protocol#Connection_establishment) e [aperto de mão TLS](https://www.cloudflare.com/learning/ssl/what-happens-in-a-tls-handshake/) que ocorre com qualquer conexão criptografada. Ao olhar para os pacotes de "dados de aplicação" que se seguem, nenhum deles contém o domínio que solicitamos ou o endereço IP devolvido.
## Porque **não deveria** Eu uso DNS encriptado?
In locations where there is internet filtering (or censorship), visiting forbidden resources may have its own consequences which you should consider in your [threat model](../basics/threat-modeling.md). Fazemos **não** sugerimos o uso de DNS criptografado para este fim. Use [Tor](https://torproject.org) or a [VPN](../vpn.md) instead. Se você estiver usando uma VPN, você deve usar os servidores DNS da sua VPN. Ao utilizar uma VPN, já está a confiar-lhes toda a sua actividade na rede.
Quando fazemos uma pesquisa DNS, geralmente é porque queremos aceder a um recurso. Abaixo, discutiremos alguns dos métodos que podem revelar as suas actividades de navegação mesmo quando utiliza DNS encriptado:
### Endereço IP
A maneira mais simples de determinar a atividade de navegação pode ser olhar para os endereços IP que seus dispositivos estão acessando. Por exemplo, se o observador sabe que `privacyguides.org` está em `198.98.54.105`, e o seu dispositivo está solicitando dados de `198.98.54.105`, há uma boa chance de você estar visitando os Guias de Privacidade.
Este método só é útil quando o endereço IP pertence a um servidor que só hospeda poucos sites. It's also not very useful if the site is hosted on a shared platform (e.g. Github Pages, Cloudflare Pages, Netlify, WordPress, Blogger, etc). Também não é muito útil se o servidor estiver hospedado atrás de um [reverse proxy](https://en.wikipedia.org/wiki/Reverse_proxy), o que é muito comum na Internet moderna.
### Indicação do nome do servidor (SNI)
A indicação do nome do servidor é normalmente usada quando um endereço IP hospeda muitos sites. Este pode ser um serviço como o Cloudflare, ou algum outro [ataque de negação de serviço](https://en.wikipedia.org/wiki/Denial-of-service_attack) protecção.
1. Comece a capturar novamente com `tshark`. Adicionamos um filtro com nosso endereço IP para que você não capture muitos pacotes:
```bash
tshark -w /tmp/pg.pcap porto 443 e host 198.98.54.105
```
2. Depois visitamos [https://privacyguides.org](https://privacyguides.org).
3. Depois de visitar o site, nós o que parar a captura de pacotes com <kbd>CTRL</kbd> <kbd>C</kbd>.
4. A seguir queremos analisar os resultados:
```bash
wireshark -r /tmp/pg.pcap
```
Veremos o [estabelecimento de conexão](https://en.wikipedia.org/wiki/Transmission_Control_Protocol#Connection_establishment), seguido pelo [aperto de mão TLS](https://www.cloudflare.com/learning/ssl/what-happens-in-a-tls-handshake/) para o site Guias de Privacidade. Em redor da moldura 5. verás um "Olá Cliente".
5. Expandir o triângulo &#9656; ao lado de cada campo:
```text
▸ Transport Layer Security
▸ TLSv1.3 Record Layer: Protocolo de Aperto de Mãos: Cliente Olá
▸ Protocolo de Aperto de Mãos: Cliente Olá
▸ Extensão: Server_name (len=22)
▸ Server Name Indication extension
```
6. Podemos ver o [Server Name Indication (SNI)](https://en.wikipedia.org/wiki/Server_Name_Indication) valor que revela o site que estamos visitando. O comando `tshark` pode dar-lhe o valor directamente para todos os pacotes que contenham um valor SNI:
```bash
tshark -r /tmp/pg.pcap -Tfields -Y tls.handshake.extensions_server_name -e tls.handshake.extensions_server_name
```
Isto significa que mesmo que estejamos usando servidores DNS "Encriptados", o domínio provavelmente será divulgado através do SNI. O protocolo [TLS v1.3](https://en.wikipedia.org/wiki/Transport_Layer_Security#TLS_1.3) traz consigo [Cliente Encriptado Olá](https://blog.cloudflare.com/encrypted-client-hello/), o que evita este tipo de fuga.
Governos, em particular [China](https://www.zdnet.com/article/china-is-now-blocking-all-encrypted-https-traffic-using-tls-1-3-and-esni/) e [Rússia](https://www.zdnet.com/article/russia-wants-to-ban-the-use-of-secure-protocols-such-as-tls-1-3-doh-dot-esni/), ou já [começaram a bloquear](https://en.wikipedia.org/wiki/Server_Name_Indication#Encrypted_Client_Hello) ou manifestaram o desejo de o fazer. Recently, Russia has [started blocking foreign websites](https://github.com/net4people/bbs/issues/108) that use the [HTTP/3](https://en.wikipedia.org/wiki/HTTP/3) standard. Isto porque o [QUIC](https://en.wikipedia.org/wiki/QUIC) protocolo que faz parte do HTTP/3 requer que `ClientHello` também seja criptografado.
### Protocolo de Status de Certificado Online (OCSP)
Outra forma do seu navegador poder divulgar suas atividades de navegação é com o [Online Certificate Status Protocol](https://en.wikipedia.org/wiki/Online_Certificate_Status_Protocol). When visiting an HTTPS website, the browser might check to see if the website's [certificate](https://en.wikipedia.org/wiki/Public_key_certificate) has been revoked. Isto geralmente é feito através do protocolo [HTTP](https://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol) , significando que é **não** encriptado.
O pedido OCSP contém o certificado "[número de série](https://en.wikipedia.org/wiki/Public_key_certificate#Common_fields)", que é único. Ele é enviado ao "OCSP respondedor" para verificar o seu estado.
Podemos simular o que um navegador faria usando o comando [`openssl`](https://en.wikipedia.org/wiki/OpenSSL) .
1. Obtenha o certificado do servidor e use [`sed`](https://en.wikipedia.org/wiki/Sed) para manter apenas a parte importante e escrevê-la em um arquivo:
```bash
openssl s_client -connect privacyguides.org:443 < /dev/null 2>&1 |
sed -n '/^-*BEGIN/,/^-*END/p' > /tmp/pg_server.cert
```
2. Obter o certificado intermediário. [Autoridades Certificadoras (AC)](https://en.wikipedia.org/wiki/Certificate_authority) normalmente não assinam um certificado diretamente; eles usam o que é conhecido como certificado "intermediário".
```bash
openssl s_client -showcerts -connect privacyguides.org:443 < /dev/null 2>&1 |
sed -n '/^-*BEGIN/,/^-*END/p' > /tmp/pg_and_intermediate.cert
```
3. O primeiro certificado em `pg_and_intermediate.cert` é na verdade o certificado do servidor do passo 1. Podemos usar `sed` novamente para apagar até a primeira instância de TERMINAR:
```bash
sed -n '/^-*END CERTIFICATE-*$/!d;:a n;p;ba' \
/tmp/pg_and_intermediate.cert > /tmp/intermediate_chain.cert
```
4. Obtenha o OCSP respondedor para o certificado do servidor:
```bash
openssl x509 -noout -ocsp_uri -in /tmp/pg_server.cert
```
O nosso certificado mostra o Lets Encrypt Responder ao certificado. Se quisermos ver todos os detalhes do certificado, podemos usar:
```bash
openssl x509 -text -noout -in /tmp/pg_server.cert
```
5. Comece a captura do pacote:
```bash
tshark -w /tmp/pg_ocsp.pcap -f "tcp port http
```
6. Faça o pedido OCSP:
```bash
openssl ocsp -issuer /tmp/intermediate_chain.cert \
-cert /tmp/pg_server.cert \
-text \
-url http://r3.o.lencr.org
```
7. Abra a captura:
```bash
wireshark -r /tmp/pg_ocsp.pcap
```
There will be two packets with the "OCSP" protocol: a "Request" and a "Response". Para o "Request" podemos ver o "serial number", expandindo o triângulo &#9656; ao lado de cada campo:
```bash
▸ Online Certificate Status Protocol
▸ tbsRequest
▸ requestList: 1 item
▸ request
▸ reqCert
serialNumber
```
Para a "Resposta" também podemos ver o "número de série":
```bash
▸ Online Certificate Status Protocol
▸ responseBytes
▸ BasicOCSPResponse
▸ tbsResponseData
▸ responses: 1 item
▸ Respostas Simples
▸ certID
serialNumber
```
8. Ou use `tshark` para filtrar os pacotes para o Número de Série:
```bash
tshark -r /tmp/pg_ocsp.pcap -Tfields -Y ocsp.serialNumber -e ocsp.serialNumber
```
Se o observador da rede tiver o certificado público, que está disponível publicamente, ele pode fazer corresponder o número de série com esse certificado e, portanto, determinar o site que você está visitando a partir daí. O processo pode ser automatizado e pode associar endereços IP com números de série. Também é possível verificar [Certificate Transparency](https://en.wikipedia.org/wiki/Certificate_Transparency) logs para o número de série.
## Devo utilizar DNS encriptado?
Nós fizemos este fluxograma para descrever quando você *deve* usar DNS criptografado:
``` mermaid
graph TB
Start[Start] --> anonymous{Trying to be<br> anonymous?}
anonymous--> | Yes | tor(Use Tor)
anonymous --> | No | censorship{Avoiding<br> censorship?}
censorship --> | Yes | vpnOrTor(Use<br> VPN ou Tor)
censorship --> | No | privacy{Want privacy<br> from ISP?}
privacidade --> | Yes | vpnOrTor
privacidade --> | No | obnoxious{ISP makes<br> obnoxious<br> redirecciona?}
obnóxio --> | Yes | encryptedDNS(Use<br> encrypted DNS<br> with 3rd party)
obnóxio --> | No | ispDNS{Does ISP support<br> encrypted DNS?}
ispDNS --> | Yes | useISP(Use<br> DNS encriptado<br> com ISP)
ispDNS --> | No | nothing(Do nothing)
```
Encrypted DNS with a third-party should only be used to get around redirects and basic [DNS blocking](https://en.wikipedia.org/wiki/DNS_blocking) when you can be sure there won't be any consequences or you're interested in a provider that does some rudimentary filtering.
[Lista de servidores DNS recomendados](../dns.md ""){.md-button}
## What is DNSSEC?
[Domain Name System Security Extensions](https://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions) (DNSSEC) is a feature of DNS that authenticates responses to domain name lookups. It does not provide privacy protections for those lookups, but rather prevents attackers from manipulating or poisoning the responses to DNS requests.
In other words, DNSSEC digitally signs data to help ensure its validity. In order to ensure a secure lookup, the signing occurs at every level in the DNS lookup process. As a result, all answers from DNS can be trusted.
The DNSSEC signing process is similar to someone signing a legal document with a pen; that person signs with a unique signature that no one else can create, and a court expert can look at that signature and verify that the document was signed by that person. These digital signatures ensure that data has not been tampered with.
DNSSEC implements a hierarchical digital signing policy across all layers of DNS. For example, in the case of a `privacyguides.org` lookup, a root DNS server would sign a key for the `.org` nameserver, and the `.org` nameserver would then sign a key for `privacyguides.org`’s authoritative nameserver.
<small>Adapted from [DNS Security Extensions (DNSSEC) overview](https://cloud.google.com/dns/docs/dnssec) by Google and [DNSSEC: An Introduction](https://blog.cloudflare.com/dnssec-an-introduction/) by Cloudflare, both licensed under [CC BY 4.0](https://creativecommons.org/licenses/by/4.0/).</small>
## O que é a minimização do QNAME?
Um QNAME é um "nome qualificado", por exemplo `privacyguides.org`. A minimização do QNAME reduz a quantidade de informação enviada do servidor DNS para o [servidor de nomes autorizado](https://en.wikipedia.org/wiki/Name_server#Authoritative_name_server).
Em vez de enviar o domínio inteiro `privacyguides.org`, a minimização do QNAME significa que o servidor DNS irá pedir todos os registos que terminem em `.org`. Descrição técnica adicional é definida em [RFC 7816](https://datatracker.ietf.org/doc/html/rfc7816).
## O que é a Sub-Rede do Cliente EDNS (ECS)?
O [subrede do cliente EDNS](https://en.wikipedia.org/wiki/EDNS_Client_Subnet) é um método para um resolvedor DNS recursivo para especificar um [sub-rede](https://en.wikipedia.org/wiki/Subnetwork) para o [host ou cliente](https://en.wikipedia.org/wiki/Client_(computing)) que está fazendo a consulta DNS.
O objectivo é "acelerar" a entrega de dados, dando ao cliente uma resposta que pertence a um servidor que lhes está próximo, tal como um [content delivery network (CDN)](https://en.wikipedia.org/wiki/Content_delivery_network), que são frequentemente utilizados em streaming de vídeo e em aplicações web JavaScript.
Este recurso tem um custo de privacidade, pois informa ao servidor DNS algumas informações sobre a localização do cliente.
--8<-- "includes/abbreviations.pt.txt"

81
i18n/pt/advanced/tor-overview.md Normal file
View File

@@ -0,0 +1,81 @@
---
title: "Tor Overview"
icon: 'simple/torproject'
---
Tor is a free to use, decentralized network designed for using the internet with as much privacy as possible. If used properly, the network enables private and anonymous browsing and communications.
## Path Building
Tor works by routing your traffic through a network comprised of thousands of volunteer-run servers called nodes (or relays).
Every time you connect to Tor, it will choose three nodes to build a path to the internet—this path is called a "circuit." Each of these nodes has its own function:
### The Entry Node
The entry node, often called the guard node, is the first node to which your Tor client connects. The entry node is able to see your IP address, however it is unable to see what you are connecting to.
Unlike the other nodes, the Tor client will randomly select an entry node and stick with it for two to three months to protect you from certain attacks.[^1]
### The Middle Node
The middle node is the second node to which your Tor client connects. It can see which node the traffic came from—the entry node—and to which node it goes to next. The middle node cannot, see your IP address or the domain you are connecting to.
For each new circuit, the middle node is randomly selected out of all available Tor nodes.
### The Exit Node
The exit node is the point in which your web traffic leaves the Tor network and is forwarded to your desired destination. The exit node is unable to see your IP address, but it does know what site it's connecting to.
The exit node will be chosen at random from all available Tor nodes ran with an exit relay flag.[^2]
<figure markdown>
![Tor path](../assets/img/how-tor-works/tor-path.svg#only-light)
![Tor path](../assets/img/how-tor-works/tor-path-dark.svg#only-dark)
<figcaption>Tor circuit pathway</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>
![Tor encryption](../assets/img/how-tor-works/tor-encryption.svg#only-light)
![Tor encryption](../assets/img/how-tor-works/tor-encryption-dark.svg#only-dark)
<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)
## Recursos Adicionais
- [Tor Browser User Manual](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.pt.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))