關於不推薦用 1.1.1.1 的事情...

最近剛好跟朋友有聊到 1.1.1.1,然後就有提到我不推薦使用 1.1.1.1 的原因。

主要是因為 Cloudflare 以隱私的理由所以不打算支援 EDNS Client Subnet (ECS),而 ECS 這項技術可以把 client 的 subnet 資訊帶給 DNS server,讓 DNS server 可以配出更精準的伺服器,而關於 Cloudflare 不支援的這點,可以在「1.1.1.1 supports ECS?」這邊看到一些討論。

這個問題在 Akamai 這種超大 CDN,在同一個地區的各 ISP 都有伺服器的情況下特別明顯。

以我家第四台的 cable 線路來說 (我的備用線路),是走亞太 (APOL) 的線路出去,如果從自己的 ISP 查 www.akamai.com 的位置,可以查到 23.76.81.151,用 mtr 可以發現是走到 EBIX (也是亞太) 裡面的伺服器:

gslin@rpi3p [~] [13:35] host www.akamai.com         
www.akamai.com is an alias for www.akamai.comv2.edgekey.net.
www.akamai.comv2.edgekey.net is an alias for e1699.dscx.akamaiedge.net.
e1699.dscx.akamaiedge.net has address 23.76.81.151
e1699.dscx.akamaiedge.net has IPv6 address 2600:1417:76:594::6a3
e1699.dscx.akamaiedge.net has IPv6 address 2600:1417:76:58a::6a3
gslin@rpi3p [~] [13:35] mtr -w 23.76.81.151
Start: 2020-04-05T13:35:49+0000
HOST: rpi3p                                              Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- unknown                                             0.0%    10    0.5   0.5   0.4   0.6   0.0
  2.|-- NK219-91-13-254.adsl.dynamic.apol.com.tw            0.0%    10    7.8   8.2   6.1  11.9   1.7
  3.|-- 10.251.11.6                                         0.0%    10   19.3  25.6  19.3  33.5   4.7
  4.|-- 10.251.231.5                                        0.0%    10   25.4  23.4  19.8  29.1   3.7
  5.|-- 10.251.231.1                                        0.0%    10    8.0  10.7   5.7  24.0   5.7
  6.|-- 10.251.230.34                                       0.0%    10   26.6  20.6   5.9 110.0  32.1
  7.|-- 10.251.230.29                                       0.0%    10   58.4  35.4   6.6  81.2  30.9
  8.|-- 202-178-245-162.cm.static.apol.com.tw               0.0%    10    9.5  18.4   7.4  78.5  21.3
  9.|-- 203-79-250-201.static.apol.com.tw                   0.0%    10    8.5   8.2   6.4   9.8   1.0
 10.|-- 211.76.96.191                                       0.0%    10    7.2  10.2   6.7  15.6   2.7
 11.|-- 203-79-254-10.ebix.net.tw                           0.0%    10  2226. 3802. 2226. 6017. 1314.6
 12.|-- a23-76-81-151.deploy.static.akamaitechnologies.com  0.0%    10    6.4   9.4   6.3  16.4   3.3

但如果從 1.1.1.1 查,會查到在中華電信內的 Akamai 伺服器,於是在尖峰時間反而變得很慢:

gslin@rpi3p [~] [13:36] host www.akamai.com 1.1.1.1
Using domain server:
Name: 1.1.1.1
Address: 1.1.1.1#53
Aliases: 

www.akamai.com is an alias for www.akamai.comv2.edgekey.net.
www.akamai.comv2.edgekey.net is an alias for e1699.dscx.akamaiedge.net.
e1699.dscx.akamaiedge.net has address 23.48.142.132
e1699.dscx.akamaiedge.net has IPv6 address 2001:b034:1:1ea7::6a3
e1699.dscx.akamaiedge.net has IPv6 address 2001:b034:1:1e9f::6a3
gslin@rpi3p [~] [13:39] mtr -w 23.48.142.132
Start: 2020-04-05T13:39:42+0000
HOST: rpi3p                                               Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- unknown                                              0.0%    10    0.4   0.5   0.4   0.6   0.1
  2.|-- NK219-91-13-254.adsl.dynamic.apol.com.tw             0.0%    10    8.7  17.0   6.1  81.2  22.8
  3.|-- 10.251.11.6                                          0.0%    10   26.7  24.6  21.4  29.3   2.8
  4.|-- 10.251.231.5                                         0.0%    10   26.8  29.9  16.8  88.6  21.0
  5.|-- 10.251.231.1                                         0.0%    10    7.2   8.3   6.8  12.7   1.8
  6.|-- 10.251.230.34                                        0.0%    10   10.3   8.9   5.9  11.0   1.6
  7.|-- 10.251.230.29                                        0.0%    10    6.3  10.1   5.4  31.7   7.8
  8.|-- 202-178-245-162.cm.static.apol.com.tw                0.0%    10    8.8   9.1   7.3  13.2   1.8
  9.|-- 203-79-250-209.static.apol.com.tw                    0.0%    10   10.0   8.6   6.3  10.8   1.5
 10.|-- 211.76.96.67                                         0.0%    10    7.9   9.0   4.0  12.4   2.6
 11.|-- 109-84-21-113-static.chief.net.tw                    0.0%    10   18.3  11.7   7.0  25.1   5.7
 12.|-- 21-252-123-103-static.chief.net.tw                   0.0%    10    9.4  10.0   7.7  15.0   2.2
 13.|-- 203-75-228-5.HINET-IP.hinet.net                      0.0%    10   10.1  10.8   7.0  21.2   4.3
 14.|-- r4209-s2.hinet.net                                   0.0%    10    9.4  10.5   6.3  17.9   3.7
 15.|-- tpdt-3012.hinet.net                                  0.0%    10   92.0  61.6  11.1 141.6  53.8
 16.|-- tpdt-3301.hinet.net                                  0.0%    10   42.9  38.8   7.3 100.8  33.6
 17.|-- a23-48-142-132.deploy.static.akamaitechnologies.com  0.0%    10    8.2  15.5   8.2  46.6  12.4

跨 ISP 的線路品質通常都沒有同一個 ISP 內來的好,但因為沒有 EDNS Client Subnet (ECS) 的資訊,所以只能導去當地 (地理上) 預設的點,latency 應該還是夠低,但頻寬就未必足夠了。

8.8.8.8 會好一點,但目前最建議的還是用 ISP 自家的 DNS resolver,當 ISP 的 DNS Resolver 不支援 EDNS Client Subnet 時,CDN 也還是會正確讀到 ISP 的資訊,配到的伺服器的頻寬就不會太差...

Google 用 x-client-data 追蹤使用者的問題

前陣子 Chromium 團隊在研究要移除 User-Agent 字串的事情 (參考「User-Agent 的淘汰提案」),結果 kiwibrowser 就直接炸下去,Google 很久前就會針對自家網站送出 x-client-data 這個 HTTP header,裡面足以辨識使用者瀏覽器的單一性:「Partial freezing of the User-Agent string#467」。

Google 的白皮書裡面是說用在 server 的試驗:

We want to build features that users want, so a subset of users may get a sneak peek at new functionality being tested before it’s launched to the world at large. A list of field trials that are currently active on your installation of Chrome will be included in all requests sent to Google. This Chrome-Variations header (X-Client-Data) will not contain any personally identifiable information, and will only describe the state of the installation of Chrome itself, including active variations, as well as server-side experiments that may affect the installation.

The variations active for a given installation are determined by a seed number which is randomly selected on first run. If usage statistics and crash reports are disabled, this number is chosen between 0 and 7999 (13 bits of entropy). If you would like to reset your variations seed, run Chrome with the command line flag “--reset-variation-state”. Experiments may be further limited by country (determined by your IP address), operating system, Chrome version and other parameters.

但因為這個預設值開啟的關係,就算關掉後也足以把使用者再分類到另外一個區塊,仍然具有高度辨識性,不是你 Google 說無法辨識就算數。

另外如果看 source code 裡的說明:

    // Note the criteria for attaching client experiment headers:
    // 1. We only transmit to Google owned domains which can evaluate
    // experiments.
    //    1a. These include hosts which have a standard postfix such as:
    //         *.doubleclick.net or *.googlesyndication.com or
    //         exactly www.googleadservices.com or
    //         international TLD domains *.google. or *.youtube..
    // 2. Only transmit for non-Incognito profiles.
    // 3. For the X-Client-Data header, only include non-empty variation IDs.

可以看到 *.doubleclick.net*.googlesyndication.comwww.googleadservices.com 全部都是廣告相關,另外 Google 自家搜尋引擎是直接提供廣告 (不透過前面提到的網域),YouTube 也是一樣的情況,所以完全可以猜測 x-client-data 這個資料就是用在廣告相關的系統上。

The Register 在「Is Chrome really secretly stalking you across Google sites using per-install ID numbers? We reveal the truth」這邊用粗體的 Update 提到了 GDPR 的問題,不確定是不是開始有單位在調查了:

Updated Google is potentially facing a massive privacy and GDPR row over Chrome sending per-installation ID numbers to the mothership.

在這個問題沒修正之前,只能暫時用操作 HTTP header 的 extension 移掉這個欄位。

User-Agent 的淘汰提案

看到廢除更新 User-Agent 字串的提案:「Intent to Deprecate and Freeze: The User-Agent string」。

一方面是 User-Agent 裡面太多沒用的假資料 (像是每一家都是 Mozilla),另外 User-Agent 會帶出一些隱私問題 (辨識資訊)。

目前的提案是希望改用 User-Agent Client Hints (UA-CH) 取代 User-Agent 的功能,把預定義好的東西透過對應的 HTTP header 傳遞。

Chromium 的計畫是在 M81 (stable 版預定在 2020 年三月中釋出) 先 deprecate navigator.userAgent,所以有存取時 web console 上會出現警告。而 M83 (2020 年六月初) 則是不再更動 user agent 字串 (鎖住)。到了 M85 (2020 年九月中) 則是統一 desktop 的 user agent 字串,並且盡可能統一 mobile 上的字串。

另外裡面也有整理了其他瀏覽器的意願:

Edge: Public support

Firefox: Public support for freezing the UA string - “freezing the User Agent string without any client hints—seems worth-prototyping”

Safari: Shipped to some extent. Safari has attempted to completely freeze the UA string in the past, without providing an alternative mechanism. That got a lot of pushback, which resulted in somewhat reverting that decision. Nowadays, their UA string seems frozen, other than updates to the OS version and the browser major version.

雖然不是完全都同意,但看起來應該有機會在今年陸陸續續搞定...

用 Amazon SES 發 Trac 通知信的問題

Trac 在發 ticket 的通知信時,會定義自己的 Message-ID,另外後續變更的通知信件會增加 References 欄位,讓 mail client 可以配對起來 (變成一個 thread)。

Amazon SES 會把原來的 Message-ID 改掉,使用自己的 Message-ID 欄位,可是 References 欄位仍然維持不變... 這就導致 mail client 無法將第一封信 (只有被改過的 Message-ID) 與後續的信件 (References 所指到的信件不存在) 配對起來,只剩下後續的信件因為有相同的 References,所以 mail client 可以正確的配對起來。

所以我就決定生一個 workaround plugin,只要是沒有 References 的信件 (像是每張 ticket 的第一封信),就從 Message-ID 複製一份到 References 裡,這樣就可以讓後續的通知信件與第一封也連結起來了。另外評估這個 workaround 的副作用應該還好,所以就不判斷是不是 ticket 的通知信了...

這就是 trac-references-mail-decorator 這個套件的由來...

AWS Client VPN 支援 Split-tunnel

VPN 的 Split-tunnel 指的是 partial routing,也就只針對部份 IP range 走進 VPN,其餘大多數的流量還是走原來的 Internet。

這個方式的安全性通常會比 full routing 低一些,因為這個方式會使得 internet 流量有機會穿進 VPN 內 (像是透過瀏覽器),但因為這可以讓使用者避免越洋的 VPN 導致速度下降過多,算是 VPN 常用的功能。

這次 AWS Client VPN 實做了這個功能:「AWS Client VPN now adds support for Split-tunnel」。

不過 AWS Client VPN 相較於自己架設貴不少,目前知道的單位大多也都還是自己架...

RTorrent 0.9.8

RTorrent 算是我在 command line 下很喜歡用的 bittorrent client,前幾天釋出 0.9.8 版,距離上一個版本 0.9.7 一年多了:「RTorrent release version 0.9.8」。

從 changelog 可以看到目前主要都還是一些維護性質的修改,像是 bugfix 以及對新的 library 的更新,功能增加的不多...

另外一個是最近提供了 donate 的管道:「Donate to rTorrent development」。在 2017 年的時候有寫信問他有沒有 Patreon,他當時說他人在日本沒辦法處理,看起來後來解決了...

Facebook 花錢向使用者購買他們的行為記錄

這則從 Nuzzel 上看到的,國外討論得很凶:「Facebook pays teens to install VPN that spies on them」。

Facebook 付錢給使用者,要他們安裝 VPN (以及 Root CA,看起來是為了聽 HTTPS 內容),然後從上面蒐集資料,這本身就不是什麼好聽的行為了,但更嚴重的問題在於包括了未成年人:

Since 2016, Facebook has been paying users ages 13 to 35 up to $20 per month plus referral fees to sell their privacy by installing the iOS or Android “Facebook Research” app. Facebook even asked users to screenshot their Amazon order history page. The program is administered through beta testing services Applause, BetaBound and uTest to cloak Facebook’s involvement, and is referred to in some documentation as “Project Atlas” — a fitting name for Facebook’s effort to map new trends and rivals around the globe.

這個計畫在 iOS 平台下架了,但 Android 平台看起來還是會繼續:

[Update 11:20pm PT: Facebook now tells TechCrunch it will shut down the iOS version of its Research app in the wake of our report. The rest of this article has been updated to reflect this development.]

Facebook’s Research program will continue to run on Android. We’re still awaiting comment from Apple on whether Facebook officially violated its policy and if it asked Facebook to stop the program. As was the case with Facebook removing Onavo Protect from the App Store last year, Facebook may have been privately told by Apple to voluntarily remove it.

未成年人部份應該會是重點,拉板凳出來看...

AWS 提供 OpenVPN-based VPN 服務

不知道為什麼在 feed reader 裡面沒注意到這則,後來是在 Facebook 上看到的。

AWS 推出了 OpenVPN-based 的 VPN 服務 AWS VPN:「Introducing AWS Client VPN to Securely Access AWS and On-Premises Resources」。

看起來是這個價錢:

AWS Client VPN pricing
$0.05 per AWS Client VPN connection hour
$0.10 per AWS Client VPN endpoint association hour

所以服務本身的費用要 $72/month 左右,另外 client 接上去的費用另外算?

目前支援的區域有限,暫時只有歐美的大區:

AWS Client VPN is available in US East (Virginia), US East (Ohio), US West (Oregon) and EU (Ireland) AWS Regions. Support for other AWS Regions is coming soon.

Cloudflare 同時支援 TLS 1.2 與 TLS 1.3 的過程

Cloudflare 算是很早就參與 TLS 1.3 發展的廠商。在參與過程中他們希望讓支援 TLS 1.3 draft 的瀏覽器可以開始使用 TLS 1.3 draft,但又不希望因為 draft 頻繁修改而導致本來的使用者受到影響,所以就找了方法讓兩者並存:「Know your SCM_RIGHTS」。

這個方法就是 SCM_RIGHTS,可以讓另外一個 process 存取自己的 file description。

You can use UNIX-domain sockets to pass file descriptors between applications, and like everything else in UNIX connections are files.

所以他們的作法就是先讀取 TLS 裡 Client Hello 的資料,如果裡面有看到想要使用 TLS 1.3 的訊息,就透過前面提到的 SCM_RIGHTS 丟進 Golang 寫的程式跑:

We let OpenSSL read the “Client Hello” message from an established TCP connection. If the “Client Hello” indicated TLS version 1.3, we would use SCM_RIGHTS to send it to the Go process. The Go process would in turn try to parse the rest of the “Client Hello”, if it were successful it would proceed with TLS 1.3 connection, and upon failure it would give the file descriptor back to OpenSSL, to handle regularly.

這樣本來的 stack 就只要修改一小段程式碼,將當時還很頻繁修改的 TLS 1.3 draft 丟到另外一個 process 跑,就比較不用擔心本來的 stack 會有狀況了。

解 ocserv 因為沒有使用 DTLS 而導致速度很慢的問題...

最近偏好用 ocserv 來跑 VPN。在連上 full-route VPN 後測試發現速度偏慢,發現是沒有走 UDP 的 DTLS,只有 TCP 的 TLS 流量... 找了一下發現用有人遇過了,可以用 workaround 解:「OpenConnect not working with DTLS」。

作者發現是 ocserv.socket 有問題,打算整個抽開。方法是註解掉 /lib/systemd/system/ocserv.service 裡的 Requires=ocserv.socketAlso=ocserv.socket,然後在 systemd 裡一起處理:

sudo systemctl stop ocserv
sudo systemctl disable ocserv.service
sudo systemctl disable ocserv.socket
sudo systemctl daemon-reload
sudo systemctl start ocserv
sudo systemctl enable ocserv

重新連上去後跑 tcpdump 可以看到是 UDP 了,測速也可以看出來快不少...