Home » Posts tagged "ca" (Page 3)

未來 CA 將會強制要求檢查 DNS CAA record

CA/Browser 通過提案,要求以後 CA 單位都要檢查 DNS CAA record 才能發放憑證 (RFC 6844 的「DNS Certification Authority Authorization (CAA) Resource Record」):「Ballot 187 - Make CAA Checking Mandatory」。

Certificate Authority Authorization (CAA) is a DNS Resource Record defined in RFC 6844 – https://datatracker.ietf.org/doc/rfc6844/ , published in January 2013. It allows a DNS domain name holder to specify one or more Certification Authorities (CAs) authorized to issue certificates for that domain and, by implication, that no other CAs are authorized.

透過 DNS CAA 資料,你可以限制只有誰可以發你的憑證,直接用白名單做控管。

未來 SSL Certificate 的最大有效時間將降到 825 天

CA/Browser Forum 通過了這項提案,將 SSL Certificate 的最大有效時間降到 825 天 (大約 27 個月):「Ballot 193 - 825-day Certificate Lifetimes」。

所以將會從本來的 39 個月降到 27 個月左右,所以現在買得到最長的 certificate 會有 3 年,以後會有 2 年:

Recent Ballot 185 demonstrated a consensus among Forum members to reduce the maximum lifetime for DV and OV certificates from 39 months to 825 days (roughly 27 months). This ballot reflects that consensus, and also reduces the maximum period for reuse of vetting data for DV and OV certificates from 39 months to 27 months.

Firefox 下一個版本 (52) 將預設關閉 SHA-1 支援

順著 SHA-1 正式被打穿,Mozilla 也正式宣佈從下一個版本的 Firefox 將完全關閉 SHA-1 支援 (看敘述應該還是可以透過 about:config 開):「The end of SHA-1 on the Public Web」。

As announced last fall, we’ve been disabling SHA-1 for increasing numbers of Firefox users since the release of Firefox 51 using a gradual phase-in technique. Tomorrow, this deprecation policy will reach all Firefox users. It is enabled by default in Firefox 52.

大家都開始有動作了...

dehydrated 0.4.0 的新要求

dehydrated 出 0.4.0 了,剛剛把 PPA for dehydrated 更新了,已經安裝過的使用者可以直接升級使用。

這次主要的改變在於建立帳號時必須先同意 Let's Encrypt 的使用條款:

dehydrated now asks you to read and accept the CAs terms of service before creating an account

這邊可以用 dehydrated --register --accept-terms 表示同意並且建立帳號。

微軟預定在 2017 年的西洋情人節淘汰 SHA-1 certificate

經過多次改動後,微軟這次宣佈 SHA-1 certificate 將在明年淘汰:「SHA-1 deprecation countdown」。

影響的範圍包括 Internet Explorer 11Microsoft Edge,在 2017 年 2 月 14 日之後不信任 SHA-1 certificate:

Starting on February 14th, 2017, Microsoft Edge and Internet Explorer 11 will prevent sites that are protected with a SHA-1 certificate from loading and will display an invalid certificate warning.

與其他家類似,還是提供了管道讓企業內部建立的 SHA-1 certificate 可以用:

This will only impact SHA-1 certificates that chain to a Microsoft Trusted Root CA. Manually-installed enterprise or self-signed SHA-1 certificates will not be impacted, although we recommend for all customers to quickly migrate to SHA-256.

Google Chrome 將在 2017 的 56 版停止支援 SHA-1 SSL Certificate

在明年一月的 Google Chrome 56 將會停止支援 SHA-1 SSL Certificate:「SHA-1 Certificates in Chrome」,唯一的例外是自己建立的 CA,主要是給企業內部用的:

Starting with Chrome 54 we provide the EnableSha1ForLocalAnchors policy that allows certificates which chain to a locally installed trust anchor to be used after support has otherwise been removed from Chrome.

但安全性的標示不會是綠色的鎖頭:

Features which require a secure origin, such as geolocation, will continue to work, however pages will be displayed as “neutral, lacking security”.

使用 SHA-1 程式碼的完全移除預定在 2019 年 (大約兩年多):

Since this policy is intended only to allow additional time to complete the migration away from SHA-1, it will eventually be removed in the first Chrome release after January 1st 2019.

但如果對 SHA-1 攻擊有重大突破的話也會考慮提前:

We may also remove support before 2019 if there is a serious cryptographic break of SHA-1.

Google Chrome 也宣佈不信任 WoSign + StartCom 的計畫

Google Chrome 也公開了對 WoSign + StartCom 的計畫:「Distrusting WoSign and StartCom Certificates」。

由於大家遇到的技術問題都一樣 (之前發出的量太大,無法窮舉表列出來),所以處理的方法也類似於 Mozilla 的作法,只信任 2016/10/21 前發出的 certificate:

Beginning with Chrome 56, certificates issued by WoSign and StartCom after October 21, 2016 00:00:00 UTC will not be trusted.

Google Chrome 目前是 54,所以這表示會在兩個版本後生效。另外特別提出來必須有 CT flag (Certificate Transparency),或是在白名單的網站:

Certificates issued before this date may continue to be trusted, for a time, if they comply with the Certificate Transparency in Chrome policy or are issued to a limited set of domains known to be customers of WoSign and StartCom.

而因為安全考量,會有某些 certificate 是沒救的情況:(就上面的描述,看起來是指不在白名單內又沒標 CT flag 的)

Due to a number of technical limitations and concerns, Google Chrome is unable to trust all pre-existing certificates while ensuring our users are sufficiently protected from further misissuance.

話說 www.kernel.org 從本來的 StartCom 換掉了 (之前都要打 badidea 進去看),剛剛看是 2016/10/11 簽的憑證...

這樣除了 Microsoft 還是沒動作外,其他比較大的瀏覽器都到齊了...

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 版才會生效,看起來還會花一陣子...

Mozilla 對於 WoSign + StartCom 根憑證的新發展:拔除

Okay,在 Mozilla 的人跟 WoSign + StartCom + 360 的人談過後有了新的進展。

幾個小時前 Mozilla 提了新版的草案出來 (對,還是草案):「Remediation Plan for WoSign and StartCom」。但由於 Kathleen Wilson 跟 Gervase Markham 都沒有太多意見,我猜這應該會接近定案了。

這次的處分草案由 Kathleen Wilson 發出來,會包括這些 root certificate,可以看到包括了所有 WoSign 與 StartCom 的 CA:

1) Subject: CN=CA 沃通根证书, OU=null, O=WoSign CA Limited, C=CN
2) Subject: CN=Certification Authority of WoSign, OU=null, O=WoSign CA Limited, C=CN
3) Subject: CN=Certification Authority of WoSign G2, OU=null, O=WoSign CA Limited, C=CN
4) Subject: CN=CA WoSign ECC Root, OU=null, O=WoSign CA Limited, C=CN
5) Subject: CN=StartCom Certification Authority, OU=Secure Digital Certificate Signing, O=StartCom Ltd., C=IL
6) Subject: CN=StartCom Certification Authority, OU=Secure Digital Certificate Signing, O=StartCom Ltd., C=IL
7) Subject: CN=StartCom Certification Authority G2, OU=null, O=StartCom Ltd., C=IL

首先是認定這一連串的事件是惡意行為:

Based on the information that I have seen regarding WoSign, I believe that WoSign intentionally bent the rules in order to continue issuing SHA-1 SSL certs, when they knew full well that was no longer allowed. I also believe that the deception continued even after Mozilla directly asked WoSign about this. WoSign has lost my confidence in their ability and intention to follow Mozilla's policies.

所以打算採取與 CNNIC 類似的處分方法,但很不幸的由於規模不一樣,所以被迫採用另外的方式來處理:

Therefore, I think we should respond similarly to WoSign as we did to CNNIC [1][2]. Unfortunately, the number of certificates and the timescales involved are such that we prefer not to create a list of the domains for which previously-issued certs that chain up to the Affected Roots may continue to be trusted, so our approach will be a little different, as Gerv previously described[3].

這次處分的過程會包括四個項目,第一個是在 Firefox 51 會用黑名單的方式將這些 root certificate 擋下,但會信任 2016/10/21 前所發出的憑證以降低對目前網站的衝擊:

1) Distrust certificates chaining up to Affected Roots with a notBefore date after October 21, 2016. If additional back-dating is discovered (by any means) to circumvent this control, then Mozilla will immediately and permanently revoke trust in the Affected Roots.
-- This change will go into the Firefox 51 release train [4].
-- The code will use the subject key id (hash of public key) to identify the Affected Roots, so that the control will also apply to cross-certs of the Affected Roots.

然後將之前簽出來的 SHA-1 憑證列入 OneCRL:

2) Add the previously identified backdated SHA-1 certs chaining up to the Affected Roots to OneCRL.

另外一個非常大的事情是,Mozilla 將永久不信任安永香港的稽核報告:

3) No longer accept audits carried out by Ernst & Young Hong Kong.

Gervase Markham 做了補充「永久」的部份:

To be clear, this is a permanent ban, applicable worldwide, but only to the Hong Kong branch of E&Y. (If further issues are found with E&Y audits elsewhere, then we might consider something with wider scope.)

最後一個是移除 NSS 裡包的憑證:

4) Remove the Affected Roots from NSS after the SSL certificates issued before October 1, 2016, have expired or have been replaced.

在討論裡有提到 Firefox 與 NSS 的處置日期不太一樣的問題 (一個是 10/21,一個是 10/01),應該會在正式的定案時修正。

另外在「StartCom & Qihoo Incidents」這邊,Google 家的 Ryan Sleevi 也寫了一串,也許是他目前個人的看法 (但畢竟他是 Google 家主事的人之一),基本上的立場與 Mozilla 相同 (將 WoSign 與 StartCom 視為同一個單位,而且是刻意違反 Baseline Requirement),所以後續應該也會有動作了...

Comodo 取消對 WoSign CA 的 Cross-signed

剛剛看到 ComodoRob Stradling 在群組上說明了 Comodo 透過 CRLOCSP 取消對 WoSign CA 的 cross-signed:「Incidents involving the CA WoSign」。

Today we have revoked (via CRL and OCSP) all 3 of the cross-certificates that we'd issued to WoSign:

https://crt.sh/?id=3223853
https://crt.sh/?id=12716343
https://crt.sh/?id=12716433

See also:
https://bugzilla.mozilla.org/show_bug.cgi?id=906611#c2

然後另外也看到在倫敦與 Qihoo 360StartCom 以及 WoSign 的會面也已經結束了,接下來 Mozilla 會討論新的計畫後更新上來:「WoSign and StartCom: next steps」。

Archives