Google 也透過同樣機制蒐集使用者的行為

Update:Google 的憑證也被 revoke 了,另外 Facebook 的恢復內部使用的部分了:「Apple blocks Google from running its internal iOS apps」。

昨天是 Facebook 被發現在 iOS 上使用 Enterprise Certificate 取得使用者的行為記錄 (參考「Facebook 花錢向使用者購買他們的行為記錄」),後來 Apple 撤銷了這張 Enterprise Certificate (因為不符合 Enterprise Certificate 的使用條款),並且使得 Facebook 內部符合 Enterprise Certificate 的應用程式都失效。

Google 也被抓出幹同樣的事情,叫做 Screenwise Meter:「Google will stop peddling a data collector through Apple’s back door」。

目前 Google 自己已經下架,但這表示已經有的 spyware 還是會生效,就看 Apple 要不要拔了...

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.

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

apt-get 的安全性漏洞

前幾天寫的「APT 不使用 HTTPS 的說明」的當下就已經有看到在講這個漏洞,但沒讀完就一直放著沒寫:「Remote Code Execution in apt/apt-get」。

漏洞出在實作上的問題,對於 HTTP 重導的程式碼沒有處理好外部字串,在還沒修正的機器上用這個指令關閉 redirect,避免在修正的過程反而被 RCE 打進去:

sudo apt update -o Acquire::http::AllowRedirect=false
sudo apt upgrade -o Acquire::http::AllowRedirect=false

但也不是 HTTPS 就能避免這個問題,因為 HTTPS 連線用的程式碼又是另外一份,裡面不知道有沒有問題 (像是之前經典的 Heartbleed),所以應該還是會繼續爭吵吧...

APT 不使用 HTTPS 的說明

居然有個獨立的網站在說明:「Why does APT not use HTTPS?」。主要是 HTTPS 沒有增加太多保護,但會使得維護的複雜度變高很多。

首先是被竄改的問題,APT 本身就有簽名機制 (參考「SecureApt」),即使 mirror site 被打下來也無法成功竄改內容,反而比起單純的 HTTPS 保護還好。

而對於隱私問題,由於內容是可以公開取得的,這代表可以看封包的大小與流動順序猜測是哪些 package 被下載 (也就是類似「利用 Side-channel 資訊判斷被 HTTPS 保護的 Netflix 影片資訊」這篇提到的方法),加上 APT 這邊還多了時間性的資訊 最近被更新的軟體被下載的機率比較高),所以隱私的保護上其實有限。

而針對攻擊者刻意提供舊版的問題 (某種形式的 replay attack),APT 降低風險的解法是把時間簽進去,當用戶端發現太久沒更新時,就當作過期失效而提出警告。

就以上來看,把所有的 APT 伺服器都加上 HTTPS 的工程太浩大,而得到的效益太小。所以願意提供 HTTPS 的站台就提供,但主要的保護還是從本來的 SecureApt 機制上提供。

幫你在本機產生 localhost 的 SSL Certificate

mkcert 這個工具可以產生出讓系統 (包括瀏覽器) 信任的 https://localhost/:「mkcert: valid HTTPS certificates for localhost」。

先建立 CA 的 root key 與 root certificate,然後把 root certificate 塞到系統與各軟體的信任清單內,再產生 localhost 的 key 與 certificate 出來給前面的 CA root key 簽名。把這些事情包裝起來就是 mkcert 了。

拿來開發軟體時比較方便一點,HSTS 的程式碼就可以全環境共用了...

所以要開始開發 CECPQ2 了...

CECPQ1Google 在研究對抗量子電腦的演算法,作為測試用的演算法,曾經在 Google Chrome 的 54 beta 版 (2016 年) 存活過一段時間,最近又開始在開發新一代的演算法 CECPQ2 了,這次會是基於 TLS 1.3 上測試:「CECPQ2」。

CECPQ2 will be moving slowly: It depends on TLS 1.3 and, as mentioned, 1.3 is taking a while. The larger messages may take some time to deploy if we hit middlebox- or server-compatibility issues. Also the messages are currently too large to include in QUIC. But working though these problems now is a lot of the reason for doing CECPQ2—to ensure that post-quantum TLS remains feasible.

目前對抗量子電腦的演算法好像都跟 Lattice 有關,找時間來補一下基礎理論... @_@

HTTP/3 (QUIC) 的反面看法

這篇整理了 HTTP/3 (QUIC) 的反面看法,算是常見的疑慮都列出來了:「QUIC and HTTP/3 : Too big to fail?!」。

其實大多都是使用 UDP 而導致的問題:

  • 因為 UDP 導致 firewall 可能沒開,以及可能會需要等 timeout 走回 TCP 的問題。
  • 因為 UDP 變成很多事情在 userland 處理,而導致的 CPU 使用率比使用 TCP 的 TLS 1.2/1.3 高很多。
  • 因為 UDP 導致 amplification attack 的安全性問題,以及對應的 workaround 產生的頻寬議題。
  • 由於 UDP 會需要自己控制擁塞,等於是在 UDP 上面又重做了一次 TCP congestion algorithm,而且因為重作所以得考慮與 TCP 搶資源的公平性。

整篇文章算是整理了一般對 HTTP/3 的疑慮,之後如果有進展的話,可以再拿出來當 checklist 再確認有哪些有改善...

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 會有狀況了。

HTTP-over-QUIC 將變成 HTTP/3

cURL 作者那邊看到的,之前 HTTP-over-QUIC 的名稱實在太長,想要找個短一點的名字來用,這邊算是把命字確定下來了:「HTTP/3」。從文章後的說明就可以看出來:

No more confusion. HTTP/3 is the coming new HTTP version that uses QUIC for transport!

不過這代表 HTTP/3 需要 443/udp 了,之後防火牆預設應該要打開...

升級 nginx 後關不掉的 TLSv1.3...

我 blog 的 nginx 是用 ondrej 的版本,最近他把套件加上 TLSv1.3 的支援 (主要是 OpenSSL 1.1.1 出了),但不知道是哪個環節出問題了,現在 TLSv1.3 關不掉 XDDD

而且包起來的 OpenSSL 很奇怪,不管什麼情況都會把 TLSv1.3 的三個 cipher 放進來:

gslin@colo-vultr-1 [~] [17:38] openssl ciphers -v 'xxx'     
TLS_AES_256_GCM_SHA384  TLSv1.3 Kx=any      Au=any  Enc=AESGCM(256) Mac=AEAD
TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any      Au=any  Enc=CHACHA20/POLY1305(256) Mac=AEAD
TLS_AES_128_GCM_SHA256  TLSv1.3 Kx=any      Au=any  Enc=AESGCM(128) Mac=AEAD

然後 nginx 只設 TLSv1.2 的情況下,用 SSL Labs 的網站掃還是會有 TLSv1.3:

ssl_protocols TLSv1.2;

然後還有遇到改了 cipher 後,跑 pkill -1 nginx 之後 client 端會回報沒有任何 cipher 可以用,直到跑了 service nginx restart 後就好的情況...

建議想用的人再等一下...