Tag: ca

2017 年 CA/Browser Forum 在台北辦的見面會議的會議記錄出爐了...

2017 年 CA/Browser Forum 在台北舉辦的見面會議，會議記錄總算是出爐了：「2017-10-04 Minutes of Face-to-Face Meeting 42 in Taipei - CAB Forum」。

由於是辦在台北，所以台灣很多單位都有出席，像是中央警察大學 (1)、中華電信 (11)、日盛聯合會計師事務所 (1)、TWCA (3)：

Attendance: Peter Bowen (Amazon); Geoff Keating and Curt Spann (Apple); Jeremy Shen (Central Police University); Franck Leroy (Certinomis / Docapost); Wayne Chan and Sing-man Ho (Certizen Limited); Wen-Cheng Wang, Bon-Yeh Lin, Wen-Chun Yang, Jenhao Ou, Wei-Hao Tung, Chiu-Yun Chuang, Chung-Chin Hsiao, Chin-Fu Huang, Li-Chun Chen, Pin-Jung Chiang, and Wen-Hui Tsai (Chunghwa Telecom); Alex Wight and JP Hamilton (Cisco), Robin Alden (Comodo), Gord Beal (CPA Canada), Ben Wilson and Jeremy Rowley (DigiCert), Arno Fiedler and Enrico Entschew (D-TRUST); Kirk Hall (Entrust Datacard); Ou Jingan, Zhang Yongqiang, and Xiu Lei (GDCA); Atsushi Inaba and Giichi Ishii (GlobalSign); Wayne Thayer (GoDaddy); Devon O’Brien (Google); David Hsiu (KPMG); Mike Reilly (Microsoft); Gervase Markham and Aaron Wu (Mozilla); Hoang Trung La (National Electronic Authentication Center (NEAC) of Vietnam); Tadahiko Ito (Secom Trust Systems); Leo Grove and Fotis Loukos (SSL.com); Brian Hsiung (Sunrise CPA Firm); Steve Medin (Symantec); Frank Corday and Tim Hollebeek (Trustwave); Robin Lin, David Chen, and Huang Fu Yen (TWCA); and Don Sheehy and Jeff Ward (WebTrust).

開頭有提到會議記錄 delay 的情況：

Preliminary Note: The CA/Browser Forum was delayed in completing the minutes for its last Face-to-Face meeting Oct. 4-5, 2017 in Taipei, and the proposed final Minutes were only sent by the Chair to the Members on December 13, 2017 for their review. There was not enough time for Members to review the draft before the next teleconference of December 14, and the teleconference of December 28 was cancelled due to the holidays. The next Forum teleconference is scheduled for January 11, 2018.

會議記錄很長，主要是有不少主題被拿到見面會議上討論，另外有一半的篇幅是在說明各家 root program policy 的變化。

下次的見面會議會在三月，然後會由 Amazon 辦在東岸：

Peter confirmed the next F2F meeting will be hosted by Amazon on March 6-8, 2018 at its Herndon, Virginia location. More information will be provided in the coming months.

StartCom 決定關門

在 Hacker News 上看到 StartCom 決定關門的消息：「Termination of the certificates business of Startcom」。

2018 停發新的憑證，然後維護兩年 CRL 與 OCSP 服務：

We´ll set January 1st 2018 as the termination date and will stop issuing certificates therefrom. We will maintain our CRL and OCSP service for two more years from January 1st 2018. The three pairs of StartCom key Roots will be eliminated after that time.

在不斷的抵制下總算關了...

Savitech (盛微) 的 USB 音效驅動程式會安裝 Root CA (被發了 CVE-2017-9758)

在 Hacker News 上看到 CERT 的「Savitech USB audio drivers install a new root CA certificate」提到 Savitech USB audio driver 會安裝自己的 Root CA：

Savitech provides USB audio drivers for a number of specialized audio products. Some versions of the Savitech driver package silently install a root CA certificate into the Windows trusted root certificate store.

出自「Inaudible Subversion - Did your Hi-Fi just subvert your PC? (原網站已經無法訪問，參考備份連結 https://archive.is/K6REr)」，CVE 編號是 CVE-2017-9758，最初是由 n3kt0n 提出的：「某單位 drivers silently install certificate in trusted root certificate authorities store [CVE-2017-9758]」：

Mitre assigned this exposure the identifier CVE-2017-9758, but was initially tracked by HITCON ZeroDay project as ZD-2017-00386.

有兩把 CA public key 被塞進去。雖然目前還沒有徵兆 private key 有外洩，但還是建議儘快移除：

There is currently no evidence that the Savitech private key is compromised. However, users are encouraged to remove the certificate out of caution. The two known certificates are:

SaviAudio root certificate #1
‎Validity: Thursday, ‎May ‎31, ‎2012 - ‎Tuesday, ‎December ‎30, ‎2036
Serial number: 579885da6f791eb24de819bb2c0eeff0
Thumbprint: cb34ebad73791c1399cb62bda51c91072ac5b050

SaviAudio root certificate #2
Validity: ‎Thursday, ‎December ‎31, ‎2015 - ‎Tuesday, ‎December ‎30, ‎2036
Serial number: ‎972ed9bce72451bb4bd78bfc0d8b343c
Thumbprint: 23e50cd42214d6252d65052c2a1a591173daace5

另外 Savitech 也放出了新版的 driver，不包含 Root CA：

Savitech has released a new driver package to address the issue. Savitech drivers version 2.8.0.3 or later do not install the root CA certificate. Users still must remove any previously installed certificate manually.

看了一下說明，看起來是當時為了支援 Windows XP 而做的，但微軟已經不提供驅動程式的數位簽章了，所以就只好這樣搞...

Chromium 內提案移除 HPKP (HTTP Public Key Pinning)

Twitter 上看到這則 tweet，提到要移除 HPKP (HTTP Public Key Pinning)：

blink-dev 上的討論可以參考「Intent To Deprecate And Remove: Public Key Pinning」(就是上面那個連結，只是拉出來)。

這個提案大概可以推敲出理由... 目前的作法必須寫進瀏覽器內，這樣明顯會有 scale 問題，而且這個作法本身就很 workaround，只能保護所謂「高價值」的 domain，而且因為是綁在 Public Key 上，如果 CA 換了 Intermediate Certificate 就有可能會導致檢查過不了。

另外一方面，scale 而且合理的替代方案已經發展出來了。如果瀏覽器會檢查 DNS CAA 資訊 (這個規格可以在 DNS 裡設定有哪些 CA 可以簽這個 domain)，就能解這個問題 (加上 DNSSEC 會更加確保驗證過程)。像是這樣：

example.com.    IN      CAA     0 issue "letsencrypt.org"
example.com.    IN      CAA     0 issuewild ";"

不過這個提案本身提到 CT (Certificate Transparency) 怪怪的，因為 CT 無法避免惡意的簽發 (發了以後故意不送 CT)：

Finally, remove support for built-in PKP (“static pins”) at a point in the future when Chrome requires Certificate Transparency for all publicly-trusted certificates (not just newly-issued publicly-trusted certificates). (We don’t yet know when this will be.)

但在瀏覽器支援 DNS CAA 可以避免，結果在討論時都沒到 DNS CAA...

另外在 Hacker News 上也有討論：「Public Key Pinning Being Removed from Chrome (groups.google.com)」可以看一下，有個人有提到用 DNS CAA 的方法...

不過印象中這群人對 DNS-based 的方案都不太喜歡，所以也有可能是這樣不考慮在瀏覽器端實作 DNS CAA 吧...

Google Chrome 對 Symantec 全系列憑證的不信任計畫

Google Chrome 前陣子整理了一份對 Symantec 憑證的不信任計畫：「Chrome’s Plan to Distrust Symantec Certificates」。

這包括了一卡車的品牌，像是 Thawte、VeriSign、GeoTrust、RapidSSL，不過 Equifax 跟 Symantec 的關係我沒查到...：

Symantec’s PKI business, which operates a series of Certificate Authorities under various brand names, including Thawte, VeriSign, Equifax, GeoTrust, and RapidSSL, had issued numerous certificates that did not comply with the industry-developed CA/Browser Forum Baseline Requirements.

反正整個計畫會在 Google Chrome 70 推出時告一段落 (變成完全不信任)，會是 2018/09/13 (預定時間) 與 2018/10/23 (預定時間) 在 beta channel 與 stable channel 上推出。

中間比較重要的時間點是 2018/03/15 (預定時間) 與 2018/04/17 (預定時間)，Google Chrome 66 在 beta channel 與 stable channel 上推出，這個版本不會信任 2016/06/01 前發出的憑證：

Chrome 66 released to beta, which will remove trust in Symantec-issued certificates with a not-before date prior to June 1, 2016. As of this date Site Operators must be using either a Symantec-issued TLS server certificate issued on or after June 1, 2016 or a currently valid certificate issued from any other trusted CA as of Chrome 66.
Site Operators that obtained a certificate from Symantec’s old infrastructure after June 1, 2016 are unaffected by Chrome 66 but will need to obtain a new certificate by the Chrome 70 dates described below.

整個計畫的時間軸清楚多了...

Amazon Route 53 支援 CAA record 了

Amazon Route 53 宣佈支援 CAA record 了：「Announcement: Announcement: Amazon Route 53 now supports CAA records」、「Amazon Route 53 now supports CAA records」。

這是一個被動性的 workaround，要求 CA 本身要支援 DNS CAA，所以他沒辦法防止 CA 本身作惡誤簽，但因為負作用與技術債的可能性不高，在 CA/Browser Forum 上被通過強制要求支援了。(參考「未來 CA 將會強制要求檢查 DNS CAA record」)

Gandi 的 DNS 服務也支援了 (要透過 export mode，參考「How can I add a CAA record?」)，不過 Linode 還沒做...

Amazon Route 53 將會加緊支援 DNS CAA

看到 Amazon Route 53 要支援 DNS CAA 的消息：「Announcement: Announcement: CAA Record Support Coming Soon」。

裡面有提到 CA/Browser Forum 的決議，要求各瀏覽器支援 DNS CAA：

On March 8, 2017, the Certification Authority and Browser Forum (CA/Browser Forum) mandated that by September 8, 2017, CA’s are expected to check for the presence of a CAA DNS record and, if present, refuse issuance of certificates unless they find themselves on the whitelist <https://cabforum.org/2017/03/08/ballot-187-make-caa-checking-mandatory/>.

DNS CAA 可以設定哪些 SSL certificate 可以發出你的證書，除了自己以外，也可以讓第三者比較容易確認是否有誤發的行為：

We have seen a lot of interest in Amazon Route 53 support for Certification Authority Authorization (CAA) records, which let you control which certificate authorities (CA) can issue certificates for your domain name.

Google Chrome 對 WoSign 與 StartCom 的白名單要完全移除了

在 Twitter 上看到的：

對 WoSign 與 StartCom 的移除會發生在 61 版，而依照「Final removal of trust in WoSign and StartCom Certificates」這邊的說明，stable 應該會在九月出 61 版而生效：

Based on the Chromium Development Calendar, this change should be visible in the Chrome Dev channel in the coming weeks, the Chrome Beta channel around late July 2017, and will be released to Stable around mid September 2017.

Let's Encrypt 決定要規劃 Wildcard SSL Certificate 了

Let's Encrypt 把時間表喊出來了，預定在 2018 年年初開放使用：「Wildcard Certificates Coming January 2018」。

Wildcard SSL Certificate 會需要走新的 ACME v2 協定認證：

Wildcard certificates will be offered free of charge via our upcoming ACME v2 API endpoint. We will initially only support base domain validation via DNS for wildcard certificates, but may explore additional validation options over time.

跟前陣子提到的「ACME v2 API Endpoint Coming January 2018」是相同的時間。

這好讚...

IE 與 Edge 推出更新，阻擋 SHA-1 憑證

微軟這幾天推出更新，IE 與 Edge 將不會接受 SHA-1 憑證：「Microsoft Makes it Official, Cuts off SHA-1 Support in IE, Edge」。微軟的公告則是在「Deprecation of SHA-1 for SSL/TLS Certificates in Microsoft Edge and Internet Explorer 11」這邊。

根憑證不受影響 (所以企業自己產生的 Root CA 也不受影響)：

Beginning May 9, 2017, Microsoft released updates to Microsoft Edge and Internet Explorer 11 to block sites that are protected with a SHA-1 certificate from loading and to display an invalid certificate warning. This change will only impact SHA-1 certificates that chain to a root in the Microsoft Trusted Root Program where the end-entity certificate or the issuing intermediate uses SHA-1. Enterprise or self-signed SHA-1 certificates will not be impacted, although we recommend that all customers quickly migrate to SHA-2 based certificates.