前幾天綠界 *.ecpay.com.tw 憑證爆掉的事情
source link: https://blog.gslin.org/archives/2021/10/20/10380/%e5%89%8d%e5%b9%be%e5%a4%a9%e7%b6%a0%e7%95%8c-ecpay-com-tw-%e6%86%91%e8%ad%89%e7%88%86%e6%8e%89%e7%9a%84%e4%ba%8b%e6%83%85/
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
前幾天綠界 *.ecpay.com.tw 憑證爆掉的事情
前幾天社群蠻熱鬧在討論綠界的 *.ecpay.com.tw 憑證被上游 Sectigo 給 revoke，而導致 login.ecpay.com.tw 無法連線的問題 (ba:d3:26:14:db:53:1b:56:49:8d:de:d5:0c:68:b9 這張，另外參考點了 OCSP 檢查的 https://crt.sh/?id=3608838685&opt=ocsp 結果)，可以看 domain 知道這個網域比較偏使用者的用途 (而非 API 類)，會買 EV 主要就是要用在瀏覽器上，所以這邊主要就討論瀏覽器受到影響的部份...
因為 Sectigo 是透過 CRL 與 OCSP 兩個機制把 revoke 資訊送出來，所以各家瀏覽器的處理方式會不太一樣...
首先是市占率最高的 Chrome，因為有自家的機制在處理 revoke，不走 CRL 或是 OCSP，所以大多數的使用者應該都沒有受到影響 (不確定...)，但 Firefox 與 Safari 都吃 OCSP，所以都會炸掉。
這次有看到兩個社群有一些討論，一個是「https://www.facebook.com/groups/rayforum/posts/4417812681632189/」，另外一個是「https://www.facebook.com/groups/616369245163622/posts/2497356027064925/」這邊。
Vincent Liang 有貼了 Sectigo 送 revoke 的原因，在 Mozilla 的 Bugzilla 上面有 Sectigo 的主動通報：「Sectigo: Subject field with unvalidated information included in certificates」，看起來是因為在內部 code review 的時候發現 postOfficeBox (以台灣來說就是郵遞區號郵政信箱) 這個欄位的問題：
Though the postOfficeBox field is permissible for inclusion in OV certificates, any field containing unvalidated information is not permissible. Furthermore, the EV Guidelines prohibit this field at all for EV certificates.
也就是說，在 OV 憑證內可以列入 postOfficeBox，但需要確認後才能列進去；而 EV 憑證則是不允許列 postOfficeBox 的；因為這兩個原因，這些憑證都要 revoke，另外也因為 Baseline Requirements 與 EV SSL Certificate Gudidelines 的要求而需要主動通報。
Sectigo 有列出 453 個受到影響的憑證，不過發文者 Lorex L. Yang 有注意到綠界的這個憑證沒有被列在這 453 個受到影響的憑證內，但是後來也有被 revoke 掉...
所以現在問題就來了，會不會 Sectigo 根本沒通知綠界要換憑證？另外 Sectigo 的通報內容不實也是一個大問題，因為沒有人在 Bugzilla 上提到，所以我就在上面回個 comment 把這個議題拋出來，讓 Mozilla 的人知道後繼續查下去...
當然綠界花了十八個小時解決也是個問題，不過那個就不是我們能管到的了...
Related
Firefox 支援 OCSP Must-Staple
Firefox 宣佈支援 OCSP Must-Staple：「Improving Revocation: OCSP Must-Staple and Short-lived Certificates」。 先前的 SSL certificate 的 revoke 技術目前是透過 CRL 與 OCSP 兩個技術在支撐，前者是列出所有被 revoke 的清單，後者則是瀏覽器主動去指定的 server 確認這個 SSL certificate 是否有效。但這兩個方法都有嚴重的問題。 CRL 的問題是 revoke 清單會愈來愈多。這完全沒辦法 scale。 OCSP 的問題有幾個，一個是熱門網站的 SSL certificate 會讓 OCSP server 的負擔非常重 (不過還是有些辦法打散)。第二個問題是 OCSP server 會知道哪些 IP 造訪了哪些網站，使得隱私權受到嚴重侵害。第三個問題則是 client 需要再連線確認花掉很多時間，而且失敗機率超高： However, these…
November 25, 2015In "Browser"
Mozilla 對 WoSign 事件的決策 (草稿階段)
在「Mozilla 在考慮移除 WoSign 的 CA Root」這邊提到的事情，隨著時間的發展，大家發現事情愈來愈誇張。 在兩個小時前 Mozilla 的 Gervase Markham 提出了對 WoSign + StartCom 處置的草稿：「WoSign and StartCom」，草稿在 Google Docs 上的「WoSign and StartCom」這邊可以看到。另外 Mozilla 在 wiki 上「CA:WoSign Issues」將 WoSign + StartCom 的事情都整理了出來，也是重要的資料。 文章很長，先講結論：目前 Mozilla 打算把 WoSign 與 StartCom 所簽出的 certificate 都照當年 CNNIC 的方式拔掉。 從頭說明，事情發生於八月底的時候 Google 通知了 Mozilla 一連串 WoSign 出包卻沒有主動通報的事件，當時知道的大約有三或四件。而在…
September 27, 2016In "Browser"
OCSP 是如何影響 HTTPS 的效率...
Netcraft 從 2012 年 11 月開始偵測 OCSP 的 availability，然後發現各家 OCSP 的穩定性都不太好：「Certificate revocation and the performance of OCSP」。 OCSP 是 Online Certificate Status Protocol 的縮寫，當 HTTPS 連線建立中，client 可以透過 OCSP 詢問這份 certificate 是否有效。這是 PKI 架構下的事後補救機制，因為已經發出去的簽名是無法被收回的，只好靠連線時再查詢。 另外一個機制比較舊，叫 CRL (Certificate Revocation List)，則是屬於清單類的機制，更新速度比 OCSP 慢。 目前是以 OCSP 為主，而舊的平台 (就是 XP 上的 IE) 則只支援 CRL。 可以看到…
April 17, 2013In "Computer"
Author Gea-Suan LinPosted on October 20, 2021October 20, 2021Categories Computer, Murmuring, Network, Security, Service, WWWTags authority, bugzilla, ca, certificate, crl, ecpay, ev, green, https, login, mozilla, ocsp, ov, postofficebox, sectigo, security, ssl, tls, world Leave a Reply Cancel reply
Your email address will not be published. Required fields are marked *
Comment
Name *
Email *
Website
Notify me of follow-up comments by email.
Notify me of new posts by email.
Post navigation
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK