WireGuard 1.0.0 的釋出

在「[ANNOUNCE] WireGuard 1.0.0 for Linux 5.6 Released」這邊看到的消息,看起來 WireGuard 1.0.0 會回過投來 backport 到幾個重要的版本:

We'll also continue to maintain our wireguard-linux-compat [2] backports repo for older kernels. On the backports front, WireGuard was backported to Ubuntu 20.04 (via wireguard-linux-compat) [4] and Debian Buster (via a real backport to 5.5.y) [5]. I'm also maintaining real backports, not via the compat layer, to 5.4.y [6] and 5.5.y [7], and we'll see where those wind up; 5.4.y is an LTS release.

包括 DebianUbuntu 的新版,以及 5.4.x 的 LTS 版本,讓使用起來更方便一些...

Chrome 與 Chrome OS 最近不會更新新功能

這邊看到的消息,ChromeChrome OS 會避免在最近推出新功能,以維持軟體的穩定性,最近更新的主力會放在安全性上:「Google halts upcoming releases of Chrome and Chrome OS to keep things stable for everyone working from home」。

報導引用自 Twitter 上的宣佈:

呃,突然想到 Windows 的更新情況...

Brave 出手檢舉 Google 沒有遵守 GDPR

Brave (從 Chromium 分支出來的瀏覽器) 檢舉 Google 沒有遵守 GDPR 的規定:「Formal GDPR complaint against Google’s internal data free-for-all」。

主要是「purpose limitation」這個部份,出自「REGULATION (EU) 2016/679 OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL of 27 April 2016」:

1. Personal data shall be:

(b)

collected for specified, explicit and legitimate purposes and not further processed in a manner that is incompatible with those purposes; further processing for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes shall, in accordance with Article 89(1), not be considered to be incompatible with the initial purposes (‘purpose limitation’);

比較重要的是 specified 與 explicit 這兩個詞,GDPR 規定必須明確指明用途,而可以從整理出來的文件「Inside the black box」裡的「Purported processing purpose」看到大量的極為廣泛的說明。

Google 應該會就這塊反擊認為這樣的描述就夠用,就看歐盟決定要怎麼做了...

把 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 是我自己買的),後來好像降到三年,最近是兩年,看起來要變成一年了...

Let's Encrypt 的 ACME v1/v2 透過多個節點認證

從 2020/02/19 開始,Let's Encrypt 的 ACME v1/v2 都會透過多個節點認證:「ACME v1/v2: Validating challenges from multiple network vantage points」。

從多個節點認證可以降低路由被劫持後被拿來產生 SSL Certificate 的風險,看起來會有三個機房參與,需要兩個確認:

After Feb 19th we will make four total validation requests (1 from a primary datacentre, and 3 from remote datacentres). The primary request and at least 2 of the 3 remote requests must receive the correct challenge response value for the domain to be considered authorized.

也如同標題寫的,包括了現有的 v2 與將要淘汰的 v1。

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

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

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

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