過去，證書經常會過期，因為必須手動更新。 人們只是忘記了這樣做。 隨著 Let's Encrypt 和自動更新程式的出現，這個問題似乎應該要解決。 但最近 表明它實際上仍然具有相關性。 不幸的是，證書仍然會過期。
如果您錯過了這個故事，4 年 2019 月 XNUMX 日午夜，幾乎所有 Firefox 擴充功能突然停止工作。
事實證明，這次大規模失敗的原因是 Mozilla ，用於簽署擴充。 因此，它們被標記為“無效”並且未經驗證（）。 在論壇上，作為解決方法，建議停用擴展簽名驗證 about：config中 或更改系統時鐘。
Mozilla很快就發布了Firefox 66.0.4補丁，解決了憑證無效的問題，所有擴充功能恢復正常。 開發人員建議安裝它並 沒有繞過簽名驗證的解決方法，因為它們可能與補丁衝突。
然而，這個故事再次表明證書過期仍然是當今的一個緊迫問題。
在這方面，看看協議開發人員如何處理這項任務的一種相當原始的方式是很有趣的 。 他們的解決方案可以分為兩個部分。 首先，這些是短期證書。 其次，警告用戶長期到期的情況。
DNSCrypt
DNSCrypt 是一種 DNS 流量加密協定。 它可以保護 DNS 通訊免受攔截和 MiTM，還允許您繞過 DNS 查詢等級的封鎖。
該協定將客戶端和伺服器之間的 DNS 流量封裝在加密結構中，透過 UDP 和 TCP 傳輸協定運作。 要使用它，客戶端和 DNS 解析器都必須支援 DNSCrypt。 例如，自 2016 年 152 月以來，它已在其 DNS 伺服器和 Yandex 瀏覽器中啟用。 其他幾家提供者也宣布提供支持，包括 Google 和 Cloudflare。 不幸的是，數量並不多（官方網站上列出了 XNUMX 個公共 DNS 伺服器）。 但節目 可以在 Linux、Windows 和 MacOS 用戶端上手動安裝。 還有 .
DNSCrypt 是如何運作的？ 簡而言之，客戶端獲取所選提供者的公鑰並使用它來驗證其憑證。 會話的短期公鑰和密碼套件標識符已經存在。 鼓勵客戶端為每個請求產生新金鑰，並鼓勵伺服器更改金鑰 每24小時。 交換金鑰時，使用 X25519 演算法進行簽章 - EdDSA，進行區塊加密 - XSalsa20-Poly1305 或 XChaCha20-Poly1305。
協議開發者之一 Frank Denis 每24小時自動更換一次，解決了證書過期的問題。 原則上，dnscrypt-proxy 參考用戶端接受任何有效期的證書，但如果證書有效期超過 24 小時，則會發出警告「該伺服器的 dnscrypt-proxy 金鑰週期太長」。 同時發布了一個 Docker 映像，其中實作了金鑰（和憑證）的快速變更。
首先，它對於安全性非常有用：如果伺服器遭到破壞或金鑰洩露，則昨天的流量將無法解密。 關鍵已經改變了。 這可能會為 Yarovaya 法的實施帶來問題，該法迫使提供者儲存所有流量，包括加密流量。 這意味著以後如有必要，可以透過從網站請求金鑰來解密它。 但在這種情況下，該網站根本無法提供它，因為它使用短期金鑰，刪除舊金鑰。
但最重要的是，丹尼斯寫道，短期金鑰迫使伺服器從第一天起就設定自動化。 如果伺服器連接到網路且密鑰更改腳本未配置或不起作用，則會立即偵測到。
當自動化每隔幾年更改一次金鑰時，它就不再可靠，人們可能會忘記憑證過期的情況。 如果您每天更改密鑰，則會立即偵測到。
同時，如果自動化配置正常，那麼金鑰變更的頻率並不重要：每年、每季或每天三次。 弗蘭克·丹尼斯 (Frank Denis) 寫道，如果一切都能正常工作超過 24 小時，那麼它將永遠有效。 據他介紹，第二版協議中每日密鑰輪換的建議，以及實現它的現成的 Docker 映像，有效減少了證書過期的伺服器數量，同時提高了安全性。
然而，由於某些技術原因，一些提供者仍然決定將證書有效期設定為超過 24 小時。 這個問題基本上透過dnscrypt-proxy 中的幾行程式碼得到了解決：使用者在憑證過期前30 天收到一條訊息警告，在過期前7 天收到另一條具有更高嚴重性等級的訊息，如果憑證還有剩餘，則會收到一則嚴重訊息有效期限：24小時以內。 這僅適用於最初有效期較長的憑證。
這些訊息使用戶有機會在為時已晚之前通知 DNS 營運商證書即將到期。
也許如果所有 Firefox 用戶都收到這樣的訊息，那麼有人可能會通知開發人員，他們不會允許憑證過期。 「我不記得公共 DNS 伺服器清單中的任何 DNSCrypt 伺服器在過去兩三年內其憑證已過期，」Frank Denis 寫道。 無論如何，最好先警告用戶，而不是在沒有警告的情況下停用擴充功能。
來源： www.habr.com