T-Mobile US 打算要賣使用者的瀏覽記錄了

全美第二大的 T-Mobile US 打算要賣使用者的瀏覽記錄了,除非你登入進去選擇退出:「T-Mobile to Step Up Ad Targeting of Cellphone Customers」,Hacker News 上的討論則可以看「T-Mobile to share customers' data with advertisers unless they opt out (thehill.com)」這邊。

The No. 2 U.S. carrier by subscribers said in a recent privacy-policy update that unless they opt out it will share customers’ web and mobile-app data with advertisers starting April 26.

這次的改變包括了 2020 年併購 Sprint 的使用者:

T-Mobile’s new policy will also cover Sprint customers acquired through the carriers’ 2020 merger. Sprint had previously shared similar data only from customers who opted into its third-party ad program.

所以連在美國都有 DNS over HTTPS (或是 DNS over TLS) 與 ESNI 需求了...

架設 Proxy over TLS

HTTP Proxy 算是很好用的跳板手段,瀏覽器有很多套件可以依照各種條件自動切換到不同的 Proxy 上面。

但一般在使用 HTTP Proxy (走 Port 3128 或是 8080 的那種) 使用明文傳輸,就不適合使用 Proxy-Authenticate 把帳號密碼帶進去 (出自 RFC 7235 的「Hypertext Transfer Protocol (HTTP/1.1): Authentication」),查了一些資料後發現,現在的瀏覽器基本上都支援 Proxy over TLS 了,也就是 Proxy Protocol 外面包一層 TLS,保護瀏覽器到 Proxy 中間的流量。

順便說一下,這邊講的 HTTPS Proxy 跟環境變數裡的 HTTPS_PROXYhttps_proxy 不太一樣,這兩個環境變數是說「HTTPS 協定要走哪個 Proxy 設定」。

HTTPS Proxy 主要有幾份文件可以參考,第一份可以是 Squid 的「Feature: HTTPS (HTTP Secure or HTTP over TLS)」,裡面提到了伺服器上的設定 https_port,以及瀏覽器的支援度。

第二份是認證的部份,也是 Squid 的文章「Proxy Authentication」這篇,走 ncsa 認證基本上就可以吃熟悉的 .htpasswd 格式了。

接下來就是安裝與設定了,在 Ubuntu 20.04 可以直接用 apt 裝 squid4,因為有包括了 --enable-gnutls;而在 Ubuntu 18.04 就不能這樣做了,因為 Ubuntu 裡面是 squid3,而且沒有加上 --enable-openssl 或是 --enable-gnutls,會比較麻煩...

其他基本上就是塞設定進去就可以了... 然後 Google Chrome 這邊可以裝「Proxy SwitchyOmega」這種套件,他可以設定 HTTPS Proxy 的 Profile,然後依照網域名稱來設定要用哪個 Profile。

這樣做的好處就是不需要連 VPN 改變 routing table (通常需要登入),就有類似 VPN 的效果,而且可以很細緻的調整流量要怎麼繞。

而且機器上也不需要 shell account 讓人跑 ssh -D1080 之類的指令開 Socks Proxy,要給朋友共用也比較簡單。

先架了台灣跟美國的,找機會再多架一些伺服器起來用...

Dehydrated 取得憑證的預設演算法改成 secp384r1

這兩天弄 dehydrated,結果發現 v0.7.0 取得憑證的預設演算法改成 ECCsecp384r1 了:

Using EC secp384r1 as default certificate type

這會導致很多「稍微舊一點」的 client 失效 (瀏覽器與 library),不知道為什麼要預設... 目前避開的方法是強制在 /etc/dehydrated/config 內設定使用 rsa

KEY_ALGO=rsa

剛剛把公司一堆機器改上去,然後把自己的 server 也加一加...

RFC 定義的 application/problem+json (或是 xml)

剛剛在 Clubhouse 上聽到保哥提到了 RFC 7807 這個東西 (Problem Details for HTTP APIs),剛剛翻瀏覽器累積的 tab,發現原來先前有看到,而且有打算要出新版的消息:

RFC 7807 裡面這樣定義的方式可以讓 client 端直接判斷 Content-Type 知道這個回傳資料是不是錯誤訊息,不然以前都是 JSON 就得再另外包裝。用 Content-Type 的作法可以讓判斷條件變得清晰不少。

除了 application/problem+jsonapplication/problem+xml 以外,在「3.1. Members of a Problem Details Object」裡面則是說明 JSON (或是 XML) 裡面有哪些必要以及可選的資訊要填,然後「3.2. Extension Members」這邊則大概描述一下怎麼擴充。

先有個印象,之後新規劃的東西可以考慮進去...

Firefox 也打算淘汰 ESNI,改推 ECH

Firefox 也打算放棄 ESNI,改推 ECH 了:「Encrypted Client Hello: the future of ESNI in Firefox」。

目前的 85 版 (目前的 beta) 支援了 ECH draft-08,想要玩看看的人就可以測試了:

Firefox 85 replaces ESNI with ECH draft-08, and another update to draft-09 (which is targeted for wider interoperability testing and deployment) is forthcoming.

另外一個要看的當然就是 Google 家的 Chromium 了,不過這個協定對 Google 的誘因應該是超大,有機會直接穿入中國市場... 只是不知道會不會自己搞一套 protocol。

IdenTrust 願意再幫 Let's Encrypt 交叉簽三年

先前在「Let's Encrypt 在 Android 平台上遇到的問題」這邊提到了 IdenTrustLet's Encrypt 交叉簽名的有效日會在 2021 年的八月底左右到期,而這會導致比較舊的 Android 平台因為沒有內建 ISRG Root X1 這個憑證,造成 Let's Encrypt 簽出來的憑證在這些舊的 Android 裝置上都認不出來。

文章出來過了一個多月後,剛剛看到 Let's Encrypt 發佈消息,IdenTrust 願意再交叉簽名三年:「Extending Android Device Compatibility for Let's Encrypt Certificates」,當時猜測發文是要讓 IdenTrust 表態,看起來目的達成了...

話說中間跑出來的「ZeroSSL 也提供免費的 SSL Certificate (DV) 了」不知道後續會怎麼樣,之後可以看看 Certificate Transparency 的資料來看看到底有多少人用...

Cloudflare 改推 ECH 加密整個 TLS 的 ClientHello

Cloudflare 本來在推的 ESNI 現在變成 ECH 了:「Good-bye ESNI, hello ECH!」。

上面這張圖是 ESNI,下面這張是 ECH:

可以看出來 ECH 最主要的差異是把本來的 ClientHello 都加密包起來了,伺服器會先試著解內層的 ClientHelloInner,失敗的時候會用外層的 ClientHelloOuter:

The server completes the handshake with just one of these ClientHellos: if decryption succeeds, then it proceeds with the ClientHelloInner; otherwise, it proceeds with the ClientHelloOuter.

看得出來 ECH 的其中一個目標是讓他看起來跟一般的 TLS 連線一樣,這樣就能順便解掉 censorship 的問題...

其中一個原因應該也是因為之前中國與俄國的直接封掉 ESNI:

In August 2020, the Great Firewall of China started blocking ESNI traffic, while still allowing ECH traffic.

In October 2020, Russian ISPs such as Rostelecom and its mobile operator Tele2 started blocking ESNI traffic.

不過仍然還有分析 HTTPS pattern 的方式可以抓 (就是文章裡提的 traffic analysis),目前看起來只處理了 ClientHello 本身,現在還是有機會分析 handshake 過程來擋,必須繼續改善 ECH 的協定,讓整個流程看起來都跟一般的 TLS 一樣...

可以等著看,到時候在中國的效果如何了,會不會讓國外的各大服務直接打進去呢...

Cloudflare 與 ISP 合作推出 ODoH 加強隱私,然後 Google 想要看 HTTPS 流量

Cloudflare 推出了 ODoH (目前是 IETF 的 draft:「Oblivious DNS Over HTTPS」):「Improving DNS Privacy with Oblivious DoH in 1.1.1.1」,在 Hacker News 上面也有討論:「 Improving DNS Privacy with Oblivious DoH (cloudflare.com)

基本上就是 DNS over HTTPS 在上面架一層 Proxy,但這層 Proxy 不能是 Cloudflare 自己:

這樣一來 Cloudflare 知道 IP address 的機會就會比較小,藉以達到要求,先前要達到這樣的效果必須透過 ISP 提供的 HTTP/HTTPS Proxy (像是已經淘汰的 proxy.hinet.net:「HiNet 宣佈年底關閉 Proxy 服務」),或是透過 Tor,但 Tor 的效能會讓 query 速度慢不少。這次的這個服務的確是好不少...

技術上來說,當 Cloudflare 與 ISP 都把所有的 packet 記錄下來後,兩邊合作還是可以取得原始的 IP 資訊,以這個例子來說,你跟總部在香港的 PCCW 集團合作,看起來就不怎麼吸引人啊...

不過隔壁棚的 Google 則是讓人吐血中,打算用 Prefetch 名義看到你的 HTTPS 流量:「Continuing our journey to bring instant experiences to the whole web」,這樣一來,就有不少的機會 Google 可以分析出來使用者在看什麼 Netflix 影片了 (要看 Prefetch 到什麼程度,2017 年的時候做出來有 99.99% 的準確度):「利用 Side-channel 資訊判斷被 HTTPS 保護的 Netflix 影片資訊」。

來坐著等看 Google 這邊的好戲...

Load Impact 的 k6 網站壓測軟體

這幾天在 Hacker News 上看到 Load Impact 推出的 k6 壓測程式,結合了 Golang 的執行效率與 JavaScript 的操作語法,讓使用者可以很簡單的進行壓力測試,在 Hacker News 上也有蠻正向的反應:「K6: Like unit testing, for performance (github.com/loadimpact)」,我唯一會在意的應該是 AGPLv3 的部份...

先看了一下資訊,看起來「Load Impact」是公司名稱,「LoadImpact」則是產品名稱,然後現在要改名變成「k6」與「k6 Cloud」:

Load Impact is now k6

Due to the success and rapid growth of the k6 open source load testing tool we decided to rebrand the LoadImpact product as k6 Cloud!

k6 裡面設計了 VU (Virtual User) 的概念,如同字面上的意義,VU 是虛擬的使用者,就技術上來說,每個 VU 都是在獨立的 JavaScript runtime 裡跑:

Each virtual user (VU) executes your script in a completely separate JavaScript runtime, parallel to all of the other running VUs.

然後他們居然把 JavaScript 裡面最「經典」的 async 架構給拔了,所以就不需要一堆 callback & promise 架構,用起來就爽很多:

For simplicity, unlike many other JavaScript runtimes, a lot of the operations in k6 are synchronous. That means that, for example, the let response = http.get("https://test-api.k6.io/") call from the Running k6 example script will block the VU execution until the HTTP request is completed, save the response information in the response variable and only then continue executing the rest of the script - no callbacks and promises needed.

翻了一下 Hacker News 上的討論與程式碼,看起來 JavaScript runtime 這部份是用 Golang 寫的 goja

文件裡面給了不少範例,像是在「Running k6」這邊有直接給出怎麼壓測,10 個 VU 跑 30 秒:

k6 run --vus 10 --duration 30s script.js

另外在 repository 裡面,「samples」這個目錄下有不少範例,可以直接先看過一次從裡面學到不少功能,之後再回去翻一次 manual,應該就會更熟悉...

隨便測了一下還蠻容易上手的,加上有 apt repository 可以直接納入系統管理,看起來應該會放著跑,之後找機會用看看,也許打 API 之類的...

關閉 GitLab 的 nginx,使用自己裝的 nginx

我自己架設的 GitLab 是透過「Install self-managed GitLab」這邊的方法裝進 Ubuntu 系統內的 (我在自己的 wiki 上也有整理:「GitLab」),他會自己下載所有對應的套件,包括了 nginx

但這樣就直接把 TCP port 80/443 都吃掉了,同一台機器要放其他的 virtual host 就比較麻煩,所以找了些方法讓 GitLab 不要佔用 TCP port 80/443。

首先是找到這篇,資料有點舊,但裡面關掉 nginx 的方法還算是有用:「How to setup gitlab without embedded nginx」。

現在只要把 /etc/gitlab/gitlab.rb 裡面的:

  • nginx['enable'] 改成 false
  • web_server['external_users'] 改成 ['www-data']

然後跑 gitlab-ctl reconfigure 讓他更新設定檔,接下來停掉整個 GitLab 再打開 (或是重開機) 讓 nginx 完全失效就可以了。

接下來弄好自己的 nginx 以及 HTTPS 設定,這個部份我自己偏好用 dehydrated,其他人會有不同的偏好設法。

在弄完 nginx 後再來是 proxy_pass 類的資訊要帶進去,這個部份可以參考本來 GitLab 的 nginx 設定檔 (在 /var/opt/gitlab/nginx/conf/ 這下面),其中最重要的就是 GitLab 本身,我們會在 /etc/nginx/conf.d/upstream.conf 裡面寫入對應的 upstream 資訊 (沒這個檔案就自己生一個):

upstream gitlab-workhorse {
    server unix:/var/opt/gitlab/gitlab-workhorse/sockets/socket;
}

接下來是在對應的 virtual host 下設定 proxy_pass

    location / {
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_pass http://gitlab-workhorse;
    }

另外我有啟用 GitLab 提供的 Mattermost,所以也要翻設定導進去:

#
upstream gitlab_mattermost {
    server 127.0.0.1:8065;
}

與:

    location / {
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_pass http://gitlab_mattermost;
    }

都弄好後叫 nginx 重讀設定,接下來應該就會動了... 然後 TCP port 80/443 也算自由了,要掛其他的網域上去應該都 OK。