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/zh-Hant/advanced/communication-network-types.md
Normal file
104
i18n/zh-Hant/advanced/communication-network-types.md
Normal 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
|
||||
|
||||
{ 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
|
||||
|
||||
{ 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
|
||||
|
||||
{ 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
|
||||
|
||||
{ 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.zh-Hant.txt"
|
||||
307
i18n/zh-Hant/advanced/dns-overview.md
Normal file
307
i18n/zh-Hant/advanced/dns-overview.md
Normal file
@@ -0,0 +1,307 @@
|
||||
---
|
||||
title: "DNS 簡介"
|
||||
icon: material/dns
|
||||
---
|
||||
|
||||
The [Domain Name System](https://en.wikipedia.org/wiki/Domain_Name_System) is the 'phonebook of the Internet'. DNS 將網域名稱轉換為 IP 位址，以便瀏覽器和其他服務可以通過分散的伺服器網路載入網路資源。
|
||||
|
||||
## 什麼是 DNS？
|
||||
|
||||
當您訪問一個網站時，會傳回一個數字地址。 For example, when you visit `privacyguides.org`, the address `192.98.54.105` is returned.
|
||||
|
||||
DNS 從網際網路的 [早期](https://en.wikipedia.org/wiki/Domain_Name_System#History) 就存在了。 來往 DNS 伺服器的 DNS 請求通常 **不是** 加密的。 一般家用的網路中，客戶的伺服器通常是由 ISP 透過 [DHCP](https://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol)給予的。
|
||||
|
||||
Unencrypted DNS requests are able to be easily **surveilled** and **modified** in transit. In some parts of the world, ISPs are ordered to do primitive [DNS filtering](https://en.wikipedia.org/wiki/DNS_blocking). 當您要求被封鎖網域的IP位址時，伺服器可能不會回應，或可能會使用其他IP位址回應。 由於DNS通訊協定沒有加密， ISP （或任何網路營運商）可以使用 [DPI](https://en.wikipedia.org/wiki/Deep_packet_inspection) 來監控請求。 網路服務供應商也可以根據共同特徵封鎖請求，無論你使用哪種 DNS 伺服器。 未加密的 DNS 總是使用 53 號[端口](https://en.wikipedia.org/wiki/Port_(computer_networking)) ，並且總是使用UDP。
|
||||
|
||||
接下來，我們將討論並提供一個教程來證明外部觀察者可以使用普通的未加密 DNS 和 [加密 DNS ](#what-is-encrypted-dns)看到什麼。
|
||||
|
||||
### 未加密的 DNS
|
||||
|
||||
1. 使用 [`tshark`](https://www.wireshark.org/docs/man-pages/tshark.html) （ [Wireshark](https://en.wikipedia.org/wiki/Wireshark) 項目的一部分） ，我們可以監控和記錄網路封包的傳輸。 This command records packets that meet the rules specified:
|
||||
|
||||
```bash
|
||||
tshark -w /tmp/dns.pcap udp port 53 and host 1.1.1.1 or host 8.8.8.8
|
||||
```
|
||||
|
||||
2. We can then use [`dig`](https://en.wikipedia.org/wiki/Dig_(command)) (Linux, MacOS etc) or [`nslookup`](https://en.wikipedia.org/wiki/Nslookup) (Windows) to send the DNS lookup to both servers. Software such as web browsers do these lookups automatically, unless they are configured to use encrypted DNS.
|
||||
|
||||
=== "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. Next, we want to [analyse](https://www.wireshark.org/docs/wsug_html_chunked/ChapterIntroduction.html#ChIntroWhatIs) the results:
|
||||
|
||||
=== "Wireshark"
|
||||
|
||||
```
|
||||
wireshark -r /tmp/dns.pcap
|
||||
```
|
||||
|
||||
=== "tshark"
|
||||
|
||||
```
|
||||
tshark -r /tmp/dns.pcap
|
||||
```
|
||||
|
||||
如果執行上面的 Wireshark 命令，頂部窗格會顯示「[frame](https://en.wikipedia.org/wiki/Ethernet_frame)」，底部窗格會顯示所選框架的所有資料。 企業過濾和監控解決方案（例如政府購買的解決方案）可以自動執行此過程，而無需人工交互，並且可以聚合這些框架以產生對網路觀察者有用的統計數據。
|
||||
|
||||
| No. | Time | Source | Destination | Protocol | Length | Info |
|
||||
| --- | -------- | --------- | ----------- | -------- | ------ | ---------------------------------------------------------------------- |
|
||||
| 1 | 0.000000 | 192.0.2.1 | 1.1.1.1 | DNS | 104 | Standard query 0x58ba A privacyguides.org OPT |
|
||||
| 2 | 0.293395 | 1.1.1.1 | 192.0.2.1 | DNS | 108 | Standard query response 0x58ba A privacyguides.org A 198.98.54.105 OPT |
|
||||
| 3 | 1.682109 | 192.0.2.1 | 8.8.8.8 | DNS | 104 | Standard query 0xf1a9 A privacyguides.org OPT |
|
||||
| 4 | 2.154698 | 8.8.8.8 | 192.0.2.1 | DNS | 108 | Standard query response 0xf1a9 A privacyguides.org A 198.98.54.105 OPT |
|
||||
|
||||
An observer could modify any of these packets.
|
||||
|
||||
## 什麼是「加密後的 DNS」 ？
|
||||
|
||||
加密 DNS 可以引用許多協議之一，最常見的是：
|
||||
|
||||
### DNSCrypt
|
||||
|
||||
[**DNSCrypt**](https://en.wikipedia.org/wiki/DNSCrypt) 是第一種查詢加密 DNS 的方法之一。 DNSCrypt operates on port 443 and works with both the TCP or UDP transport protocols. DNSCrypt has never been submitted to the [Internet Engineering Task Force (IETF)](https://en.wikipedia.org/wiki/Internet_Engineering_Task_Force) nor has it gone through the [Request for Comments (RFC)](https://en.wikipedia.org/wiki/Request_for_Comments) process, so it has not been used widely outside of a few [implementations](https://dnscrypt.info/implementations). As a result, it has been largely replaced by the more popular [DNS over HTTPS](#dns-over-https-doh).
|
||||
|
||||
### DNS over TLS (DoT)
|
||||
|
||||
[**DNS over TLS**](https://en.wikipedia.org/wiki/DNS_over_TLS) is another method for encrypting DNS communication that is defined in [RFC 7858](https://datatracker.ietf.org/doc/html/rfc7858). Support was first implemented in Android 9, iOS 14, and on Linux in [systemd-resolved](https://www.freedesktop.org/software/systemd/man/resolved.conf.html#DNSOverTLS=) in version 237. Preference in the industry has been moving away from DoT to DoH in recent years, as DoT is a [complex protocol](https://dnscrypt.info/faq/) and has varying compliance to the RFC across the implementations that exist. DoT also operates on a dedicated port 853 which can be blocked easily by restrictive firewalls.
|
||||
|
||||
### DNS over HTTPS (DoH)
|
||||
|
||||
[**DNS over HTTPS**](https://en.wikipedia.org/wiki/DNS_over_HTTPS) as defined in [RFC 8484](https://datatracker.ietf.org/doc/html/rfc8484) packages queries in the [HTTP/2](https://en.wikipedia.org/wiki/HTTP/2) protocol and provides security with HTTPS. Support was first added in web browsers such as Firefox 60 and Chrome 83.
|
||||
|
||||
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).
|
||||
|
||||
## 外部人士可以看到什麼？
|
||||
|
||||
在此範例中，我們將記錄當我們提出 DoH 請求時發生的事情：
|
||||
|
||||
1. First, start `tshark`:
|
||||
|
||||
```bash
|
||||
tshark -w /tmp/dns_doh.pcap -f "tcp port https and host 1.1.1.1"
|
||||
```
|
||||
|
||||
2. Second, make a request with `curl`:
|
||||
|
||||
```bash
|
||||
curl -vI --doh-url https://1.1.1.1/dns-query https://privacyguides.org
|
||||
```
|
||||
|
||||
3. After making the request, we can stop the packet capture with <kbd>CTRL</kbd> + <kbd>C</kbd>.
|
||||
|
||||
4. Analyse the results in Wireshark:
|
||||
|
||||
```bash
|
||||
wireshark -r /tmp/dns_doh.pcap
|
||||
```
|
||||
|
||||
We can see the [connection establishment](https://en.wikipedia.org/wiki/Transmission_Control_Protocol#Connection_establishment) and [TLS handshake](https://www.cloudflare.com/learning/ssl/what-happens-in-a-tls-handshake/) that occurs with any encrypted connection. When looking at the "application data" packets that follow, none of them contain the domain we requested or the IP address returned.
|
||||
|
||||
## 什麼時候 **不該** 使用加密的 DNS ？
|
||||
|
||||
在有網路過濾（或審查）的地方，訪問被禁止的資源可能會產生某些後果，您應該在 [威脅模型](../basics/threat-modeling.md)中考慮這些後果。 We do **not** suggest the use of encrypted DNS for this purpose. Use [Tor](https://torproject.org) or a [VPN](../vpn.md) instead. 如果您使用的是VPN ，則應使用 VPN 的 DNS 伺服器。 使用 VPN 時，您已經信任它們與您的所有網路活動。
|
||||
|
||||
當我們進行 DNS 查詢時，通常是因為我們想要存取資源。 接下來，我們將討論一些即使在使用加密 DNS 時也可能會披露您的瀏覽活動的情況：
|
||||
|
||||
### IP 位址
|
||||
|
||||
確定瀏覽活動的最簡單方法可能是查看您的設備正在訪問的 IP 位址。 例如，如果觀察者知道 `privacyguides.org` 位於 `198.98.54.105`，而您的裝置正在請求 `198.98.54.105`的數據，則很有可能您正在訪問隱私指南。
|
||||
|
||||
此方法僅在 IP 位址屬於僅託管少數網站的伺服器時才有用。 如果網站託管在共享平臺上（例如Github Pages ， Cloudflare Pages ， Netlify ， WordPress ， Blogger等） ，它也不是很有用。 如果服務器託管在 [反向代理](https://en.wikipedia.org/wiki/Reverse_proxy)之後，這也不是很有用，這在現代互聯網上非常常見。
|
||||
|
||||
### 伺服器名指示(SNI)
|
||||
|
||||
伺服器名稱指示通常用於IP位址託管多個網站時。 This could be a service like Cloudflare, or some other [Denial-of-service attack](https://en.wikipedia.org/wiki/Denial-of-service_attack) protection.
|
||||
|
||||
1. Start capturing again with `tshark`. We've added a filter with our IP address so you don't capture many packets:
|
||||
|
||||
```bash
|
||||
tshark -w /tmp/pg.pcap port 443 and host 198.98.54.105
|
||||
```
|
||||
|
||||
2. Then we visit [https://privacyguides.org](https://privacyguides.org).
|
||||
|
||||
3. After visiting the website, we want to stop the packet capture with <kbd>CTRL</kbd> + <kbd>C</kbd>.
|
||||
|
||||
4. Next we want to analyze the results:
|
||||
|
||||
```bash
|
||||
wireshark -r /tmp/pg.pcap
|
||||
```
|
||||
|
||||
We will see the connection establishment, followed by the TLS handshake for the Privacy Guides website. Around frame 5. you'll see a "Client Hello".
|
||||
|
||||
5. Expand the triangle ▸ next to each field:
|
||||
|
||||
```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. We can see the SNI value which discloses the website we are visiting. The `tshark` command can give you the value directly for all packets containing a SNI value:
|
||||
|
||||
```bash
|
||||
tshark -r /tmp/pg.pcap -Tfields -Y tls.handshake.extensions_server_name -e tls.handshake.extensions_server_name
|
||||
```
|
||||
|
||||
This means even if we are using "Encrypted DNS" servers, the domain will likely be disclosed through SNI. The [TLS v1.3](https://en.wikipedia.org/wiki/Transport_Layer_Security#TLS_1.3) protocol brings with it [Encrypted Client Hello](https://blog.cloudflare.com/encrypted-client-hello/), which prevents this kind of leak.
|
||||
|
||||
Governments, in particular [China](https://www.zdnet.com/article/china-is-now-blocking-all-encrypted-https-traffic-using-tls-1-3-and-esni/) and [Russia](https://www.zdnet.com/article/russia-wants-to-ban-the-use-of-secure-protocols-such-as-tls-1-3-doh-dot-esni/), have either already [started blocking](https://en.wikipedia.org/wiki/Server_Name_Indication#Encrypted_Client_Hello) it or expressed a desire to do so. 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. 這是因為作為HTTP/3的一部分的 [QUIC](https://en.wikipedia.org/wiki/QUIC) 協議要求 `ClientHello` 也被加密。
|
||||
|
||||
### Online Certificate Status Protocol (OCSP)
|
||||
|
||||
Another way your browser can disclose your browsing activities is with the [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. This is generally done through the HTTP protocol, meaning it is **not** encrypted.
|
||||
|
||||
The OCSP request contains the certificate "[serial number](https://en.wikipedia.org/wiki/Public_key_certificate#Common_fields)", which is unique. It is sent to the "OCSP responder" in order to check its status.
|
||||
|
||||
We can simulate what a browser would do using the [`openssl`](https://en.wikipedia.org/wiki/OpenSSL) command.
|
||||
|
||||
1. Get the server certificate and use [`sed`](https://en.wikipedia.org/wiki/Sed) to keep just the important part and write it out to a file:
|
||||
|
||||
```bash
|
||||
openssl s_client -connect privacyguides.org:443 < /dev/null 2>&1 |
|
||||
sed -n '/^-*BEGIN/,/^-*END/p' > /tmp/pg_server.cert
|
||||
```
|
||||
|
||||
2. Get the intermediate certificate. [Certificate Authorities (CA)](https://en.wikipedia.org/wiki/Certificate_authority) normally don't sign a certificate directly; they use what is known as an "intermediate" certificate.
|
||||
|
||||
```bash
|
||||
openssl s_client -showcerts -connect privacyguides.org:443 < /dev/null 2>&1 |
|
||||
sed -n '/^-*BEGIN/,/^-*END/p' > /tmp/pg_and_intermediate.cert
|
||||
```
|
||||
|
||||
3. The first certificate in `pg_and_intermediate.cert` is actually the server certificate from step 1. We can use `sed` again to delete until the first instance of END:
|
||||
|
||||
```bash
|
||||
sed -n '/^-*END CERTIFICATE-*$/!d;:a n;p;ba' \
|
||||
/tmp/pg_and_intermediate.cert > /tmp/intermediate_chain.cert
|
||||
```
|
||||
|
||||
4. Get the OCSP responder for the server certificate:
|
||||
|
||||
```bash
|
||||
openssl x509 -noout -ocsp_uri -in /tmp/pg_server.cert
|
||||
```
|
||||
|
||||
Our certificate shows the Lets Encrypt certificate responder. If we want to see all the details of the certificate we can use:
|
||||
|
||||
```bash
|
||||
openssl x509 -text -noout -in /tmp/pg_server.cert
|
||||
```
|
||||
|
||||
5. Start the packet capture:
|
||||
|
||||
```bash
|
||||
tshark -w /tmp/pg_ocsp.pcap -f "tcp port http"
|
||||
```
|
||||
|
||||
6. Make the OCSP request:
|
||||
|
||||
```bash
|
||||
openssl ocsp -issuer /tmp/intermediate_chain.cert \
|
||||
-cert /tmp/pg_server.cert \
|
||||
-text \
|
||||
-url http://r3.o.lencr.org
|
||||
```
|
||||
|
||||
7. Open the capture:
|
||||
|
||||
```bash
|
||||
wireshark -r /tmp/pg_ocsp.pcap
|
||||
```
|
||||
|
||||
There will be two packets with the "OCSP" protocol: a "Request" and a "Response". For the "Request" we can see the "serial number" by expanding the triangle ▸ next to each field:
|
||||
|
||||
```bash
|
||||
▸ Online Certificate Status Protocol
|
||||
▸ tbsRequest
|
||||
▸ requestList: 1 item
|
||||
▸ Request
|
||||
▸ reqCert
|
||||
serialNumber
|
||||
```
|
||||
|
||||
For the "Response" we can also see the "serial number":
|
||||
|
||||
```bash
|
||||
▸ Online Certificate Status Protocol
|
||||
▸ responseBytes
|
||||
▸ BasicOCSPResponse
|
||||
▸ tbsResponseData
|
||||
▸ responses: 1 item
|
||||
▸ SingleResponse
|
||||
▸ certID
|
||||
serialNumber
|
||||
```
|
||||
|
||||
8. Or use `tshark` to filter the packets for the Serial Number:
|
||||
|
||||
```bash
|
||||
tshark -r /tmp/pg_ocsp.pcap -Tfields -Y ocsp.serialNumber -e ocsp.serialNumber
|
||||
```
|
||||
|
||||
If the network observer has the public certificate, which is publicly available, they can match the serial number with that certificate and therefore determine the site you're visiting from that. The process can be automated and can associate IP addresses with serial numbers. It is also possible to check [Certificate Transparency](https://en.wikipedia.org/wiki/Certificate_Transparency) logs for the serial number.
|
||||
|
||||
## Should I use encrypted DNS?
|
||||
|
||||
We made this flow chart to describe when you *should* use encrypted DNS:
|
||||
|
||||
``` 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 or Tor)
|
||||
censorship --> | No | privacy{Want privacy<br> from ISP?}
|
||||
privacy --> | Yes | vpnOrTor
|
||||
privacy --> | No | obnoxious{ISP makes<br> obnoxious<br> redirects?}
|
||||
obnoxious --> | Yes | encryptedDNS(Use<br> encrypted DNS<br> with 3rd party)
|
||||
obnoxious --> | No | ispDNS{Does ISP support<br> encrypted DNS?}
|
||||
ispDNS --> | Yes | useISP(Use<br> encrypted DNS<br> with 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.
|
||||
|
||||
[List of recommended DNS servers](../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>
|
||||
|
||||
## What is QNAME minimization?
|
||||
|
||||
A QNAME is a "qualified name", for example `privacyguides.org`. QNAME minimisation reduces the amount of information sent from the DNS server to the [authoritative name server](https://en.wikipedia.org/wiki/Name_server#Authoritative_name_server).
|
||||
|
||||
Instead of sending the whole domain `privacyguides.org`, QNAME minimization means the DNS server will ask for all the records that end in `.org`. Further technical description is defined in [RFC 7816](https://datatracker.ietf.org/doc/html/rfc7816).
|
||||
|
||||
## What is EDNS Client Subnet (ECS)?
|
||||
|
||||
The [EDNS Client Subnet](https://en.wikipedia.org/wiki/EDNS_Client_Subnet) is a method for a recursive DNS resolver to specify a [subnetwork](https://en.wikipedia.org/wiki/Subnetwork) for the [host or client](https://en.wikipedia.org/wiki/Client_(computing)) which is making the DNS query.
|
||||
|
||||
It's intended to "speed up" delivery of data by giving the client an answer that belongs to a server that is close to them such as a [content delivery network](https://en.wikipedia.org/wiki/Content_delivery_network), which are often used in video streaming and serving JavaScript web apps.
|
||||
|
||||
This feature does come at a privacy cost, as it tells the DNS server some information about the client's location.
|
||||
|
||||
--8<-- "includes/abbreviations.zh-Hant.txt"
|
||||
81
i18n/zh-Hant/advanced/tor-overview.md
Normal file
81
i18n/zh-Hant/advanced/tor-overview.md
Normal file
@@ -0,0 +1,81 @@
|
||||
---
|
||||
title: "Tor 簡介"
|
||||
icon: 'simple/torproject'
|
||||
---
|
||||
|
||||
Tor 是一個免費使用的去中心化網路，專為盡可能多地使用互聯網而設計。 如果使用得當，該網路可以實現私人和匿名瀏覽和通信。
|
||||
|
||||
## 工作原理
|
||||
|
||||
Tor 的工作原理是通過一個由數千個志願者運行的服務器組成的網絡路由您的流量，稱為節點（或中繼）。
|
||||
|
||||
每當您連接到 Tor 時，它都會選擇三個節點來構建通往網際網路的路徑，這種路徑稱為「電路」。 每個節點都有自己的功能：
|
||||
|
||||
### 入口節點
|
||||
|
||||
入口節點，通常稱為守護節點，是Tor客戶端連接的第一個節點。 入口節點能夠看到您的 IP 位址，但無法看到您正在連接的內容。
|
||||
|
||||
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]
|
||||
|
||||
### 中間節點
|
||||
|
||||
中間節點是 Tor 客戶端連接的第二個節點。 它可以看到流量來自哪個節點（入口節點）以及它下一步要去哪個節點。 中間節點無法看到您的 IP 位址或您連接的網域。
|
||||
|
||||
對於每個新電路，中間節點會從所有可用的 Tor 節點中隨機選擇。
|
||||
|
||||
### 出口節點
|
||||
|
||||
出口節點是您的 Web 流量離開 Tor 網路並轉發到所需目的地的點。 The exit node is unable to see your IP address, but it does know what site it's connecting to.
|
||||
|
||||
出口節點將從所有可用的 Tor 節點中隨機選擇，並使用退出中繼標記。[^ 2]
|
||||
|
||||
<figure markdown>
|
||||
|
||||
|
||||
<figcaption>Tor circuit pathway</figcaption>
|
||||
</figure>
|
||||
|
||||
## 加密
|
||||
|
||||
Tor 使用來自出口，中間和入口節點的密鑰對每個數據包（傳輸數據區塊）進行三次加密，依此順序。
|
||||
|
||||
一旦 Tor 構建了電路，數據傳輸將按照以下方式進行：
|
||||
|
||||
1. 首先：當數據包到達入口節點時，第一層加密被移除。 在這個加密數據包中，入口節點將找到另一個具有中間節點地址的加密數據包。 然後，入口節點將將數據包轉發到中間節點。
|
||||
|
||||
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.
|
||||
|
||||
下面是一個替代圖表，顯示了這個過程。 每個節點都會移除自己的加密層，當目標服務器返回數據時，同樣的過程完全相反。 例如，退出節點不知道你是誰，但它確實知道它來自哪個節點，因此它添加了自己的加密層並將其發送回來。
|
||||
|
||||
<figure markdown>
|
||||
|
||||
|
||||
<figcaption>Sending and receiving data through the Tor Network</figcaption>
|
||||
</figure>
|
||||
|
||||
Tor 允許我們連接到服務器，而不需要任何一方知道整個路徑。 入口節點知道你是誰，但不知道你要去哪裡；中間節點不知道你是誰或你要去哪裡；出口節點知道你要去哪裡，但不知道你是誰。 由於出口節點負責了最終連線，目標伺服器永遠不會知道您的 IP 位址。
|
||||
|
||||
## 注意事項
|
||||
|
||||
雖然 Tor 確實提供了強大的隱私保證，但必須意識到 Tor 並不完美：
|
||||
|
||||
- 資金充足的對手有能力被動地觀察全球大多數網絡流量，他們有機會通過先進的流量分析來解除 Tor 用戶的匿名化。 Tor 也不能保護你免於錯誤地暴露自己，例如如果你分享了太多關於你真實身份的信息。
|
||||
- Tor 出口節點還可以監控通過它們的流量。 這意味著可以記錄和監控未加密的流量，例如純 HTTP 流量。 如果此類流量包含個人身份識別信息，則可以將您去匿名化到該出口節點。 因此，我們建議在可能的情況下使用 HTTPS。
|
||||
|
||||
如果您希望使用 Tor 瀏覽網頁，我們只建議使用 **官方** Tor 瀏覽器：它旨在防止指紋。
|
||||
|
||||
- [Tor Browser :material-arrow-right-drop-circle:](../tor.md#tor-browser)
|
||||
|
||||
## Additional Resources
|
||||
|
||||
- [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.zh-Hant.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