Tag: security

Canonical 與 Docker 合作，推出了一系列 LTS Docker Image

Canonical 與 Docker 合作，推出了一系列 LTS Docker Image：「Canonical publishes LTS Docker Image Portfolio on Docker Hub」。

這邊的 LTS 是十年：

Ten year maintenance commitment on app images provides secure cloud software supply chain

另外有提到這些 LTS Docker Image 將不受 per-user rate limit 限制：

Canonical and Docker will collaborate on Docker Official Images and LTS Docker Image Portfolio to bring the best of the two to the community and ecosystem. The entire LTS Docker Image Portfolio will be exempted from per-user rate limits.

發佈的 image 可以在 https://hub.docker.com/u/ubuntu 上面翻到，主要就是常見的 server 軟體，算是多一個選擇...

AWS 推出了 AWS Network Firewall

AWS 推出了 AWS Network Firewall，可以在 VPC 層做更多細緻的設定了：「AWS Network Firewall – New Managed Firewall Service in VPC」。

本來的 Network ACLs 的設計也是對 VPC 做過濾，但就是很標準的 stateless filtering：

Network ACLs are stateless, which means that responses to allowed inbound traffic are subject to the rules for outbound traffic (and vice versa).

而這次推出的 AWS Network Firewall 引入了 stateful filtering 的能力：

另外介紹裡面也提到支援 Suricata 的語法，不過太久沒碰 IDS 這塊了，我只知道 Snort：

A stateful rule group with Suricata compatible IPS rules has all settings defined within the Suricata compatible specification. For example, as following is to detect SSH protocol anomalies. For information about Suricata, see the Suricata website.

目前支援的區域很少，只有 us-east-1、us-west-2 與 eu-west-1 可以用：

AWS Network Firewall is now available in US East (N. Virginia), US West (Oregon), and Europe (Ireland) Regions. Take a look at the product page, price, and the documentation to learn more.

另外價錢上不算便宜：「AWS Network Firewall Pricing」，比較特別的是用 AWS Network Firewall 的話，包含了免費的 NAT Gateway 額度可以用...

印象中 Network ACLs 不用另外付費 (找了一下沒找到收費的標準？)，如果可以用 Network ACLs 解決就用 Network ACLs，不能的再考慮用 AWS Network Firewall 吧...

Dehydrated 使用 ZeroSSL 的方式

上一篇「ZeroSSL 也提供免費的 SSL Certificate (DV) 了」提到 ZeroSSL 的服務，而各家 acme client 也都陸陸續續支援了。

Dehydrated 是在 2020/09/15 的時候實做：「EAB + ZeroSSL support」，我就抓了個新版，更新之前自己包的 PPA dehydrated-lite...

Dehydrated 的設定方式還蠻簡單的，在 /etc/dehydrated/config 裡面這樣寫：

CA=zerossl
EAB_HMAC_KEY=x
EAB_KID=y

其中兩個 EAB 的資訊可以在 ZeroSSL 網站上面取得，然後其他就照舊跑...

ZeroSSL 也提供免費的 SSL Certificate (DV) 了

在 Facebook 上被朋友敲可以測 ZeroSSL，另外一個透過 ACME 協定提供免費的 SSL Certificate，不過目前只有支援單一網域名稱 (DV)：「Another free CA as an alternative to Let's Encrypt (scotthelme.co.uk)」。

我先前就有在測 ZeroSSL，不過驗證一直過不去，當時有在 Twitter 上找 ZeroSSL 帳號問，但 ZeroSSL 的人說 ACME 的部份不在客服範圍，就先丟著...

剛剛發現是自己耍笨了，原因是 nginx 沒設好造成驗證卡住，一改好後就正常了。

用 SSL Labs 的 SSL Server Test 翻了一下，他的 Root CA 看起來歷史更久，應該是有機會解決 Let's Encrypt 明年會產生的 Root CA 憑證信任問題，也就是先前在「Let's Encrypt 在 Android 平台上遇到的問題」提到的問題，在 Hacker News 上的討論也可以看到有人提到這點：

Good to know, and I'm glad there's an alternative to Let's Encrypt, just in case. Is ZeroSSL trusted by old Android devices? If so, that might be a work-around for Let's Encrypt's cross-signing from IdenTrust expiring.

不過也有些人有疑慮，畢竟提供這個服務後面的公司幹過不少壞事：

If zerossl is reselling/a subsidiary of sectigo, that’s enough reason to never use this.
Sectigo is the new name for Comodo. The same bunch of pricks who tried to trademark “Let’s Encrypt”.

Other players in the acme cert “business” is great. Renaming a slime ball name and carrying on like nothing happened is not ok.

但看起來至少是多了一個選擇...

Firefox 83 推出 HTTPS-Only Mode

Mozilla 在 Firefox 83 推出了 HTTPS-Only Mode：「Firefox 83 introduces HTTPS-Only Mode」。

就如同名稱的說明，這個模式只會允許 HTTPS 的連線，主要的設計方式是把「開 HTTP 連線」當作一種特殊權限，就像 notification 之類的權限一樣：

When you enable HTTPS-Only Mode:

  • Firefox attempts to establish fully secure connections to every website, and
  • Firefox asks for your permission before connecting to a website that doesn’t support secure connections.

使用者會先在設定裡面開啟這個全域設定：

開了以後如果想要連 HTTP 網站，就會遇到阻擋：

這個功能真的不賴，馬上想到 Tor Browser 與 Tails 應該都會改用這個，畢竟 Tor 的 HTTP 出口常常被搞...

我自己類似的保護措施是把 HTTP 頁面執行 JavaScript 的能力全部關掉，像是這樣 (這邊是 Brave 瀏覽器，是個基於 Chromium 的 fork)：

然後對於需要 JavaScript 的 HTTP 頁面，我是透過「Simple JavaScript Toggle」暫時授權。

這樣至少在無法確認 integrity 的情況下不會執行 js，減少可被攻擊的面積...

Firefox 試著透過預載 Intermediate CA 降低連線錯誤發生的機率？

在「Preloading Intermediate CA Certificates into Firefox」這邊看到 Mozilla 的人打算在 Firefox 上預載所有的 Intermediate CA，以降低 HTTPS 連線發生錯誤的作法。這點在 Mozilla 的 Wiki 上也有記錄：「Security/CryptoEngineering/Intermediate Preloading」。

的確如文章裡說的，沒有正確放入 Intermediate CA 是個 server 設定上很常見的錯誤。像是前幾天看到「【茶包射手日記】網站憑證無效案例分析」這篇講的摩斯 https://www.mos.com.tw/ 其實就是這個案例，用 SSL Labs 的工具就可以掃出來問題：「SSL Report: www.mos.com.tw (210.59.225.242)」。

問題出在於沒有送出正確的 Intermediate CA(s)，所以在 Android 上找不到一條完整的 trust chain：

不過在 Windows 系統內的 CA store 是可以建立出一條完整的 trust chain，所以 Windows 上的 Microsoft Edge 與 Google Chrome 是不會有問題的 (這兩個都吃系統的 CA store)：

而 Linux 上的 Google Chrome 就會出問題 (這邊會吃 Google 自家的 CA store 資料，就是 Android 那包)。

交叉比對中華電信自家的網站，像是「SSL Report: www.cht.com.tw (2001:b000:1a4:d000:203:75:129:111)」這組，可以看到同樣都叫做「Chunghwa Telecom Co., Ltd. / Public Certification Authority - G2」的 Intermediate CA，但有兩種不同的 SHA256，可以翻到是：「609930eb807ad420afda2a8aa61b67483039168cd766e09942a48bfe7f3bdc10」與「f5fb67c8453eda34dbec8a766574f07a03548c084af2f5e6455ea769608d9ad5」，點入裡面的「Trust」tab 中可以看到中華自己的 CA 與 ePKI 的 CA 都有交叉簽，但卻不是每一個 CA 都有被所有瀏覽器認可，所以在設定的時候就得注意...

話說回來，現在因為 CA/B Forum 的標準有強制要送 CT (Certificate Transparency)，的確是有辦法抓出所有的 Intermediate CA 沒錯，但瀏覽器幫使用者預載感覺好像怪怪的？

In essence, Firefox pre-downloads all trusted Web Public Key Infrastructure (PKI) intermediate CA certificates into Firefox via Mozilla’s Remote Settings infrastructure. This way, Firefox users avoid seeing an error page for one of the most common server configuration problems: not specifying proper intermediate CA certificates.

目前大約有 2000 筆資料：

Given this information, we periodically synthesize a list of these intermediate CA certificates and place them into Remote Settings. Currently the list contains over two thousand entries.

這個比較像是 client 端的 hack？

Ubuntu 16.04 (xenial) 的 ESM 準備中...

Ubuntu 的 ESM (Extended Security Maintenance) 是指 LTS (Long Term Support) 版本在五年的維護期過了以後，可以付費取得安全性更新的方案。

剛剛看到 Ubuntu 官方的文章，說明 Ubuntu 16.04 的 ESM 差不多要開始了：「Less than 6 months to Ubuntu 16.04 ESM: 6 things to prepare」。

ESM 在早期是延長三年，但最近則是改成五年。第一次提供 ESM 的 12.04 到後續的 14.04 與 16.04 都是三年，而 18.04 與 20.04 則是五年。

剛剛翻資料的時候發現原來 ESM 有提供個人免費使用 (在 Ubuntu Advantage 的 Essential 方案內)，一般是三台，如果是社群成員的話有機會到五十台：

Free for personal use
Canonical provides Ubuntu Advantage Essential subscriptions, which include ESM, free of charge for individuals on up to 3 machines. For our community of Ubuntu members we will gladly increase that to 50 machines. Your personal subscription will also cover Livepatch, FIPS and CIS hardening tools.

不過手上 16.04 的機器也升的差不多了，好像用不太到...

在視訊會議裡面，用肩膀的移動猜測輸入的字串

在「Determining What Video Conference Participants Are Typing from Watching Shoulder Movements」這邊看到的方法，利用視訊會議時肩膀的移動猜測輸入的字串，原始的論文在「Zoom on the Keystrokes: Exploiting Video Calls for Keystroke Inference Attacks」這邊可以看到。

就論文有提到的，單就這個資訊的準確度看起來不高，看起來主要是想驗證這也是一個攻擊手法... 但馬上想到視訊會議裡如果有聲音的話，可以透過分析鍵盤的聲音攻擊，這在 2005 年的時候就有類似的手法了，而且準確率很高，不過不知道過了視訊會議軟體後會差多少：「Snooping on Text by Listening to the Keyboard」。

算是個頗特別的方法就是了...

HashiCorp 推出 Boundary 與 Waypoint

HashiCorp 推出了兩個新的產品。

第一個是 Boundary，這個產品看起來還很早期，但看起來想要實做 BeyondCorp 的一些想法 (可以參考之前寫的「Google 推的 BeyondCorp」)：「Announcing HashiCorp Boundary」，這在 Hacker News 上有討論串，而且 HashiCorp 的老大 Mitchell Hashimoto 也有出來回答一些問題：「HashiCorp Boundary (hashicorp.com)」。

這個產品讓他慢慢發展起來應該會是不錯的 open-source implementation，不過傳統的 castle 在小一點的場合也還算夠用...

另外一個是 Waypoint，看起來是個 CI/CD 類的產品：「Announcing HashiCorp Waypoint」，在 Hacker News 上也有討論串，而且同樣的 Mitchell Hashimoto 也有在裡面回覆一些東西：「Waypoint: Build, deploy, and release applications across any platform (hashicorp.com)」。

我自己看了一下設定的方式以及一些畫面，然後再回頭看 Hacker News 上的討論，以目前得到的資訊來看，這個產品似乎沒有很明顯解決到痛點，也許就是補產品線...

Google Chrome 的顯示完整 URL 的方式又改了...

剛剛更新 Google Chrome 後發現 address bar 又被動手腳了 (我是 beta channel 的版本)，在網址列上的 Protocol (Scheme) 與 www subdomain 不見了，而本來裝 Suspicious Site Reporter 可以讓 URL bar 恢復的方式也失效了。

翻了一下老問題「Chrome address bar no longer shows protocol or www subdomain」，裡面有提到新的解法 (他寫的當下) 是「The current solution in Chrome 83+」這個，直接在網址列上選右鍵，可以看到 Always show full URLs 這個選項，這是整個 Google Chrome 的選項，而非單一站台選項，選下去後就生效了：

而本來的 Suspicious Site Reporter 也可以拔掉了 (沒有用處了)。