9

DST Root CA X3 將在今天 22:01:15 過期

 2 years ago
source link: https://blog.gslin.org/archives/2021/09/30/10354/dst-root-ca-x3-%e5%b0%87%e5%9c%a8%e4%bb%8a%e5%a4%a9-220115-%e9%81%8e%e6%9c%9f/
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.

先前提到 Let's Encrypt 發出的憑證在 9/30 會產生問題，主因是 IdenTrust 的 DST Root CA X3 會在 9/30 過期，交叉簽名加上 OpenSSL 1.0.2 的判斷條件太嚴格導致的：「OpenSSL 1.0.2 與 Let's Encrypt 在這個月月底的相容性問題」。

本來以為是 UTC 的 2021/09/30 23:59:59 之類的時間，結果因為要面對這個問題，需要確認正確的時間，結果發現不是 UTC 的 2021/09/30 23:59:59，而是一個奇怪的時間：

Validity
    Not Before: Sep 30 21:12:19 2000 GMT
    Not After : Sep 30 14:01:15 2021 GMT

所以是 2021/09/30 22:01:15 (台灣時間) 會過期，今天晚上可以看一下情況...

Related

Trac 1.2 的 Due Date...

在先前的文章提到了把自己在用的事件管理系統 Trac 從 1.0 升級到 1.2，然後 Due Date 的設計改變了：「Trac 1.1 增加的 time 欄位，以及 Due Date 資料的轉移」、「總算把手上的 Trac 1.0 升級到 1.2 了...」。 Trac 1.2 的資料型態是在底層存 unix timestamp 的變形 (乘以 1000000，然後前端補上 0 存成文字)，這幾天用下來才發現一些以前沒遇到的問題。 一開始轉到 Trac 1.2 是設成 date，但意外的發現 (因為伺服器時間不是 UTC)，不同時區的使用者在更新 ticket 時，系統會判定 Due Date 有變動而產生變更記錄，想了一下就改用 datetime 來處理這個問題。 用了 datetime 一陣子後，才發現先前的公司遇到的情境中，時區差異都很小，所以不會有 Due Date…

February 27, 2018

In "Computer"

APT 不使用 HTTPS 的說明

居然有個獨立的網站在說明：「Why does APT not use HTTPS?」。主要是 HTTPS 沒有增加太多保護，但會使得維護的複雜度變高很多。 首先是被竄改的問題，APT 本身就有簽名機制 (參考「SecureApt」)，即使 mirror site 被打下來也無法成功竄改內容，反而比起單純的 HTTPS 保護還好。 而對於隱私問題，由於內容是可以公開取得的，這代表可以看封包的大小與流動順序猜測是哪些 package 被下載 (也就是類似「利用 Side-channel 資訊判斷被 HTTPS 保護的 Netflix 影片資訊」這篇提到的方法)，加上 APT 這邊還多了時間性的資訊 最近被更新的軟體被下載的機率比較高)，所以隱私的保護上其實有限。 而針對攻擊者刻意提供舊版的問題 (某種形式的 replay attack)，APT 降低風險的解法是把時間簽進去，當用戶端發現太久沒更新時，就當作過期失效而提出警告。 就以上來看，把所有的 APT 伺服器都加上 HTTPS 的工程太浩大，而得到的效益太小。所以願意提供 HTTPS 的站台就提供，但主要的保護還是從本來的 SecureApt 機制上提供。

January 23, 2019

In "Computer"


report

Recommend

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK