Tag: forum

TLS 憑證的最長時效將從 825 天降到 398 天

在「Reducing TLS Certificate Lifespans to 398 Days」這邊看到才想起來沒寫這篇，這邊發生了一些有趣的事情...

提案是降低 TLS 憑證的有效時效，這件事情一開始是在 CA/B Forum 討論，但經過投票後沒有通過：「Ballot SC22 - Reduce Certificate Lifetimes (v2)」。

從投票記錄可以看到所有的憑證使用方 (包括了許多瀏覽器的廠商) 都贊同，但有大約 2/3 的憑證發行方都反對：

7 votes total including abstentions:

  • 7 Yes votes: Apple, Cisco, Google, Microsoft, Mozilla, Opera, 360
  • 0 No votes:
  • 0 Abstain:

33 votes total including abstentions

  • 11 Yes votes: Amazon, Buypass, Certigna (DHIMYOTIS), certSIGN, Sectigo (former Comodo CA), eMudhra, Kamu SM, Let’s Encrypt, Logius PKIoverheid, SHECA, SSL.com
  • 20 No votes: Camerfirma, Certum (Asseco), CFCA, Chunghwa Telecom, Comsign, D-TRUST, DarkMatter, Entrust Datacard, Firmaprofesional, GDCA, GlobalSign, GoDaddy, Izenpe, Network Solutions, OATI, SECOM, SwissSign, TWCA, TrustCor, SecureTrust (former Trustwave)
  • 2 Abstain: HARICA, TurkTrust

然後幾個比較大的憑證使用方 (Apple、Google、Mozilla) 在提案被否決後就決定放到自家的規則了：「Apple strong-arms entire CA industry into one-year certificate lifespans」。

從 2020/09/01 開始，如果發出來的憑證超過 398 天就當作是無效憑證，也就是 2020/08/31 是最後一天可以發有效期限為 825 天的憑證，會落在 2022/12/05 失效：

$ date --date='Sep 1 2020 GMT+0000 +825days'
Mon Dec  5 08:00:00 CST 2022

這三家搞下去，就等於是強制性讓這些 CA 到九月就不能賣兩年的憑證了 (雖然還沒看到 Microsoft)，這些 CA 一定是在心裡幹爆... XD

用 CleanTalk 擋論壇的廣告...

看到 Hacker News 上「You probably don’t need ReCAPTCHA (kevv.net)」這篇在討論 reCAPTCHA (原始文章在「You (probably) don’t need ReCAPTCHA」這篇)，裡面除了認為 reCAPTCHA harmful 的觀點還 ok 外，其他的觀點我覺得都無法讓人認同...

因為看到 reCAPTCHA 而想到已經用了 CleanTalk 一陣子，效果還不錯，所以寫一篇講一下...

起因是維護「FJC 華語社群」這個站台，這是一個使用 phpBB 架設的站台，為了方便，我透過 RSS + IFTTT，當論壇上有新文章時就會自動貼到 Line 群組上面...

為了避免論壇上面有 spam，我有針對註冊開 reCAPTCHA，但發現還是有不少「全人工註冊」的帳號會貼文，所以就得找更精準的服務來用... 後來在 phpBB 網站上翻到 CleanTalk 這個服務，對於在「CleanTalk Anti-Spam Installation Manuals」這頁看到支援的軟體只要 USD$8/year/site，從一月用到現在超過五個月了，就沒遇到 spam 了...

機制上他會透過 client database 分析他們自己的 spam 資料庫，另外在發文時他也會分析文章內容是不是 spam，所以裝上去之後兩關都有過濾機制...

類似的服務還有 Akismet，不過畢竟是知名品牌，費用相較起來貴不少...

在 Ubuntu 18.04 (Bionic) 上跑 Percona Server 5.7

在 Percona 的文件「Installing Percona Server on Debian and Ubuntu」這邊雖然還沒列 Ubuntu 18.04 上去，但已經有東西在裡面可以安裝了。不過還是屬於官方未正式支援的情況，用的時候自己要注意。

另外查資料的時候有看到「Ubuntu 18.04 (bionic) - percona-xtradb-cluster-server installation break」這篇提到 Percona XtraDB Cluster 裝不起來，但有 workaround 可以硬裝進去，要玩的人也可以參考一下 XD

這樣可以把 14.04 機器換一換了。(先前清點時本來以為已經是 16.04，做一些操作時才發現是 14.04...)

CA/Browser Forum 上的會議記錄：關於密碼與 2FA 的強制要求

CA/Browser Forum 會定時將會議記錄與最後的結論公開放在網站上，有時候有些資訊還蠻有趣的。像是前幾天在「Ballot 221 - Two-Factor Authentication and Password Improvements - CAB Forum」這邊看到 CA/Browser Forum 的成員對密碼與 2FA 提出了修正提案，其中瀏覽器端只有 Microsoft 參與投票，但是被否決了...

不知道否決的原因，但是大概可以猜到幾個點。

第一個是提案提到了 NSA 的 NIST 800-63B Appendix A，這個單位不太受歡迎啊...

第二個則是「For accounts that are accessible only within Secure Zones or High Security Zones, require that passwords have at least twelve (12) characters;」這段強迫使用密碼，而現在有比密碼更安全的方案存在 (以 public key cryptography 為認證基礎的方案)，像是早期的 U2F 以及今年定案的 WebAuthn。

應該是這些原因吧...

SSL Certificate 的認證方式限縮

在「Ballot 218 - Remove validation methods 1 and 5 - CAB Forum」看到「Ballot 218: Remove validation methods #1 and #5」這則議案以 78% 的同意票通過，限縮 SSL Certificate 的認證方式。眼睛瞄到中華電信投下反對票：

14 Yes votes: CFCA, Cisco, Comodo CA, D-TRUST, DigiCert, GDCA, GlobalSign, GoDaddy, Izenpe, Let’s Encrypt, Logius PKIoverheid, SSL.com, TrustCor, Trustwave

4 No votes: Buypass, Chunghwa Telecom, Entrust Datacard, SwissSign

4 Abstain: Actalis, Disig, HARICA, OATI

78% of voting CAs voted in favor

找了一下在 BR (Baseline Requirements) 的 3.2.2.4.1 與 3.2.2.4.5，其中前者是透過註冊商認證：

3.2.2.4.1 Validating the Applicant as a Domain Contact

Confirming the Applicant's control over the FQDN by validating the Applicant is the Domain Contact directly with the Domain Name Registrar.

後者是透過文件認證：

3.2.2.4.5 Domain Authorization Document

Confirming the Applicant's control over the FQDN by relying upon the attestation to the authority of the Applicant to request a Certificate contained in a Domain Authorization Document.

在想投下反對的原因，會不會是因為中華自己的 domain 應該都是透過後者方式發的？透過內部公文系統...

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.

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.

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

未來 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.

CA/Browser Forum 在三月底的會議記錄

在 CA/Browser Forum 三月底的會議記錄裡看到了關於 wildcard ssl certificate 的一些討論，還蠻有趣的：「2016-03-31 Minutes」。

主要是第五條的記錄，在討論更廣泛的 wildcard 用法。首先是 Microsoft 對 ww*.example.com 這種 domain 的認定：

Rick said there was a Microsoft tech note that allows ww*.example.com. Jody confirmed the platform supports it.

但有爭論，而且目前看起來暫時沒有打算要實作：

Rick suggested the BRs be updated to include that. Ryan said that is not a good thing as there are multiple specs that treat this differently and historical context which would make it hard for Google to support such a ballot. Kirk asked why Peter put this in the ballot. He responded that this was raised in the past where people found a discrepancy in relation to other docs. However, given there was not consensus, he would remove from the proposed ballot. Ryan said there is a need for clarification because CAs seem to be interpreting this differently. Peter said he would create a new definition called “wildcard domain name” with an exact definition to avoid confusion and add clarity. Rick said that ideally Microsoft should remove that functionality and update the tech notes. Jody said he would need to consult with his expert on this. Peter said the goal of this ballot was to make it a “consensus” ballot and would remove anything controversial.

看起來還沒有完全定下來，之後的會議記錄可以再看看進展。這對安全性也頗有幫助，舉例來說，我就可以針對不同的服務發不同的 wildcard ssl certificate，像是 test-*.example.com 這樣，而不用另外再建立機制避免 private key 的外流。