Tag Archives: root

從 Homebrew 換用 MacPorts...

看到「Thoughts on macOS Package Managers」這篇的介紹,文章作者在裡面提到從 Homebrew 換用 MacPorts 的幾個原因...

裡面有提到 root 權限的問題 (Homebrew 的 workaround),以及軟體豐富度的問題 (常用的應該都有,這邊的差異會是冷門一些的軟體)。不過這些大概都是之前都已經知道的... 比較新的是目前維護者在 integrity 上的問題:

用「How to uninstall Homebrew?」這邊的方法移除 Homebrew 後,再去 MacPorts 官網上下載檔案安裝,跑一陣子看看會不會有什麼問題...

目前看起來比較大的問題都是出自 /opt/local/{bin,sbin} 架構,這個可以靠在 /etc/profile 裡面設定解決 (不是很愛這個方法,但至少這樣會動...)。

Let's Encrypt 從七月開始將會改用自己的 Root 簽發憑證

Let's Encrypt 宣佈了以後的憑證的簽發計畫:「Transitioning to ISRG's Root」。

主要的改變是 2019/07/08 之後提供的 intermediate CA 會改變,從現在的 cross-sign 變成只有自己的 Root CA:

On July 8, 2019, we will change the default intermediate certificate we provide via ACME. Most subscribers don’t need to do anything. Subscribers who support very old TLS/SSL clients may want to manually configure the older intermediate to increase backwards compatibility.

目前的簽發用的兩個中介憑證 (Let's Encrypt Authority X3Let's Encrypt Authority X4) 是由 Let's Encrypt 自己的 ISRG Root X1IdenTrustDST Root CA X3 所 共同簽署的:

這是因為 IdenTrust 的 DST Root CA X3 憑證很久前就被各家瀏覽器信任 (像是 Mozilla 的「Request to add two additional IdenTrust root CA certificates」這篇,可以看到 2007 年就被放進去了),而 Let's Encrypt 當時為了更快把可用的產品推出,所以跟 IdenTrust 合作,採用 cross sign 的方式讓 Let's Encrypt 簽出來的憑證被一般瀏覽器與函式庫所信任。

現在差不多過了三年半,Let's Encrypt 成為目前世界上最大的 SSL Certificate 發放單位,加上自己的 Root CA (ISRG Root X1) 也都差不多被整合進各家系統內了,所以打算要獨立自己簽了。

不過系統上可以設定,使用者如果有遇到相容性問題 (太舊的系統可能還是不包含 Let's Encrypt 自家的 ISRG Root X1),還是可以設定使用有 cross-sign 的版本 (維持現狀)。與 IdenTrust 的 cross-sign 會維持到 2021 年九月,大約再兩年多一些:

Our current cross-signature from IdenTrust expires on March 17, 2021. The IdenTrust root that we are cross-signed from expires on September 30, 2021. Within the next year we will obtain a new cross-signature that is valid until September 29, 2021. This means that our subscribers will have the option to manually configure a certificate chain that uses IdenTrust until September 29, 2021.

對於自用來說應該沒什麼大影響,主要是企業用戶要注意相容性...

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

這邊講的應該是在 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% 的流量其實是有被過濾的?

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.

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

幫你在本機產生 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 的程式碼就可以全環境共用了...

EC2 支援休眠

AWSEC2 instance 推出了休眠模式:「New – Hibernate Your EC2 Instances」。

休眠模式主要是透過保留記憶體內的內容 (會寫到 EBS 裡),讓機器開起來比較快,不過這邊有要求 root EBS volume 需要加密:

When an instance is instructed to hibernate, it writes the in-memory state to a file in the root EBS volume and then (in effect) shuts itself down. The AMI used to launch the instance must be encrypted, as must the root EBS volume of the instance. The encryption ensures proper protection for sensitive data when it is copied from memory to the EBS volume.

費用的部分是 EBS volume 與 Elastic IP:

While the instance is in hibernation, you pay only for the EBS volumes and Elastic IP Addresses attached to it; there are no other hourly charges (just like any other stopped instance).

一般對外服務的伺服器好像用不太到... 應該是內部系統或是開發機的需求?

Travis CI 將轉移到 VM-based 環境

Travis CI 宣佈了將目前 container-based 的環境轉移到 VM-based 的時程:「Upcoming Required Linux Infrastructure Migration」,裡面有提到十月初的時候的文章「Combining The Linux Infrastructures」。

看起來是因為安全性的考慮,container-based 的環境必須在指定 sudo: false 的情境下才能使用。如果需要 root 權限一定會丟到 VM-based 的環境跑。現在看起來 Travis CI 不打算維護 container-based 環境了,所以整個轉移到 VM-based 的環境...

另外一個方向應該是 Google 之前提出來的 gVisor 專案 (參考「Google 推出 gVisor 強化 Container 的安全性」),不過看起來相容性又是個問題...

CVE-2018-14665:setuid 複寫檔案的 security issue...

Twitter 上看到的 security issue,好久沒在這麼普及的軟體上看到這種 bug 了:

CVE - CVE-2018-14665 的說明裡面有提到 1.20.3 前的版本都有中,但沒講到從哪個版本開始,看起來是全系列...?

A flaw was found in xorg-x11-server before 1.20.3. An incorrect permission check for -modulepath and -logfile options when starting Xorg. X server allows unprivileged users with the ability to log in to the system via physical console to escalate their privileges and run arbitrary code under root privileges.

這一臉 orz...

Let's Encrypt 被所有主流瀏覽器直接支援了...

Let's Encrypt 宣佈他們的憑證被所有主流瀏覽器直接支援了,也就是都在各平台的 trusted store 內了:「Let's Encrypt Root Trusted By All Major Root Programs」,看起來這次加入的是 Microsoft 的產品:

As of the end of July 2018, the Let’s Encrypt root, ISRG Root X1, is directly trusted by Microsoft products. Our root is now trusted by all major root programs, including Microsoft, Google, Apple, Mozilla, Oracle, and Blackberry.

先前是靠 IdenTrust 的 cross signing 讓各瀏覽器信任,在「Chain of Trust」這邊有圖說明:

另外查了一下 cross signing 的資訊,以 Let's Encrypt Authority X3 這張的 cross signing 可以看到 cross sign 簽了五年,到 2021 年:(憑證可以從 letsencryptauthorityx3.pem.txt 這邊取得,用 openssl x509 -in letsencryptauthorityx3.pem.txt -text 看到)

    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = US, O = Internet Security Research Group, CN = ISRG Root X1
        Validity
            Not Before: Oct  6 15:43:55 2016 GMT
            Not After : Oct  6 15:43:55 2021 GMT
        Subject: C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3

這樣約滿不知道會不會續簽...

用 Stubby 在 Ubuntu 上跑 DNS over TLS

透過 DNS over TLS 會損失一些效能 (我用 VDSL 的光世代測試,大約是從 10ms 變成 40ms),但可以讓 ISP 看不到你查詢什麼,對於隱私有很大的幫助... 而先前是一直在看 Ubuntu 上的 Unbound 什麼時候會有 1.8.0+ 的版本可以用 (支援 DNS-over-TLS),但一直沒看到,結果在「How to Protect Your DNS Privacy on Ubuntu 18.04 with DNS over TLS」這邊看到 Stubby 這個軟體。

Stubby 在 Ubuntu 18.04 上可以直接裝,但在 Ubuntu 16.04 上需要透過 PPA 裝,我是透過「DNS Utils : James Newell」這個安裝的,裝好後 /etc/stubby/stubby.yml 檔裡 upstream_recursive_servers 的設定改成:

upstream_recursive_servers:
  - address_data: 1.1.1.1
    tls_auth_name: "cloudflare-dns.com"
  - address_data: 1.0.0.1
    tls_auth_name: "cloudflare-dns.com"

就可以走 port 853 的 DNS over TLS 了,而 Stubby 預設會聽 127.0.0.1::1 的 port 53,所以把 /etc/resolv.conf 或是 NetworkManager 的設定改成 127.0.0.1 就可以了。

目前這樣設看起來沒辦法擋 MITM attack (偽造 SSL certificate),Stubby 看起來只能用 tls_pubkey_pinset 鎖住,但實在不愛這個方法 (因為 Cloudflare 有可能會換成其他的 SSL certificate),之後看看有沒有可以吃 Root CA 架構的認證再來調整...