mirror of
https://github.com/privacyguides/i18n.git
synced 2025-11-11 10:58:00 +00:00
New Crowdin translations by GitHub Action
This commit is contained in:
Crowdin Bot
103
i18n/zh-Hant/advanced/communication-network-types.md
Normal file
103
i18n/zh-Hant/advanced/communication-network-types.md
Normal file
@@ -0,0 +1,103 @@
|
||||
---
|
||||
title: "通訊網路的類型"
|
||||
icon: 'material/transit-connection-variant'
|
||||
description: 簡介常見的即時通訊應用程式網路架構。
|
||||
---
|
||||
|
||||
有幾種網絡架構常運用於在人與人之間傳遞消息。 這些網路提供不同的隱私保證，這就是為什麼在決定使用哪個應用程式時，最好能考慮您的[威脅模型](../basics/threat-modeling.md) 。
|
||||
|
||||
[推薦的即時通訊工具](../real-time-communication.md ""){.md-button}
|
||||
|
||||
## 集中式網絡
|
||||
|
||||
{ align=left }
|
||||
|
||||
集中式信使是指所有參與者都在同一伺服器或同一組織所控制的伺服器網絡。
|
||||
|
||||
有些自託管信使允許設置自己的伺服器。 自託管可以提供額外的隱私保證，例如不用記錄或限制讀取元數據（關於誰與誰交談的資料）。 自託管的集中式信使是隔離的，每個人都必須在同一個伺服器上進行通信。
|
||||
|
||||
**優點**
|
||||
|
||||
- 新功能和變更可以更快地實施。
|
||||
- 更容易使用和查找聯系人。
|
||||
- 近乎成熟和穩定的生態系統，因為集中式軟件更容易編程。
|
||||
- 當您信任自我託管的伺服器時，隱私問題可能會減少。
|
||||
|
||||
**缺點**
|
||||
|
||||
- [限制控制或存取](https://drewdevault.com/2018/08/08/Signal.html)。 可能包括以下內容：
|
||||
- 集中型網路 [禁封了](https://github.com/LibreSignal/LibreSignal/issues/37#issuecomment-217211165)可以提供更靈活自定與更佳使用體驗的第三方客戶端。 通常定義在使用條款和條件。
|
||||
- 對於第三方開發人員來說，文件記錄很糟。
|
||||
- 由單一實體控制服務時，其 [所有權](https://web.archive.org/web/20210729191953/https://blog.privacytools.io/delisting-wire/)、隱私政策和服務操作可輕易改變，甚致危及服務。
|
||||
- 自我託管需要精力和設置服務的知識。
|
||||
|
||||
## 聯邦式網絡
|
||||
|
||||
{ align=left }
|
||||
|
||||
聯合信使使用多個獨立的分散式伺服器，這些伺服器能夠彼此通訊（電子郵件是聯合服務的一個例子）。 聯邦讓系統管理員控制自己的伺服器，成為更大通訊網絡中的一員。
|
||||
|
||||
當自行託管時，聯邦伺服器的成員可以發現並與其他伺服器的成員進行通信，而有些伺服器可能會選擇保持私密而不加入聯邦（例如工作團隊伺服器）。
|
||||
|
||||
**優點**
|
||||
|
||||
- 運行自己的伺服器可以更加控制自己的資料。
|
||||
- 可從多個“公共”伺服器之中選擇信任的資料託付者。
|
||||
- 可讓第三方客戶端提供更原生、定制或親和的體驗。
|
||||
- 假設您有存取伺服器的權限或信任有此權限的人（例如，家庭成員），可以驗證伺服器軟體是否與公開原始碼相符。
|
||||
|
||||
**缺點**
|
||||
|
||||
- 添加新功能較複雜，因為這些功能需要標準化和測試，以確保可與網絡上的所有伺服器配合使用。
|
||||
- 根據前一點，與集中式平臺相比，聯邦式網絡欠缺完整功能或容易出現意外，例如離線時的訊息中繼或訊息刪除。
|
||||
- 可能會產生某些元數據（例如使用 E2EE 時， “誰在與誰交談”但不知其實際內容的資料）。
|
||||
- 聯邦式伺服器通常需要信任伺服器管理員。 他們可能是業餘愛好者，也不是“安全專業人士” ，欠缺標準文件，如隱私政策或服務條款，來詳細說明資料如何被使用。
|
||||
- 伺服器管理員有時會封鎖其他伺服器，因為它們無節制地濫用的或違反公認行為的一般規則。 這會阻礙您與這些伺服器成員溝通的能力。
|
||||
|
||||
## 對等網絡
|
||||
|
||||
{ align=left }
|
||||
|
||||
P2P 軟體連接到 [分佈式網路](https://en.wikipedia.org/wiki/Distributed_networking) 中的節點，在沒有第三方伺服器的情況下將訊息傳遞給收件人。
|
||||
|
||||
客戶端（對等軟體）通常通過 [分布式計算](https://en.wikipedia.org/wiki/Distributed_computing) 網絡找到彼此。 例如， [Distributed Hash Tables](https://en.wikipedia.org/wiki/Distributed_hash_table) (DHT)被 [torrents](https://en.wikipedia.org/wiki/BitTorrent_(protocol)) 和 [IPFS](https://en.wikipedia.org/wiki/InterPlanetary_File_System) 使用。 另一種方法是鄰近的網絡，通過WiFi或藍牙建立連接（例如， Briar 或 [Scuttlebutt](https://www.scuttlebutt.nz) 社交網絡協議）。
|
||||
|
||||
一旦對等體通過任何這些方法找到通往其聯繫的路徑，它們之間就會建立直接連接。 通常訊息內容會加密，但觀察者仍然可以推斷發件人和收件人的位置和身份。
|
||||
|
||||
P2P 網絡不使用伺服器，對等方彼此之間直接通信，因此不能自我託管。 但是，一些額外的服務可能要靠集中式伺服器，例如用戶看到或轉發離線消息，這些需要自託管伺服器的協助。
|
||||
|
||||
**優點**
|
||||
|
||||
- 最少的信息暴露給第三方。
|
||||
- 現代 P2P 平臺皆已預設為 E2EE。 不像集中和聯邦式網絡，沒有伺服器會攔截和解密您的傳輸。
|
||||
|
||||
**缺點**
|
||||
|
||||
- 精簡功能集：
|
||||
- 訊息只能在兩個對等方都在線時發送，但是，客戶端可能會在本地儲存訊息以等待聯絡人在線時送出。
|
||||
- 增加移動設備的電池使用量，因為客戶端必須保持與分佈式網絡的連接，以了解誰在線。
|
||||
- 缺少某些傳訊功能或不完整，例如訊息刪除。
|
||||
- 如果您未將軟體與 [VPN](../vpn.md) 或 [Tor](../tor.md)配合使用，則很可能暴露了自己和通訊聯絡人的 IP 位址。 許多國家都有某種形式的大規模監控和/或元數據保留。
|
||||
|
||||
## 匿名路由
|
||||
|
||||
{ align=left }
|
||||
|
||||
使用 [匿名路由](https://doi.org/10.1007/978-1-4419-5906-5_628) 的傳訊方式會隱藏發送者、接收者的身份或他們一直在溝通的證據。 理想情況下，這三種東西都該被隱藏。
|
||||
|
||||
匿名路由[有多種](https://doi.org/10.1145/3182658) 實現方式。 其中最著名 [洋蔥路由](https://en.wikipedia.org/wiki/Onion_routing) （即 [Tor](tor-overview.md)） ，該虛擬 [覆蓋網絡](https://en.wikipedia.org/wiki/Overlay_network) 隱藏節點位置以及收件人和發件人之間的加密訊息。 發送者和接收者不會直接互動，而是通過祕密會合節點，這樣就不會洩漏 IP 位址或物理位置。 節點無法解密訊息，也無法解密最終目的地；只有收件人可以。 中間節點只能解密下一步送到哪裡的指示，消息本體仍保持加密直到送達最終有權限解密的收件人，因此是“洋蔥層”。
|
||||
|
||||
在匿名路由網絡中自我託管節點無法增加額外隱私優勢，但有助於整個網絡軔性抵禦識別攻擊。
|
||||
|
||||
**優點**
|
||||
|
||||
- 很少甚至無資訊暴露給其他方。
|
||||
- 消息可以以分散的方式接力傳遞，即使其中一方離線。
|
||||
|
||||
**缺點**
|
||||
|
||||
- 消息傳播速度慢。
|
||||
- 通常僅支援少數媒體類型，因為網絡速度慢主要為文字傳輸。
|
||||
- 隨機路由選擇節點，某些節點可能遠離發送者和接收者，增加延遲，甚至因某個節點離線而無法傳輸消息。
|
||||
- 入手更複雜，因為需要創建和備份加密私鑰。
|
||||
- 如同其他分散式平臺，對開發人員而言，添加功能比集中式平臺更複雜。 因此，功能欠缺或未完全執行，例如離線消息中繼或消息刪除。
|
||||
354
i18n/zh-Hant/advanced/dns-overview.md
Normal file
354
i18n/zh-Hant/advanced/dns-overview.md
Normal file
@@ -0,0 +1,354 @@
|
||||
---
|
||||
title: "DNS 簡介"
|
||||
icon: material/dns
|
||||
description: 網域名稱系統是“網際網路電話簿” ，可幫助瀏覽器找到它正在尋找的網站。
|
||||
---
|
||||
|
||||
[網域名稱系統](https://en.wikipedia.org/wiki/Domain_Name_System) 是「網際網路的電話簿」。 DNS 將網域名稱轉換為 IP 位址，以便瀏覽器和其他服務可以通過分散的伺服器網路載入網路資源。
|
||||
|
||||
## 什麼是 DNS？
|
||||
|
||||
當您訪問一個網站時，會傳回一個數字地址。 以訪問 `privacyguides.org`網站為例，它傳回的地址為 `192.98.54.105` 。
|
||||
|
||||
DNS 從網際網路的 [早期](https://en.wikipedia.org/wiki/Domain_Name_System#History) 就存在了。 來往 DNS 伺服器的 DNS 請求通常 **不是** 加密的。 一般家用的網路中，客戶的伺服器通常是由 ISP 透過 [DHCP](https://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol)給予的。
|
||||
|
||||
未經加密的 DNS 請求很容易**被監視** 或在傳輸過程中**遭到修改modified**。 在某些地區， ISP 被要求做初級的 [DNS 過濾](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) 項目的一部分） ，我們可以監控和記錄網路封包的傳輸。 此命令記錄符合指定規則的封包：
|
||||
|
||||
```bash
|
||||
tshark -w /tmp/dns.pcap udp port 53 and host 1.1.1.1 or host 8.8.8.8
|
||||
```
|
||||
|
||||
2. 我們可以使用 [`dig`](https://en.wikipedia.org/wiki/Dig_(command)) （ Linux ， MacOS 等）或 [`nslookup`](https://en.wikipedia.org/wiki/Nslookup) （ Windows ）將DNS 查詢發送到伺服器。 Web 瀏覽器等軟體會自動執行這些查詢，除非它們被配置為使用加密的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. 接下來我們要[分析](https://www.wireshark.org/docs/wsug_html_chunked/ChapterIntroduction.html#ChIntroWhatIs) 結果:
|
||||
|
||||
=== "Wireshark"
|
||||
|
||||
```
|
||||
wireshark -r/tmp/dns.pcap
|
||||
```
|
||||
|
||||
=== "tshark"
|
||||
|
||||
```
|
||||
tshark -r /tmp/dns.pcap
|
||||
```
|
||||
|
||||
如果執行上面的 Wireshark 命令，頂部窗格會顯示「[frame](https://en.wikipedia.org/wiki/Ethernet_frame)」，底部窗格會顯示所選框架的所有資料。 企業過濾和監控解決方案（例如政府購買的解決方案）可以自動執行此過程，而無需人工交互，並且可以聚合這些框架以產生對網路觀察者有用的統計數據。
|
||||
|
||||
| 不。 | 時間 | 來源 | 目的地 | 協議 | 長度 | 資訊 |
|
||||
| -- | -------- | --------- | --------- | --- | --- | ----------------------------------------------------- |
|
||||
| 1 | 0.000000 | 192.0.2.1 | 1.1.1.1 | DNS | 104 | 標準查詢 0x58ba A privacyguides.org OPT |
|
||||
| 2 | 0.293395 | 1.1.1.1 | 192.0.2.1 | DNS | 108 | 標準查詢回應 0x58ba A privacyguides.org A 198.98.54.105 OPT |
|
||||
| 3 | 1.682109 | 192.0.2.1 | 8.8.8.8 | DNS | 104 | 標準查詢 0x58ba A privacyguides.org OPT |
|
||||
| 4 | 2.154698 | 8.8.8.8 | 192.0.2.1 | DNS | 108 | 標準查詢回應0xf1a9 A privacyguides.org A 198.98.54.105 OPT |
|
||||
|
||||
觀察者可以修改這些封包。
|
||||
|
||||
## 什麼是「加密後的 DNS」 ？
|
||||
|
||||
加密 DNS 可以引用許多協議之一，最常見的是：
|
||||
|
||||
### DNSCrypt
|
||||
|
||||
[**DNSCrypt**](https://en.wikipedia.org/wiki/DNSCrypt) 是第一種查詢加密 DNS 的方法之一。 DNSCrypt 在 443 端口上運作，與 TCP 或 UDP 傳輸協議一起使用。 DNSCrypt 從未向 [Internet Engineering Task Force (IETF)](https://en.wikipedia.org/wiki/Internet_Engineering_Task_Force)提交文件 ，也未通過 [Request for Comments (RFC)](https://en.wikipedia.org/wiki/Request_for_Comments) 流程，因此 [實用少](https://dnscrypt.info/implementations)並未被廣泛使用。 因此，它大量被更受歡迎的 [DNS over HTTPS](#dns-over-https-doh) 取代。
|
||||
|
||||
### 通過 TLS 的 DNS)
|
||||
|
||||
[**DNS over TLS**](https://en.wikipedia.org/wiki/DNS_over_TLS) 是另一種加密 DNS 通訊方式，其定義於 [RFC 7858](https://datatracker.ietf.org/doc/html/rfc7858)。 支持首先在Android 9 ， iOS 14和Linux的 [systemd-resolved](https://www.freedesktop.org/software/systemd/man/resolved.conf.html#DNSOverTLS=) 版本237中實現。 近年來，業界偏好已經從 DoT 轉移到 DoH ，因為 DoT 協議[複雜](https://dnscrypt.info/faq/) ，並且在實現中對RFC 的遵照狀況各不相同。 DoT 還在專用端口 853 上運行，但很容易被限制性防火牆阻止。
|
||||
|
||||
### 通過 HTTPS 的 DNS)
|
||||
|
||||
[**DNS over HTTPS**](https://en.wikipedia.org/wiki/DNS_over_HTTPS) 定義在 [RFC 8484](https://datatracker.ietf.org/doc/html/rfc8484) 文件，封包查詢透過[HTTP/2](https://en.wikipedia.org/wiki/HTTP/2) 協議，以 HTTPS 提供安全性。 最初使用於 Firefox 60 和 Chrome 83 等網頁瀏覽器。
|
||||
|
||||
DoH 原生執行出現在 iOS 14, macOS 11, Microsoft Windows, 與 Android 13 (不過其並未[預設啟動 ](https://android-review.googlesource.com/c/platform/packages/modules/DnsResolver/+/1833144))。 一般 Linux 桌面支援仍待 systemd [實現](https://github.com/systemd/systemd/issues/8639)， 所以 [還是得安裝第三方軟體](../dns.md#encrypted-dns-proxies)。
|
||||
|
||||
## 外部人士可以看到什麼？
|
||||
|
||||
在此範例中，我們將記錄當我們提出 DoH 請求時發生的事情：
|
||||
|
||||
1. 首先，打開 `tshark`：
|
||||
|
||||
```bash
|
||||
tshark -w /tmp/dns_doh.pcap -f "tcp port https and host 1.1.1.1"
|
||||
```
|
||||
|
||||
2. 其次，使用 `curl`提出請求：
|
||||
|
||||
```bash
|
||||
curl -vI --doh-url https://1.1.1.1/dns-query https://privacyguides.org
|
||||
```
|
||||
|
||||
3. 提出請求後，快速鍵 <kbd>CTRL</kbd> + <kbd>C</kbd>可停止封包捉取。
|
||||
|
||||
4. 在 Wireshark 中分析結果：
|
||||
|
||||
```bash
|
||||
wireshark -r /tmp/dns_doh.pcap
|
||||
```
|
||||
|
||||
[連接建立](https://en.wikipedia.org/wiki/Transmission_Control_Protocol#Connection_establishment) 在加密連接時會進行 [TLS 握手](https://www.cloudflare.com/learning/ssl/what-happens-in-a-tls-handshake/) 。 當查看隨後的“應用程序數據”封包時，都不包含所請求的域名或它的 IP 地址。
|
||||
|
||||
## 什麼時候 **不該** 使用加密的 DNS ？
|
||||
|
||||
在有網路過濾（或審查）的地方，訪問被禁止的資源可能會產生某些後果，您應該在 [威脅模型](../basics/threat-modeling.md)中考慮這些後果。 非常 **不建議**把加密 DNS 用在此目的上。 使用 [Tor](https://torproject.org) 或 [VPN](../vpn.md) 代替。 如果您使用的是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位址託管多個網站時。 這可能是像 Cloudflare 的服務，或者其他 [阻斷服務攻擊](https://en.wikipedia.org/wiki/Denial-of-service_attack) 保護。
|
||||
|
||||
1. 再次開始捕捉 `tshark`。 我們添加了一個自身IP 地址的過濾器，因此您不會捕獲過多封包：
|
||||
|
||||
```bash
|
||||
tshark -w /tmp/pg.pcap port 443 and host 198.98.54.105
|
||||
```
|
||||
|
||||
2. 然後訪問 [https://privacyguides.org](https://privacyguides.org)。
|
||||
|
||||
3. 在訪問網站後，以 <kbd>CTRL</kbd> + <kbd>C</kbd>停止封包捕捉。
|
||||
|
||||
4. 接下來分析結果：
|
||||
|
||||
```bash
|
||||
wireshark -r/tmp/pg.pcap
|
||||
```
|
||||
|
||||
連接建立後與 privacyguides 網站的TLS 握手。 大約在第5 幀附近。 你會看到一個“客戶你好”。
|
||||
|
||||
5. 展開每個字段旁邊的三角形 ▸ ：
|
||||
|
||||
```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. 我們可以看到我們正在訪問的網站的SNI值。 `tshark` 命令可以直接爲所有包含 SNI 封包提供值：
|
||||
|
||||
```bash
|
||||
tshark -r /tmp/pg.pcap -Tfields -Y tls.handshake.extensions_server_name -e tls.handshake.extensions_server_name
|
||||
```
|
||||
|
||||
即便使用「加密 DNS」伺服器，網域也可能會透過 SNI 披露。 [TLS v1.3](https://en.wikipedia.org/wiki/Transport_Layer_Security#TLS_1.3) 協議帶來了 [Encrypted Client Hello](https://blog.cloudflare.com/encrypted-client-hello/)，可以防止這種洩漏。
|
||||
|
||||
政府，特別是 [中國](https://www.zdnet.com/article/china-is-now-blocking-all-encrypted-https-traffic-using-tls-1-3-and-esni/) 和 [俄羅斯](https://www.zdnet.com/article/russia-wants-to-ban-the-use-of-secure-protocols-such-as-tls-1-3-doh-dot-esni/)，已經[開始封鎖](https://en.wikipedia.org/wiki/Server_Name_Indication#Encrypted_Client_Hello) ，或者有些表示將這樣做。 近來俄羅斯
|
||||
|
||||
開始屏蔽使用 [HTTP/3](https://en.wikipedia.org/wiki/HTTP/3)的外國網站。 這是因為作為HTTP/3的一部分的 [QUIC](https://en.wikipedia.org/wiki/QUIC) 協議要求 `ClientHello` 也被加密。</p>
|
||||
|
||||
|
||||
|
||||
### 線上憑邆狀態協議 (OCSP)
|
||||
|
||||
瀏覽器會披露瀏覽活動的另一種方式是使用 [線上憑證狀態協議 (Online Certificate Status Protocol)](https://en.wikipedia.org/wiki/Online_Certificate_Status_Protocol)。 訪問有 HTTPS 網站時，瀏覽器會檢查網站的 [憑證](https://en.wikipedia.org/wiki/Public_key_certificate) 是否已被撤銷。 這是透過 HTTP 協議完成的，這意味著它**不是** 加密的。
|
||||
|
||||
OCSP 請求包含憑證，其帶有獨特的"[序列號](https://en.wikipedia.org/wiki/Public_key_certificate#Common_fields)"。 它被發送到 “OCSP 回應器”去檢查其狀態。
|
||||
|
||||
利用 [`openssl`](https://en.wikipedia.org/wiki/OpenSSL) 命令模擬瀏覽器會做什麼。
|
||||
|
||||
1. 取得伺服器憑證並使用 [`sed`](https://en.wikipedia.org/wiki/Sed) 來保留重要部分並將其寫入檔案：
|
||||
|
||||
|
||||
|
||||
```bash
|
||||
openssl s_client -connect privacyguides.org:443 < /dev/null 2>&1 |
|
||||
sed -n '/^-*BEGIN/,/^-*END/p' > /tmp/pg_server.cert
|
||||
```
|
||||
|
||||
|
||||
2. 取得中間憑證。 [憑證授權機構(CA)](https://en.wikipedia.org/wiki/Certificate_authority) 通常不會直接簽署憑證；他們使用所謂的「中間」憑證。
|
||||
|
||||
|
||||
|
||||
```bash
|
||||
openssl s_client -showcerts -connect privacyguides.org:443 < /dev/null 2>&1 |
|
||||
sed -n '/^-*BEGIN/,/^-*END/p' > /tmp/pg_and_intermediate.cert
|
||||
```
|
||||
|
||||
|
||||
3. `pg_and_intermediate.cert` 中的第一個憑證實際上是步驟1 的伺服器憑證。 我們可以再次使用 `sed` 來刪除直到 END 第一個實例：
|
||||
|
||||
|
||||
|
||||
```bash
|
||||
sed -n '/^-*END CERTIFICATE-*$/!d;:a n;p;ba' \
|
||||
/tmp/pg_and_intermediate.cert > /tmp/intermediate_chain.cert
|
||||
```
|
||||
|
||||
|
||||
4. 取得伺服器憑證的OCSP 回應器：
|
||||
|
||||
|
||||
|
||||
```bash
|
||||
openssl x509 -noout -ocsp_uri -in /tmp/pg_server.cert
|
||||
```
|
||||
|
||||
|
||||
我們的憑證顯示 Lets Encrypt 憑證回應器。 如果我們想查看憑證的所有細節，我們可以使用：
|
||||
|
||||
|
||||
|
||||
```bash
|
||||
openssl x509 -text -noout -in /tmp/pg_server.cert
|
||||
```
|
||||
|
||||
|
||||
5. 開始捕取封包:
|
||||
|
||||
|
||||
|
||||
```bash
|
||||
tshark -w /tmp/pg_ocsp.pcap -f "tcp port http"
|
||||
```
|
||||
|
||||
|
||||
6. 提出 OCSP 要求：
|
||||
|
||||
|
||||
|
||||
```bash
|
||||
openssl ocsp -issuer /tmp/intermediate_chain.cert \
|
||||
-cert /tmp/pg_server.cert \
|
||||
-text \
|
||||
-url http://r3.o.lencr.org
|
||||
```
|
||||
|
||||
|
||||
7. 打開捕捉資料：
|
||||
|
||||
|
||||
|
||||
```bash
|
||||
wireshark -r /tmp/pg_ocsp.pcap
|
||||
```
|
||||
|
||||
|
||||
將會有兩個帶有「OCSP」通訊協定的封包：「Request」和「Response」。 對於“Request” ，可以通過擴展每個字段旁邊的三角形 ▸ 來看到“序列號” ：
|
||||
|
||||
|
||||
|
||||
```bash
|
||||
▸ Online Certificate Status Protocol
|
||||
▸ tbsRequest
|
||||
▸ requestList: 1 item
|
||||
▸ Request
|
||||
▸ reqCert
|
||||
serialNumber
|
||||
```
|
||||
|
||||
|
||||
對於“回應” ，我們也可以看到“序列號” ：
|
||||
|
||||
|
||||
|
||||
```bash
|
||||
▸ Online Certificate Status Protocol
|
||||
▸ responseBytes
|
||||
▸ BasicOCSPResponse
|
||||
▸ tbsResponseData
|
||||
▸ responses: 1 item
|
||||
▸ SingleResponse
|
||||
▸ certID
|
||||
serialNumber
|
||||
```
|
||||
|
||||
|
||||
8. 或者使用 `tshark` 來過濾序列號的封包：
|
||||
|
||||
|
||||
|
||||
```bash
|
||||
tshark -r /tmp/pg_ocsp.pcap -Tfields -Y ocsp.serialNumber -e ocsp.serialNumber
|
||||
```
|
||||
|
||||
|
||||
如果網路觀察者拿到可公開取得的公共憑證，就可將序列號與該憑證作匹配，從而確定您正在訪問的網站。 這個過程可以自動化，並且可以將IP地址與序列號相關聯。 也可檢查 [憑證透明度](https://en.wikipedia.org/wiki/Certificate_Transparency) 日誌的序列號。
|
||||
|
||||
|
||||
|
||||
## 我應該用加密 DNS 嗎？
|
||||
|
||||
這個流程圖描述了何時 *應該使用* 加密 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)
|
||||
```
|
||||
|
||||
|
||||
與第三方合作的加密 DNS 應限於避開重定向和基本的 [DNS 封鎖](https://en.wikipedia.org/wiki/DNS_blocking) ，也就是確定無後顧或對供應商的基本過濾感興趣時才用第三方。
|
||||
|
||||
[推薦的 DNS 伺服器列表](../dns.md ""){.md-button}
|
||||
|
||||
|
||||
|
||||
## 什麼是 DNSSEC ？
|
||||
|
||||
[Domain Name System Security Extensions](https://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions) (DNSSEC)是 DNS 的一項功能，域名查找的回應予以驗證。 它無法為查詢者提供隱私保護，而是防止攻擊者操縱或毒害對DNS 請求的回應。
|
||||
|
||||
換句話說， DNSSEC 對資料進行數位簽名，幫助確保其有效性。 為了確保安全查找，過程中的每個層級都會簽名。 因此，DNS 全部的回答都可以被信任。
|
||||
|
||||
DNSSEC 簽署過程類似於無法仿製的個人獨特簽名於法律文件，法院專家透過簽名驗證該文件效力須依據簽名的真假判定。 這些數位簽名確保資料不會被篡改。
|
||||
|
||||
DNSSEC 在所有 DNS 層中實施分級數位簽名政策。 例如，查詢 `privacyguides.org` ，根 DNS 伺服器將簽署尾綴 `.org` 伺服器密鑰，然後 `.org` 伺服器再簽署 `privacyguides.org`的授權名稱伺服器的密鑰。
|
||||
|
||||
<small>改編自 Google [DNS Security Extensions (DNSSEC) overview] (https://cloud.google.com/dns/docs/dnssec)和 Cloudflare [DNSSEC: An Introduction] (https://blog.cloudflare.com/dnssec-an-introduction/) ，兩者均根據[CC BY 4.0] (https://creativecommons.org/licenses/by/4 .0/)授權。</small>
|
||||
|
||||
|
||||
|
||||
## 什麼是QNAME最小化？
|
||||
|
||||
QNAME是“限定名稱” ，例如 `privacyguides.org`。 QNAME 最小化可減少從 DNS 伺服器傳送到 [授權名稱伺服器](https://en.wikipedia.org/wiki/Name_server#Authoritative_name_server)的資訊量。
|
||||
|
||||
與其傳送完整域名 `privacyguides.org`， QNAME最小化意味著 DNS 伺服器會請求所有 `.org`尾綴 的記錄。 進一步的技術描述在 [RFC 7816](https://datatracker.ietf.org/doc/html/rfc7816)。
|
||||
|
||||
|
||||
|
||||
## 什麼是 EDNS 客戶端子網(ECS ) ？
|
||||
|
||||
[EDNS Client Subnet](https://en.wikipedia.org/wiki/EDNS_Client_Subnet) 是遞歸DNS 解析器為DNS 查詢的 [主機或客戶端](https://en.wikipedia.org/wiki/Client_(computing))，指定 [子網絡](https://en.wikipedia.org/wiki/Subnetwork) 的方法。
|
||||
|
||||
它的目的是回答客戶端距離最靠近的伺服器以“加快”資料的傳遞，類似[內容傳遞網絡](https://en.wikipedia.org/wiki/Content_delivery_network)，後者通常用於視頻串流和 JavaScript Web 應用程序。
|
||||
|
||||
此功能確實以隱私為代價，因為它會告訴 DNS伺服器一些有關客戶端位置的資訊。
|
||||
84
i18n/zh-Hant/advanced/payments.md
Normal file
84
i18n/zh-Hant/advanced/payments.md
Normal file
@@ -0,0 +1,84 @@
|
||||
---
|
||||
title: 私密支付
|
||||
icon: material/hand-coin
|
||||
---
|
||||
|
||||
購買習慣的資料視為廣告定位聖杯是有原因的：購買行為會洩漏有關當事人的許多寶貴資訊。 不幸的是，目前的金融體系在設計上不利隱私，使銀行、其他公司和政府能夠輕鬆追蹤交易。 然而，在私下付款方面，您有很多選擇。
|
||||
|
||||
## 現金
|
||||
|
||||
幾個世紀以來， **現金** 一直是私人支付的主要形式。 在大多數情況下，現金具有優秀的隱私性，在大多數國家被廣泛接受，並且是 **可替代的**，這意味著它是非唯一的，完全可互換。
|
||||
|
||||
現金支付法因國家而異。 在美國，10,000美元以上交易需在 [8300表格中](https://www.irs.gov/businesses/small-businesses-self-employed/form-8300-and-reporting-cash-payments-of-over-10000)對美國國稅局披露。 收款業必須驗證收款人的姓名、地址、職業、出生日期、社會安全號碼或其他TIN （部分例外）。 少於 3,000 美元交換和匯款，就無須身份證明。 現金鈔票有序號。 商家很少追蹤序號，但執法部門可以在針對性調查中用到它們。
|
||||
|
||||
儘管如此，現金仍是最好的選擇。
|
||||
|
||||
## 預付卡 & 禮品卡
|
||||
|
||||
在大多數雜貨店和便利店用現金購買禮品卡和預付卡相對簡單。 禮品卡通常不收取費用，但預付卡通常會收取費用，因此請留意其費用和到期日期。 為了減少欺詐行為，部分商店可能會在結帳時要求查看身分證件。
|
||||
|
||||
禮品卡通常每張上限為 200美元，有些禮品卡上限到 2,000 美元。 預付卡（例如：來自 Visa 或 Mastercard ）通常卡片額度為 1,000 美元。
|
||||
|
||||
禮品卡的缺點是受商家政策的約束，這些政策可能有糟糕的條款和限制。 例如，有些商家不接受禮品卡付款，或者對高風險用戶取消禮品卡的價值。 一旦您拿了由商家信用擔保的禮品卡，商家就會對這筆金額有強烈的控制權。
|
||||
|
||||
預付卡無法從 ATM 提取現金或在 Venmo 以應用程序中進行“點對點”付款。
|
||||
|
||||
對於大多數人來說，現金仍然是現場購物的最佳選擇。 禮品卡用處在於節省。 預付卡適用於不接受現金的地方。 網路中禮品卡和預付卡比現金更容易使用，也更容易透過加密貨幣獲得。
|
||||
|
||||
### 網上交易平臺
|
||||
|
||||
如果您有 [加密貨幣](../cryptocurrency.md)，可在線禮品卡市場購買禮品卡。 有服務在更高額度時有提供身份驗證選項，它們也允許帳戶只需提供電子郵件地址。 基本帳戶限額為每天 5,000-10,000 美元，身份驗證帳戶（如果有）的限額則更高。
|
||||
|
||||
在網上購買禮品卡時，通常會有小折扣。 預付卡通常以面值或收取服務費在網上銷售。 如果您使用加密貨幣購買預付卡和禮品卡，您最好使用強大隱私的 Monero 付款，下面將進一步說明。 使用可追溯的付款方式支付禮物卡，取消了用現金或 Monero 購買禮品卡的隱私優點。
|
||||
|
||||
- [網上禮品卡市場 :material-arrow-right-drop-circle:](../financial-services.md#gift-card-marketplaces)
|
||||
|
||||
## 虛擬卡
|
||||
|
||||
另一種保護個資免受線上商家侵害的方法是使用虛擬的一次性卡片，以掩蓋您的實際銀行或帳單資訊。 這可對付商家數據洩露，營銷機構粗糙的跟蹤或購買聯結以及線上資料盜竊。 **無法完全匿名**您的購買行為，也不能對金融機構隱瞞自身的資訊。 發行虛擬卡的常規金融機構受「瞭解您的客戶」( KYC )法律約束，這意味著您需要提供身份證明文件或其他識別信息。
|
||||
|
||||
- [推薦付款掩蔽服務 :material-arrow-right-drop-circle:](../financial-services.md#payment-masking-services)
|
||||
|
||||
這些往往是線上定期/訂閱付款的好選擇，而預付禮品卡則更適合一次性交易。
|
||||
|
||||
## 加密貨幣
|
||||
|
||||
加密貨幣是一種數位形式的貨幣，其設計上沒有中央機構如政府或銀行即自行運作。 *有些* 加密貨幣可以在線上私密交易，但許多使用公開區塊錬則無法保障交易隱私。 加密貨幣是非常不穩定的資產，這它們的價值可能隨時發生急速顯著變化。 因此，不建議加密貨幣作為長期價值儲存。 如果決定使用加密貨幣，請確保已充分了解其隱私，且投資金額不會變成災難性損失。
|
||||
|
||||
!!! 危險
|
||||
|
||||
絕大多數加密貨幣都在* *公共* *區塊鏈上運作，這意味著每筆交易都可公開知道。 這包括最知名的加密貨幣，如比特幣和以太坊。 加密貨幣的交易不應被視為私密，也不會保護您的匿名性。
|
||||
|
||||
此外，許多（如果不是大多數）加密貨幣都是騙局。 只用你信任的項目小心進行交易。
|
||||
|
||||
### 隱私幣
|
||||
|
||||
有許多加密貨幣聲稱通過匿名交易來提供隱私。 建議探用** 預設**為匿名交易的工具，以避免操作時發生錯誤。
|
||||
|
||||
- [推薦的加密貨幣 :material-arrow-right-drop-circle:](../cryptocurrency.md#coins)
|
||||
|
||||
隱私硬幣受到政府機構日益嚴格的監管。 2020年[美國稅務局 IRS 發表 $625,000 賞金](https://www.forbes.com/sites/kellyphillipserb/2020/09/14/irs-will-pay-up-to-625000-if-you-can-crack-monero-other-privacy-coins/?sh=2e9808a085cc)，來徵求工具破解 Bitcoin Lightning Network 和 Monero 交易隱私。 最後由 [二家公司](https://sam.gov/opp/5ab94eae1a8d422e88945b64181c6018/view) (Chainalysis and Integra Fec) 共同獲得 $1250000 美元，但外界並不知道所開發的工具是用在哪一種加密貨幣網路。 由於這些工具的保密性，追蹤加密貨幣的方法都未得到獨立的證實。隱私硬幣交易很可能被運用在針對性地調查，而大規模監控則無法阻止。
|
||||
|
||||
### 其他貨幣（比特幣、以太坊等）
|
||||
|
||||
絕大多數加密貨幣項目使用公共區塊鏈，這意味著所有交易記錄都很容易追溯和永久保存。 因此，我們強烈不鼓勵把加密貨幣用和隱私相關的事物上。
|
||||
|
||||
公開區塊錬上的匿名交易*理論上* 可行，比特幣維基就 [提出如何"完全匿名"交易的案例](https://en.bitcoin.it/wiki/Privacy#Example_-_A_perfectly_private_donation)。 然而，這樣需要複雜的設置，涉及Tor和“獨自挖掘”一個區塊來產生完全獨立的加密貨幣，多年來幾乎沒有任何愛好者實踐過。
|
||||
|
||||
= =您最好還是完全避免這些加密貨幣，並堅持使用預設隱私的加密貨幣。嘗試使用其他加密貨幣超出了本網站的範圍，非常不建議。
|
||||
|
||||
### 錢包保管
|
||||
|
||||
加密貨幣有兩種形式的錢包：託管錢包和非託管錢包。 託管錢包由集中式公司/交易所運營，錢包的私鑰由該公司持有，您可以使用用戶名和密碼從任何地方存取。 非託管錢包是您自己控制和管理錢包的私鑰。 假如可以保管好錢包的私鑰安全並備份，非保管錢包比保管錢包具有更大的安全性和審查抵抗力，因為您的加密貨幣不會被保管的公司竊取或凍結。 密鑰保管在隱私貨幣上尤其重要：保管錢包使運營公司能夠查看您的交易，否定了這些加密貨幣的隱私優勢。
|
||||
|
||||
### 取得
|
||||
|
||||
私下購買 [加密貨幣](../cryptocurrency.md) ，如Monero 可能很困難。 P2P 市場如 [LocalMonero](https://localmonero.co/)，為促進人群交易的平台，也是個可考慮的選擇。 如果使用需要 KYC的交易所是您可接受的風險(只要隨後的交易無法追蹤)。一個更容易的方式是從 [Kraken](https://kraken.com/)等交易所購買 Monero ，或者從 KYC 交易所購買比特幣/萊特幣，然後兌換為 Monero。 然後，您可以將購入的 Monero 提取到自己的非保管錢包，以便 日後私下使用。
|
||||
|
||||
如果您選擇這條路線，請確保以不同的時間和額度購買與用掉Monero 。 如果你在交易所購買 5000 美元的 Monero ，並在一個小時後花掉這筆錢，外部觀察者會將這些行為作關聯，無關 Monero 走的是通道。 驚人的購買和提前購買大量的Monero 以支應之後小額交易，可以避免這種陷阱。
|
||||
|
||||
## 其他注意事項
|
||||
|
||||
使用現金現場付款時，請務必謹記現場隱私。 安全攝影機無處不在。 不妨考慮穿著不顯眼的衣服和口罩（如外科口罩或N95 ）。 請勿註冊獎勵計劃或提供自己的相關資訊。
|
||||
|
||||
在網上購買時，理想情況下應該透過 [Tor](tor-overview.md)進行。 但是，許多商家不允許使用 Tor 購買。 可以考慮使用 [推薦的 VPN](../vpn.md) （使用現金、禮品卡或 Monero 支付），或利用咖啡店或圖書館免費 Wi-Fi 購買。 如果你訂購的是實體物品，則需要提供送遞地址。 您應該考慮使用郵政信箱、私人郵箱或工作地址。
|
||||
94
i18n/zh-Hant/advanced/tor-overview.md
Normal file
94
i18n/zh-Hant/advanced/tor-overview.md
Normal file
@@ -0,0 +1,94 @@
|
||||
---
|
||||
title: "Tor 簡介"
|
||||
icon: 'simple/torproject'
|
||||
description: Tor 是一個免費使用的去中心化網路，其讓用戶在使用網際網路之際盡可能地保護自己的隱私。
|
||||
---
|
||||
|
||||
Tor 是一個免費使用的去中心化網路，其讓用戶在使用網際網路之際盡可能地保護自己的隱私。 如果使用得當，該網路可以實現私人和匿名瀏覽和通訊。
|
||||
|
||||
## 連接明網服務的路徑建立
|
||||
|
||||
「明網服務」是用任何瀏覽器都可訪問的網站，例如 [privacyguides.org](https://www.privacyguides.org)。 Tor 允許您匿名連接到某些網站，由數千個志願者運行的伺服器組成的網絡引導您的流量，這些伺服器稱為節點（或中繼）。
|
||||
|
||||
每當您連接到 Tor 時，它都會選擇三個節點來構建通往網際網路的路徑，這種路徑稱為「迴路」。
|
||||
|
||||
<figure markdown>
|
||||
! [Tor 路徑顯示您的設備到達目的地網站之前所連接的入口節點，中間節點和出口節點] (../assets/img/how-tor-works/tor-path.svg#only-light)
|
||||
! Tor 路徑顯示您的設備到達目的地網站之前所連接的入口節點，中間節點和出口節點] (../assets/img/how-tor-works/tor-path-dark.svg#only-dark)
|
||||
<figcaption>Tor 迴路路徑</figcaption>
|
||||
</figure>
|
||||
|
||||
每個節點都有自己的功能：
|
||||
|
||||
### 入口節點
|
||||
|
||||
入口節點，通常稱為守護節點，是 Tor 客戶端連接的第一個節點。 入口節點能夠看到您的 IP 位址，但無法看到您正在連接的內容。
|
||||
|
||||
不像其它節點 Tor 客戶端會隨機地選取入口節點後持續使用二~三個月以防護某些外部攻擊 [^1]
|
||||
|
||||
### 中間節點
|
||||
|
||||
中間節點是 Tor 客戶端連接的第二個節點。 它可以看到流量來自哪個節點（入口節點）以及它下一步要去哪個節點。 中間節點無法看到您的 IP 位址或您連接的網域。
|
||||
|
||||
對於每個新迴路，中間節點是隨機從所有可用的 Tor 節點中選出。
|
||||
|
||||
### 出口節點
|
||||
|
||||
出口節點是您的 Web 流量離開 Tor 網路並轉發到所需目的地的點。 出口節點無法看到您的 IP 位址，但它知道將連接到哪個網站。
|
||||
|
||||
出口節點將從所有可用的 Tor 節點中隨機選擇，並使用退出中繼標記。[^ 2]
|
||||
|
||||
## Onion 服務的路徑建立
|
||||
|
||||
“Onion 服務” （也通常被稱為“隱藏服務” ）是只能由 Tor 瀏覽器訪問的網站。 這些網站有一個長串隨機生成的域名，結尾為 `.onion`。
|
||||
|
||||
在Tor中連接到 Onion服務的工作原理與連接到明網服務非常相似，但您的流量在到達目的地伺服器之前會通過 **6 個** 節點。 不過就如之前所言，其中只有三個節點會有助 *您的*匿名性，而另外三個節點則是為了保護 * Onion 服務* 匿名性，隱藏該網站的真正 IP 和位置，就如同 Tor 瀏覽器如何隱蔽您的 IP 一樣。
|
||||
|
||||
<figure style="width:100%" markdown>
|
||||
! [Tor路徑顯示您的流量通過您的三個Tor節點加上三個額外的Tor節點隱藏網站的身份] (../assets/img/how-tor-works/tor-path-hidden-service.svg#only-light)
|
||||
! [Tor路徑顯示您的流量被路由通過您的三個Tor節點加上三個額外的Tor節點隱藏網站的身份] (../assets/img/how-tor-works/tor-path-hidden-service-dark.svg#only-dark)
|
||||
<figcaption>Tor電路路徑與洋蔥服務。 <span class="pg-blue">藍色</span> 圍欄中的節點屬於您的瀏覽器，而 <span class="pg-red">紅色</span> 圍欄中的節點屬於伺服器，因此它們的身份對您是隱藏的。</figcaption>
|
||||
</figure>
|
||||
|
||||
## 加密
|
||||
|
||||
Tor 使用來自出口，中間和入口節點的密鑰對每個封包（傳輸數據區塊）依序進行三次加密。
|
||||
|
||||
一旦 Tor 構建了電路，數據傳輸將按照以下方式進行：
|
||||
|
||||
1. 首先：當數據包到達入口節點時，第一層加密被移除。 在這個加密封包中，入口節點將找到另一個具有中間節點地址的加密封包。 然後，入口節點將將封包轉發到中間節點。
|
||||
|
||||
2. 其次：當中間節點從入口節點接收到封包時，它也會利用其密鑰刪除一層加密，找到具有出口節點地址的加密數據包。 然後中間節點將數據包轉發到出口節點。
|
||||
|
||||
3. 最後：當退出節點收到其數據包時，它將使用其密鑰移除最後一層加密。 出口節點將看到目的地地址，並將封包轉發到該地址。
|
||||
|
||||
下面是顯示此過程的圖表。 每個節點都會移除自己的加密層，當目的地伺服器傳回數據時，同樣過程會再反向發生。 例如，出口節點不知道你是誰，但它確實知道封包來自哪個節點，因此添加了自己的加密層並將其發送回來。
|
||||
|
||||
<figure markdown>
|
||||
|
||||
|
||||
<figcaption>通過 Tor 網路發送與接數資料</figcaption>
|
||||
</figure>
|
||||
|
||||
Tor 允許我們連接到伺服器，而不讓任何一方知道完整路徑。 入口節點知道你是誰，但不知道你要去哪裡；中間節點不知道你是誰或你要去哪裡；出口節點知道你要去哪裡，但不知道你是誰。 由於出口節點負責了最終連線，目的地伺服器永遠不會知道您的 IP 位址。
|
||||
|
||||
## 注意事項
|
||||
|
||||
雖然 Tor 確實提供了強大的隱私保證，但必須意識到它並不完美：
|
||||
|
||||
- 資金充足的對手有能力被動地觀察全球大多數網絡流量，他們有機會通過先進的流量分析來解除 Tor 用戶的匿名化。 Tor 也不能保護你免於不當地暴露自己，例如你分享了太多關於你真實身份的信息。
|
||||
- Tor 出口節點還可以監控通過它們的流量。 這意味著可以記錄和監控未加密的流量，例如純 HTTP 流量。 如果此類流量包含個人身份識別信息，則該出口節點可以將會消除匿名性。 因此，我們建議在可能的情況下使用 HTTPS。
|
||||
|
||||
如果您希望使用 Tor 瀏覽網頁，我們只建議使用 **官方** Tor 瀏覽器：它旨在防止指紋。
|
||||
|
||||
- [Tor 瀏覽器 :material-arrow-right-drop-circle:](../tor.md#tor-browser)
|
||||
|
||||
## 其他資源
|
||||
|
||||
- [Tor 瀏覽器用戶手冊](https://tb-manual.torproject.org)
|
||||
- [ Tor 如何運作 - Computerphile](https://invidious.privacyguides.net/embed/QRYzre4bf7I?local=true) <small>(YouTube)</small>
|
||||
- [Tor O洋蔥服務- Computerphile](https://invidious.privacyguides.net/embed/lVcbq_a5N9I?local=true) <small>(YouTube)</small>
|
||||
|
||||
[^1]: 迴路中的第一個節點被稱為“入口守衛”或“守衛”。 它是一個快速和穩定的中繼站，作迴路中的第一個入口通常會維持 2~3個月，以防止已知的匿名破壞攻擊。 其餘的迴路則會依每次訪問網站而變化，這些中繼節點共同提供Tor 完整隱私保護。 了解更多關於守衛中繼的運作，請參考 [部落格文章](https://blog.torproject.org/improving-tors-anonymity-changing-guard-parameters) 和 [入口守衛論文paper](https://www-users.cs.umn.edu/~hoppernj/single_guard.pdf)。 ([https://support.torproject.org/tbb/tbb-2/](https://support.torproject.org/tbb/tbb-2/))
|
||||
|
||||
[^2]: 中繼標記：迴路位置（例如， “Guard” ， “Exit” ， “BadExit” ） ，迴路屬性（例如， “Fast” ， “Stable” ）或角色（例如， “Authority” ， “HSDir” ）這些中繼節點的特殊（ dis- ）資格，是由目錄機構分配並在目錄協議規範中進一步定義。 ([https://metrics.torproject.org/glossary.html](https://metrics.torproject.org/glossary.html))
|
||||
Reference in New Issue
Block a user