relay

對 Tor 網路的攻擊

在「Is “KAX17” performing de-anonymization Attacks against Tor Users?」這邊看到針對 Tor 網路攻擊的一些說明...

BTCMITM20 這組比較好理解，目標也比較明確：

primary motivation: financial profit (by replacing bitcoin addresses in tor exit traffic)

KAX17 這組看起來就比較像是政府單位在後面掛：

motivation: unknown; plausible: Sybil attack; collection of tor client and/or onion service IP addresses; deanonymization of tor users and/or onion services

其中可以看到同時掌握了不少 hop，這樣就很有機會一路串起來：

To provide a worst-case snapshot, on 2020–09–08 KAX17's overall tor network visibility would allow them to de-anonymize tor users with the following probabilities:

first hop probability (guard) : 10.34%

second hop probability (middle): 24.33%

last hop probability (exit): 4.6%

由於 Tor 是匿名網路，目前最好的防禦方式還是讓更多人參與加入節點，降低單一團體可以取得足夠組出的資料... 之後找機會整理一下跑了一年多 exit node 的想法好了。

Tor 在德國的 Relay 節點比重過高的問題

在「The German Problem with Tor」這邊提到了 Tor 在德國的 Relay 節點比重過高的問題，遠超過第二名的法國：

This is where we come to Germany, which has the highest amount of Tor relay capacity in the World at 167Gbps, in contrast France is in 2nd place with 64.5Gbps of capacity aka more than 100Gbps lower than Germany.

從 Welcome to Tor Metrics 這邊可以拉資料出來看，在「rs.html#aggregate/cc」這頁可以看到差距，現在德國的 Relay 是第一名，比重約 37.7%，法國則是第二名，但卻只佔了 16.7%。

主要還是頻寬費用的關係吧？畢竟網路上租主機時也可以感覺到，德國的頻寬真的很便宜...

自建 Mail System 的難度

在 Hacker News 上的「Ask HN: Is it possible to run your own mail server for personal use?」這篇道出了現在自建 mail system 的難度。作者遇到信件常常被各大 mail 服務歸類成 spam：

The problem is making sure my mail is not marked as spam by the major MTAs out there, gmail and hotmail both mark my mails as spam.

整理一下現在自己建 mail system 要做到哪些事情：

確認 IP (包括 IPv4/IPv6) 沒有列入任何 Open Relay 清單中。
確認 IP 的反解可以查出對應的正解。
確認 SPF 設定。
確認送出去的信件有 DKIM 簽名，而且 DNS 也有設上對應的設定。
確認 TLS 的發送與接收都正常。
確認 DMARC 機制正確運作。

如同「Exercising Software Freedom in the Global Email System」這邊講的，現在要自己搞 mail system 超累...

用 Go 寫的 Tor Relay Server

在 Zite 上看到的「Implementing a Tor relay from scratch」，用 Go 寫的 Tor Relay Server。

會跳下去用 Go 寫是因為效能上的考量：

[...], but the lack of AES-NI instructions on the CPUs cause a significant slowdown.

但因為一個 IP 只能跑兩個 instance，這就有點痛了：

To maximize the amount of relayed data, it is normal to simply run multiple instances of the program, up to two per IP address.

而作者的目標是超過現有的極限：

My final goal was to beat the Tor speed record, which was at roughly 200 megabytes per second.

成果就是直接吃滿 2Gbps (250MBytes/sec)，而且 CPU 只用了 60%：

[...] He set up a server with my relay and within a few days we had broken the Tor speed record with a nice 250 megabytes per second, effectively maxing out the network link. CPU usage was at a nice 60% across 12 cores. But his relay also suffered from the memory issues and had to be restarted every few days.

作者的程式碼放在 GitHub 上，之後應該會有人跳進去改寫：「A fast implementation of the Tor OR code, in Go」。

Mozilla 加入 Tor Relay 的行列

Mozilla 宣佈了他們提供硬體與網路，提昇 Tor 的隱私性：「Deploying tor relays」。可以在「Results for mozilla」這邊看到這一波有十二台上線了。

架構上完全獨立於目前的 production 環境 (所有的硬體與網路設備)，這是 Mozilla 提供的網路架構說明：

另外關於安全以及隱私性的部份，他們也提供了不少意見與說明。

像是單一組織不應該提供太多 bandwidth，這可以當做是避嫌：

A single organization shouldn’t be running more than 10Gbps of traffic for a middle relay (and 5Gbps for an exit node).

一個 Tor 節點需要兩個月的時候逐漸讓整個網路使用：

A new Tor instance (identified by its private/public key pair) will take time (up to 2 months) to use all its available bandwidth.

目前 Tor 的程式效能限制：

A Tor process (instance) can only push about 400Mbps.

這是 Tor 的安全限制：

A single public IP can only be shared by 2 Tor instances

這是避開防火牆的限制：

Listen on well known ports like 80 or 443