把 TLS 1.0 關掉...

突然想到所以到 SSL Report 上測試 blog.gslin.org,發現如果還支援 TLS 1.0,在 Overall Rating 的部份會直接被降為 B。

翻了一下 access log (我在 log 裡有多記錄連線的 TLS Protocol),看起來用 TLS 1.0 連的主要都是 bot,關掉應該是還好...

另外看了一下報告裡的 Cipher Suites 部份,發現不少 cipher (像是 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)) 被列為 weak,看起來像是把使用 CBC 的 cipher 都認為是 weak,是個推廣 AEAD 的概念。

影響應該不大,但還是記錄一下... 另外等 Ubuntu 20.04 出了以後把整台重灌好了,目前還在用 Ubuntu 16.04,系統內建的 nginx 不支援 TLS 1.3。

Let's Encrypt 在檢查 CAA 時出包

Let's Encrypt 發現在檢查 CAA 的程式碼有問題,發了說明:「2020.02.29 CAA Rechecking Bug」,以及預定的處理方式:「Revoking certain certificates on March 4」。

問題是當一個 certificate request 包含了 N 個 domain 時,本來的 CAA 檢查應該要對這 N 個檢查,但程式寫成只會抓一個,然後檢查了 N 次:

The bug: when a certificate request contained N domain names that needed CAA rechecking, Boulder would pick one domain name and check it N times. What this means in practice is that if a subscriber validated a domain name at time X, and the CAA records for that domain at time X allowed Let’s Encrypt issuance, that subscriber would be able to issue a certificate containing that domain name until X+30 days, even if someone later installed CAA records on that domain name that prohibit issuance by Let’s Encrypt.

2020/02/29 發現的,就程式碼的部屬時間,發現應該從去年 2019/07/25 開始就有這個 bug:

We confirmed the bug at 2020-02-29 03:08 UTC, and halted issuance at 03:10. We deployed a fix at 05:22 UTC and then re-enabled issuance.

Our preliminary investigation suggests the bug was introduced on 2019-07-25. We will conduct a more detailed investigation and provide a postmortem when it is complete.

然後決定要 revoke 這些可能會有問題的 SSL certificate,大約佔現有還有效的 SSL certificate 的 2.6%,大約三百萬筆:

Q: How many certificates are affected?
A: 2.6%. That is 3,048,289 currently-valid certificates are affected, out of ~116 million overall active Let’s Encrypt certificates. Of the affected certificates, about 1 million are duplicates of other affected certificates, in the sense of covering the same set of domain names.

在「Check whether a host's certificate needs replacement」這邊可以偵測線上使用的 SSL certificate 是否受到影響。

另外在「Download affected certificate serials for 2020.02.29 CAA Rechecking Incident」這邊可以抓到所有受到影響,預定要 revoke 的 SSL certificate 的序號。關於取得序號的方式,官方也有提供 CLI 的指令可以操作確認,對於有很多網域名稱需要確認的人可以用這組指令編寫程式判斷:

openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null 2>/dev/null | openssl x509 -text -noout | grep -A 1 Serial\ Number | tr -d :

照目前的描述,如果申請時只有一個 domain 應該是不會中這個問題,再來是最壞的情況大概會維持三個月 (網站主人沒管他,等到時間到了自動 renew)。

Firefox 在美國將預設開啟 DNS over HTTPS

看到 Mozilla 在「Firefox continues push to bring DNS over HTTPS by default for US users」這邊的公告,另外也可以參考 Hacker News 上的討論:「Mozilla’s DNS over HTTPs (blog.mozilla.org)」。

這次的改變是將美國的 Firefox 使用者自動啟用 DNS over HTTPS (DoH),而預設是丟給 Cloudflare

By default, this change will send your encrypted DNS requests to Cloudflare.

這個作法非常粗暴而且侵犯使用者的隱私。

  • 對於進階而且有在跟重大消息的使用者,他們如果不信任 Cloudflare 的話,會主動關掉 DoH 的選項。
  • 但對於一般使用者,他們不知道這件事情,而他們本來也不會預期他們上網的 hostname 部份會被 Cloudflare 知道。

相較於 Google Chrome 是確認你現在用的 DNS 是不是在有支援 DoH 的清單內,如果是的話就會切過去使用 DoH,但不會因此改變 DNS provider,也就是不會有突然冒出來的第三者知道你瀏覽的網站。

來繼續看...

Safari 將會禁止長效憑證 (超過 398 天,大約十三個月)

在「Apple drops a bomb on long-life HTTPS certificates: Safari to snub new security certs valid for more than 13 months」這邊看到的,這次是 Safari 直接發難要幹掉長效憑證。

今年九月前發的憑證是照既有的協議,最長長度是 825 天 (大約 27 個月),但九月開始發的憑證,如果有效長度超過 398 天就會直接被 Safari 視為無效,所以大約是砍半,其他家瀏覽器不知道會不會跟進...

最早的時候可以直接買五年 (有印像是因為當年的 group.nctu.edu.tw 是我自己買的),後來好像降到三年,最近是兩年,看起來要變成一年了...

Google Chrome 要開始管制非 HTTP 的下載了

Google Chrome 前陣子宣佈了要淘汰透過 HTTP 下載檔案的計畫:「Protecting users from insecure downloads in Google Chrome」。

分成不同檔案類型的下載,可以看到不同類型檔案會在不同時間點被阻擋:

所以到時候 IE 的功能又多了一個?

Google 與 Cloudflare 測試 Post-Quantum 演算法的成果

這幾年量子電腦的進展不斷有突破,雖然到對於攻擊現有的密碼學看起來還有一段時間,但總是得先開始研究對量子電腦有抵抗性的演算法...

其中 Google Chrome 的團隊與 Cloudflare 的團隊手上都有夠大的產品,兩個團隊合作測試的結果在學界與業界都還蠻重視的:「Real-world measurements of structured-lattices and supersingular isogenies in TLS」、「The TLS Post-Quantum Experiment」。

Google Chrome 這邊是使用了 Canary 與 Dev 兩個 channel,有控制組與兩個新的演算法:

Google Chrome installs, on Dev and Canary channels, and on all platforms except iOS, were randomly assigned to one of three groups: control (30%), CECPQ2 (30%), or CECPQ2b (30%). (A random ten percent of installs did not take part in the experiment so the numbers only add up to 90.)

這兩個演算法有優點也有缺點。一個是 key 比較小,但運算起來比較慢 (SIKE,CECPQ2b);另外一個是 key 比較大,但是運算比較快 (HRSS,CECPQ2):

For our experiment, we chose two algorithms: isogeny-based SIKE and lattice-based HRSS. The former has short key sizes (~330 bytes) but has a high computational cost; the latter has larger key sizes (~1100 bytes), but is a few orders of magnitude faster.

We enabled both CECPQ2 (HRSS + X25519) and CECPQ2b (SIKE/p434 + X25519) key-agreement algorithms on all TLS-terminating edge servers.

感覺還是會繼續嘗試,因為這兩個演算法的缺點都還是有點致命...

Caddy Server 要採用 Open Source...

Caddy Server 是一套 HTTP Server,目標是讓使用者可以很容易設定一個安全的 HTTP Server。

程式碼本身是 open source (採用 Apache License 2.0),但官方包出來的 binary 則是限制個人免費使用或是購買訂閱,但如果你自己編譯打包的話又還是 open source license,是一個很奇怪的商業模式...

再加上看到他的設定檔的格式後,發現他包太多東西了 (連 markdown 相關的處理都包進去),實在是不愛這種設計 (感到遲早會有滿滿的 CVE),而 nginx 就是把 HTTP Server 相關的業務處理好,相較起來就懶的理了...

現在看起來 Caddy Server 應該覺得這樣沒賺頭而決定把訂閱拿掉,全部都開放出來:「Proposal: Permanently change all proprietary licensing to open source」。

但比較奇怪的還是,這件事情其實你也不用徵求社群意見,你們自己公司內部確認好就好,這個比較像是 PR 而已...

Chrome 將不會在 HTTPS 頁面上載入 HTTP 資源...

現在 Google Chrome 的穩定版是 77,到了十二月會推出的 79 的時候,就會有一連串的避免 HTTPS 頁面使用 HTTP 資源的措施:「No More Mixed Messages About HTTPS」。

首先是 79 的時候會有新的界面,讓使用者可以修改阻擋類的設定。

到了 80 的時候會試著將 HTTP 的影音 <audio><video> 升級到 HTTPS 連線,如果 HTTPS 讀不到的話就當作讀取失敗。但圖片 <img> 的部份則是會讀進來,只是安全性上會顯示 Not Secure。

到了 81 就是這系列的最終階段,包括 <img> 也會一使用 80 時影音的邏輯,沒辦法在 HTTPS 上讀到就當作讀取失敗。

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

其實網路上有一些教學,但大多數的作法都是把 port 80 空出來跑認證用的 HTTP 伺服器,而我這邊的作法是希望維持 nginx,用 webroot local folder 的方式認證。

pfSense 上先安裝 acme 套件,然後先用 Create new account key 產生出自己的金鑰:

然後選擇申請 Let's Encrypt Production ACME V2 的帳號:

接著填一下 Name 的部份,按下 Register ACME account key 註冊後就可以按下 Save 存進系統。

然後就是拿這個帳號申請網域名稱,重點在於,如果選擇 webroot local folder 時,需要填寫對應的 RootFolder 參數 (這塊做得很怪,沒有預設值 XD):

然後按下 Save 後存起來,回到頁面上就可以按 Issue/Renew 申請了,申請成功以後就可以到最上方 tab 的 System,在裡面的 Advanced 就可以改 HTTPS 管理界面使用的憑證,改好後把瀏覽器關掉重開就可以確認是不是有設定好...

Google Chrome 也要打開 DoH

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):

We are aiming for an experiment in Chrome 78 (branch cut: Sept 5th; estimated Stable: Oct 22nd) followed by a launch if everything goes well.