Mozilla 跟 Google 都宣佈了 TLS 1.0 與 TLS 1.1 的退役計畫

October 15, 2018, 3:10 pm

≪ Previous: 在 Android 上支援 DNS over HTTPS 的 Intra

Update：Apple 也宣佈了，時間點跟大家都差不多：「Deprecation of Legacy TLS 1.0 and 1.1 Versions」。

Mozilla 宣佈了「Removing Old Versions of TLS」，而 Google 也宣佈了「Modernizing Transport Security」，兩篇都是講自家瀏覽器 TLS 1.0 與 TLS 1.1 的退役時程。

Mozilla 這邊的計畫是 2020 年三月移除：

In March of 2020, Firefox will disable support for TLS 1.0 and TLS 1.1.

Google 這邊的計畫則是 Chrome 81 移除，換算成時間會從 2020 年一月開始影響到 canary channel，到 release channel 應該跟 Firefox 差不多時間：

In line with these industry standards, Google Chrome will deprecate TLS 1.0 and TLS 1.1 in Chrome 72. Sites using these versions will begin to see deprecation warnings in the DevTools console in that release. TLS 1.0 and 1.1 will be disabled altogether in Chrome 81. This will affect users on early release channels starting January 2020.

差不多試從現在開始的一年半。

雖然這是講瀏覽器端的支援，但如果伺服器想要只支援 TLS 1.2+ 的話，就得考慮一下舊 client 支援的情況了。

桌機影響會比較小 (升級比較方便，替代方案也比較多)，而行動平台看起來需要 Android 4.4+、iOS 7+，就要看各網站或是服務的族群了...

↧

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

November 4, 2018, 9:43 am

≫ Next: HTTP-over-QUIC 將變成 HTTP/3

≪ Previous: Mozilla 跟 Google 都宣佈了 TLS 1.0 與 TLS 1.1 的退役計畫

我 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 後就好的情況...

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

↧

HTTP-over-QUIC 將變成 HTTP/3

November 12, 2018, 10:27 am

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

≪ Previous: 升級 nginx 後關不掉的 TLSv1.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 了，之後防火牆預設應該要打開...

↧

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

December 1, 2018, 12:10 am

≫ Next: HTTP/3 (QUIC) 的反面看法

≪ Previous: HTTP-over-QUIC 將變成 HTTP/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/3 (QUIC) 的反面看法

December 8, 2018, 9:19 am

≫ Next: 所以要開始開發 CECPQ2 了...

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

這篇整理了 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 再確認有哪些有改善...

↧

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

December 13, 2018, 5:46 pm

≫ Next: 幫你在本機產生 localhost 的 SSL Certificate

≪ Previous: HTTP/3 (QUIC) 的反面看法

CECPQ1 是 Google 在研究對抗量子電腦的演算法，作為測試用的演算法，曾經在 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 有關，找時間來補一下基礎理論... @_@

↧

幫你在本機產生 localhost 的 SSL Certificate

January 9, 2019, 7:49 am

≫ Next: APT 不使用 HTTPS 的說明

≪ Previous: 所以要開始開發 CECPQ2 了...

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

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

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

↧

APT 不使用 HTTPS 的說明

January 22, 2019, 7:05 pm

≫ Next: apt-get 的安全性漏洞

≪ Previous: 幫你在本機產生 localhost 的 SSL Certificate

居然有個獨立的網站在說明：「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 機制上提供。

↧

apt-get 的安全性漏洞

January 25, 2019, 7:06 am

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

≪ Previous: APT 不使用 HTTPS 的說明

前幾天寫的「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)，所以應該還是會繼續爭吵吧...

↧

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

January 30, 2019, 1:01 am

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

≪ Previous: apt-get 的安全性漏洞

這則從 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.

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

↧

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

January 31, 2019, 5:08 am

≫ Next: Cloudflare 發表 Logpush，把 log 傳出來

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

昨天是 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 要不要拔了...

↧

Cloudflare 發表 Logpush，把 log 傳出來

February 26, 2019, 5:43 pm

≫ Next: Cloudflare 試著分析哪些 HTTPS 連線被攔胡過濾

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

Cloudflare 推出了 Logpush，可以把 log 傳到 Amazon S3 或是 Google Cloud Storage 上 (目前就支援這兩個)：「Logpush: the Easy Way to Get Your Logs to Your Cloud Storage」，目前是 enterprise 方案可以用：

Today, we’re excited to announce a new way to get your logs: Logpush, a tool for uploading your logs to your cloud storage provider, such as Amazon S3 or Google Cloud Storage. It’s now available in Early Access for Enterprise domains.

Logpush currently works with Amazon S3 and Google Cloud Storage, two of the most popular cloud storage providers.

以往是自己拉，需要考慮 HA 問題 (兩台小機器就可以了，機器成本是還好，但維護成本頗高)，現在則是可以讓 Cloudflare 主動推上來...

我大多數的建議是 log 儘量留 (包括各種系統的 log 與 http access log)。主要是因為儲存成本一直下降 (S3 的 1TB 才 USD$23/month，如果使用 Glacier 會低到 USD$4/month)，而且 log 在壓縮後會變小很多 (經常會有重複的字)。

最傳統的 AWStats 就可以看到不少資訊，如果是透過 IP address 與 User-agent，交叉配合其他 event data 就可以讓很多 machine learning 演算法取得的資訊更豐富。

↧

Cloudflare 試著分析哪些 HTTPS 連線被攔胡過濾

March 18, 2019, 7:01 pm

≫ Next: PHP 終止 mirror 站台計畫

≪ Previous: Cloudflare 發表 Logpush，把 log 傳出來

這邊講的應該是在 client 端裝了 root certificate 後，網路上的 middle box 就有能力解開 HTTPS 連線看內容，再 proxy 連出去的方式：「Monsters in the Middleboxes: Introducing Two New Tools for Detecting HTTPS Interception」，對於有設定 Pinning 的 HTTPS 應該會因為偵測到 certificate 被換掉而不會被監聽，但大多數的應用程式應該沒做這個保護。

對應的公開網站是 MALCOLM，為「Measuring Active Listeners, Connection Observers, and Legitimate Monitors」的縮寫。

Cloudflare 用了幾個方法去分析，像是 User-agent 與 OS 跟支援的 cipher 對不起來的情況就可以猜測是 middle box 的監聽。另外也可以看到 Cloudflare 分析了 middle box 的廠牌，可以看到 Blue Coat 應該是目前的大品牌 (但這邊有統計偏差，限制在可以被偵測出來的品牌)。

其實整體看起來不算低耶... 光是可以確認的部分，整個 Cloudflare 網路上有 10%～20% 的流量其實是有被過濾的？

↧

PHP 終止 mirror 站台計畫

April 1, 2019, 3:20 pm

≫ Next: 靜態網頁服務的選擇

≪ Previous: Cloudflare 試著分析哪些 HTTPS 連線被攔胡過濾

Twitter 上看到的公告：

Effective today, the PHP project has ended its volunteer mirror program. All users of PHP will now be accessing https://t.co/S2GoDChwgr sites directly from project servers and via CDN.https://t.co/POypIycsti #NotAnAprilFools

— php.net (@official_php) April 1, 2019

本來 PHP 開放讓各地區的自願者提供頻寬，使用 PHP 的網域名稱 (像是 tw.php.net 這樣)，現在則是全部都收回，由官方統一提供有 HTTPS 的網頁版本 https://www.php.net/。

目前看起來 latency 頗高，都是到美東的伺服器上？下載也都還是指在 https://www.php.net/ 上，不知道 CDN 是用在哪裡...

↧

靜態網頁服務的選擇

May 22, 2019, 1:52 pm

≫ Next: OpenBSD 關掉 Firefox 預設的 DoH (DNS over HTTPS)

≪ Previous: PHP 終止 mirror 站台計畫

在 Hacker News 上看到「Show HN: Scar – Static websites with HTTPS, a global CDN, and custom domains (github.com)」這篇，除了文章連結外，留言提到了不少工具...

一種是透過 GitHub Pages 的方式提供服務，或是透過 Netlify，需求真的需要動到 AWS 元件的情況其實還是考慮用傳統一點的架構 (EC2 或是 VPS) 會更有彈性。

算是提出一個雞肋後，其他人把真正有用的工具整理了出來...

↧

OpenBSD 關掉 Firefox 預設的 DoH (DNS over HTTPS)

September 12, 2019, 7:56 am

≫ Next: Google Chrome 也要打開 DoH

≪ Previous: 靜態網頁服務的選擇

OpenBSD 決定關閉 Firefox 預設的 DoH (DNS over HTTPS)：「DoH disabled by default in Firefox」。

原因是 OpenBSD 的人認為，DoH 本身 ok，但是預設導去 Cloudflare 不 ok：

Disable DoH by default. While encrypting DNS might be a good thing, sending all DNS traffic to Cloudflare by default is not a good idea. Applications should respect OS configured settings. The DoH settings still can be overriden if needed. ok landry@ job@

我覺得這槍開的很好 XD

↧

Google Chrome 也要打開 DoH

September 14, 2019, 1:28 am

≫ Next: 讓 pfSense 的管理界面接上 Let's Encrypt

≪ Previous: OpenBSD 關掉 Firefox 預設的 DoH (DNS over HTTPS)

Google Chrome 也要支援 DNS over HTTPS (DoH) 了，不過 Google 的作法比 Firefox 軟 (大概這種東西都有經過反壟斷法的評估？)，會先判斷系統的 DNS 是否在支援 DoH 的清單內，在不改變 DNS 服務商的情況下，從本來的 UDP 查詢變成 DoH 查詢：「Experimenting with same-provider DNS-over-HTTPS upgrade」。

清單可以從「DNS over HTTPS (aka DoH)」這邊看到，除了 Google 自己外，也有 Cloudflare 與其他支援 DoH 的 DNS 服務商。

這個功能會從 Chrome 78 生效 (現在 stable 與 beta 都還是 77)：