Amazon CA 在 renew 時將引入動態的 Intermediate CA

上個月 AWS 發的公告,其實已經生效了,但整理的時候才發現還沒寫:「Amazon introduces dynamic intermediate certificate authorities」。

先介紹一下 Amazon CA,這是 Amazon 自己維護的 Root CA,有走過 CA/Browser Forum 的規範與稽核,以及各家瀏覽器額外的要求,所以是個用戶端預設都有信任的 CA。

這個服務後來也被用在 AWS Certificate Manager (ACM) 上,由 ACM 申請到的憑證也都可以掛到 AWS 的各種服務上。

通常 root CA 的憑證不會直接拿來簽最終使用者使用的憑證 (leaf certificate),而是 root CA 的憑證先簽 intermediate CA 的憑證,然後 intermediate CA 可能有好幾層一路簽下來,到最後面再用 intermediate CA 的憑證簽最終使用者使用的憑證。

這次公告的內容就題到了,之前的 intermediate CA 是一個固定範圍的量,而且會確保 renew 時用的 intermediate CA 跟先前的是相同的:

Before this change, Amazon maintained a limited number of intermediate CAs and issued and renewed certificates from the same intermediate CAs.

這次則是會變成動態:

With this change, leaf certificates issued to you will be signed by different intermediate CAs.

生效日期是這個月十一日,其實已經生效了:

Starting October 11, 2022 at 9:00 AM Pacific Time, public certificates obtained through ACM will be issued from one of the multiple intermediate CAs that Amazon manages.

一般的用戶端 (像是瀏覽器) 基本上應該是不會有問題,因為大多數預設都是信任 root CA,而非 intermediate CA,而這次的改變還是可以從 root CA 產生出對應的 trust chain。

官方有提到一個有可能的情況:如果你的應用程式有設定 certificate pinning 的話,應該是對 root CA 設定,而非對 intermediate CA 或是 leaf 做:

If you use intermediate CA information through certificate pinning, you will need to make changes and pin to an Amazon Trust Services root CA instead of an intermediate CA or leaf certificate.

這個也算通則,因為就 certificate pinning 想要做到的效果,對 root CA 做就就行了...

Cloudflare 預定推出 SSH command logging 功能

Cloudflare 預定要推出 SSH command logging 功能:「Introducing SSH command logging」。

看起來是 Cloudflare Zero Trust 產品線:

We’re excited to announce SSH command logging as part of Cloudflare Zero Trust.

翻了 Zero Trust 的 Pricing 資訊,Free Plan 看起來是 50 users 以下不用錢,但不確定這個功能會被放到 Core Features 內還是會被放到另外要收費的部份。

早在 AWS 在 2016 年的時候有用 script 整合了一個方案出來,裡面提到的方法不限於 AWS 上才能用:「How to Record SSH Sessions Established Through a Bastion Host」。

翻了一下 open source 專案,看起來有一些 open source 方案可以用:

另外這個需求在資安要求比較高的行業算是很常見,非 open source 的方案就有不少,先隨便抓兩個:

網頁的死亡線

是一篇 2017 年的文章,前幾天在 Hacker News 上重新被提出來:「The Line of Death (2017) (textslashplain.com)」。

文章開頭在講瀏覽器 UI 的信任區,這條線以上是 native UI,以下是網站可以任意操控的內容:

所以 UI 上面有些小細節讓你區分,但這其實對不是專精 phishing 的人很不友善:

另外當然就會提到 browser-in-a-browser (以及 picture-in-picture) 類的 phishing 了:

另外提到了 Fullscreen API,這使得信任區間變成 0:

提到 Fullscreen API 所以就去翻資料,意外發現 IE11 居然支援這組 API,雖然是帶 ms 的 prefix,而且不支援一些輔助性的功能 (像是傳回 Promise object)。

這些 UI 與 security 類的問題,主要還是得考慮到使用者未必那麼熟悉,以及就算有經驗的人也很有可能不小心中獎...

美國聯邦政府推動的 Zero Trust 架構

看到美國總統行政辦公室發佈的「Moving the U.S. Government Toward Zero Trust Cybersecurity Principles」這個備忘錄,在講 Zero trust security model,算是讓其他聯邦單位可以依循的指引,從比較高的角度來說明聯邦政府對系統安全設計的方向。

裡面有提到「Phishing-resistant MFA」,一般的 MFA 無法防止 phishing (像是軟體 TOTP 類的 Google Authenticator 或是硬體式 TOTP 的 RSA SecurID,或是透過簡訊輸入收到的字串那種),要能夠對抗 phishing 的應該只有 U2F 或是後續的 WebAuthn 這種有把網站位置也放進 protocol 的協定。

另外提到了 RBACABAC 兩種設計,而且更偏好用 ABAC 得到更多彈性:

Currently, many authorization models in the Federal Government focus on role-based access control (RBAC), which relies on static pre-defined roles that are assigned to users and determine their permissions within an organization. A zero trust architecture should incorporate more granularly and dynamically defined permissions, as attribute-based access control (ABAC) is designed to do.

另外因為 zero trust 的設計,內部網路其實只能當作是一個傳輸媒介,不能當作是一個安全的傳輸層,任何的傳輸都需要有另外的驗證機制確保 CIA,所以從 DNS 的流量必須是透過 DNS over HTTPS 或是 DNS over TLS 的保護:

Agencies must resolve DNS queries using encrypted DNS wherever it is technically supported. This means that agency DNS resolvers must support standard encrypted DNS protocols (DNS-over-HTTPS or DNS-over-TLS), and must use them to communicate with upstream DNS resolvers.

任何 HTTP 傳輸都需要使用 HTTPS 保護,甚至是把 .gov 直接放進 HTTPS-only 清單 (應該是指 HSTS preload?):

More generally, the .gov top-level domain has announced an intent to eventually preload the entirety of the .gov domain space as an HTTPS-only zone.

不過裡面也有提到 email 的 encryption 到目前為止沒有好的方法可以確保 encryption 的使用,尤其是跟外部的人溝通:

Unlike HTTP and DNS, there is not today a clear path forward for guaranteeing that Federal emails are encrypted in transit, particularly for emails with external parties.

然後提到安全漏洞的測試與回報機制也蠻有趣的,像是鼓勵外部測試:

In addition to their own testing programs, agencies must increase their reliance on external perspectives to identify vulnerabilities that internal staff may not identify

以及鼓勵安全回報的制度:

Public vulnerability disclosure programs, which allow security researchers and other members of the general public to report security issues safely, are used widely across the Federal Government and many private-sector industries. These programs are an invaluable accompaniment to existing internal security programs and operate as a reality check on an organization’s online security posture.

拿來翻一翻讀一讀...

PayPal 也要提供加密貨幣服務

先是看到「PayPal to allow cryptocurrency buying, selling and shopping on its network」這篇,另外翻到了 PayPal 的新聞稿:「PayPal Launches New Service Enabling Users to Buy, Hold and Sell Cryptocurrency」。

幾個比較重要的地方是,這次會提供的是 BitcoinEthereumBitcoin Cash 以及 Litecoin 這四種:

To increase consumer understanding and adoption of cryptocurrency, the company is introducing the ability to buy, hold and sell select cryptocurrencies, initially featuring Bitcoin, Ethereum, Bitcoin Cash and Litecoin, directly within the PayPal digital wallet.

會先提供美國 PayPal 的使用者使用,然後再展到其他服務以及地區:

The service will be available to PayPal accountholders in the U.S. in the coming weeks. The company plans to expand the features to Venmo and select international markets in the first half of 2021.

另外這次的服務也不是自己跳進去搞,而是透過 Paxos Trust Company 建立起防火牆,所以當加密貨幣那邊出包的時候大概就會切割出來:

The service is enabled in the U.S. through a partnership with Paxos Trust Company, a regulated provider of cryptocurrency products and services.

比較像是個嘗試,只是這個主題很適合發新聞稿...

TWCA 不在 Java Trust Store 裡...

SSL Labs 上翻資料的時候發現看到台灣有些網站的 SSL 憑證在 Java Trust Store 內是不會取得信任授權的,但其他的都支援,像是這樣:

翻了幾個後發現都是 TWCA 的,在其他家都是這樣授權出來的 (Mozilla/Apple/Android/Windows):(TWCA Root Certification Authority -> ) TWCA Global Root CA -> TWCA Secure SSL Certification Authority -> Final,也就是 TWCA 的兩個 Root CA 都在 trust store 內,走任何一條授權都可以拉出來。

印象中之前應該都是支援的... 先前是 cross sign 嗎?@_@

Mozilla 對 WoSign + StartCom 的正式處分

MozillaWoSign + StartCom 的不信任處分出爐了:「Distrusting New WoSign and StartCom Certificates」,最後處分的內容跟之前的討論差不多 (參考先前寫的「Mozilla 對於 WoSign + StartCom 根憑證的新發展:拔除」)。

Mozilla 台灣有放出中文版的說明 (差不多就是英文翻譯的版本):「取消對 WoSign 與 StartCom 新簽發憑證的信任」。

這次比較麻煩的地方在於要信任已經發出的 certificate,而且量太大無法窮舉。所以必須改增加程式碼處理,而這個方法無法對使用 Mozilla CA Certificate Store 的人生效 (因為這包套件只是一堆 pem 檔案,沒辦法放特殊的邏輯進去...)

另外現在 Firefox 是 49 版,要到 51 版才會生效,看起來還會花一陣子...

Firefox 49 將可以吃系統的 Certificate Trust Store

在「Upcoming Changes to Root Certificates in Firefox on Windows」這邊看到 Firefox 49 將會有選項可以讓 Firefox 多吃系統的 Certificate Trust Store:

This feature is available in Firefox 49 and up (currently in beta). To give it a try, set the preference security.enterprise_roots.enabled to true. After that, Firefox should connect successfully to sites using certificates issued by 3rd party root certificates that have been added to the Windows trust database.

這對企業來說會比較方便管理。

These features are still in the early stages, so if you encounter any unexpected behavior, please feel free to file a bug.

然後正在測試階段,有問題的可以去戳...

Love your country, but never trust its government

Hacker News Daily 上看到的,在 Sun-2 的 bootloader 裡可以看到「Love your country, but never trust its government」這樣的字串:「Why the Sun 2 has the message "Love your country, but never trust its government"」。

這段字串是由 John Gilmore 當時在 Sun 開發時所放入的,John Gilmore 同時也是後來 EFF 創辦人之一,不過當初放入這段字串的目的是為了抓到盜版:

Yes. Vinod Khosla, first President of Sun, came to me at one point and said to put something hidden, triggered in an unexpected way, into the ROM Monitor, so that if somebody cloned the Sun Workstation (violating our software’s copyright), we could do that unexpected thing to the competitor’s demo workstation at a trade show and thereby prove that they had cloned it.

過了三十年後 John Gilmore 被挖出來問的回應也是蠻有趣的... (可以參考原文附上的信件)

而這句話現在回頭看也很經典,尤其是最近各國政府想要在 crypto system 裡面放後門的各種反應。

STARTTLS 的不完整性以及大規模監控電子郵件

在「Don’t count on STARTTLS to automatically encrypt your sensitive e-mails」這邊提到了 STARTTLS 的問題,引用「Neither Snow Nor Rain Nor MITM ... An Empirical Analysis of Email Delivery Security」這篇論文的說明。

SMTP 裡 STARTTLS 的設計雖然可以加密,但仲所皆知,可以阻擋 EHLO 回應結果避免建立 STARTTLS 連線,而讓發送端改用傳統未加密的 SMTP 傳輸。而研究發現其實目前就有大規模的這種監控行為:

可以看到突尼西亞的監控情況遠超過想像...

目前的想法是發展一套類似 HSTS 的 Trust on first use 設計,也許在這份報告出來後可以加速催生...