幹壞事是進步最大的原動力
在「Another free CA as an alternative to Let's Encrypt (scotthelme.co.uk)」這邊引用的文章本來在討論又多了一家免費的 SSL certificate 可以用，但結果討論的主力都在講除了 Certbot 外還有什麼比較好用...
大家之所以厭惡 Certbot，先不講他需要依賴一堆 Python 的套件包，最主要的問題在於現在 Certbot 官方建議的指引裡面都要求你裝 Snap，而 Snap 這東西超級吃資源...
既然是資源問題，裡面可以看到 Dehydrated 又被拿出來推薦了，另外也有提到 acme.sh，不過我個人不太愛 acme.sh，主要是預設值跑去用 ZeroSSL 的 CA。
這種單檔就可以跑的很適合包進像是 Ansible 這類的管理工具，至少目前用起來沒什麼大問題...
在「IEEE P1735 Encryption Is Broken—Flaws Allow Intellectual Property Theft」這邊看到 US-CERT 發表的「IEEE P1735 implementations may have weak cryptographic protections」，裡面提到的主要漏洞：
The methods are flawed and, in the most egregious cases, enable attack vectors that allow recovery of the entire underlying plaintext IP.
主要應該是第一包：
CVE-2017-13091: improperly specified padding in CBC mode allows use of an EDA tool as a decryption oracle.
又是 CBC 的 padding oracle attack 啊... 看起來是標準沒有強制定義好造成的？
The main vulnerability (CVE-2017-13091) resides in the IEEE P1735 standard's use of AES-CBC mode.
Since the standard makes no recommendation for any specific padding scheme, the developers often choose the wrong scheme, making it possible for attackers to use a well-known classic padding-oracle attack (POA) technique to decrypt the system-on-chip blueprints without knowledge of the key.
去年 Cloudflare 寫的「Padding oracles and the decline of CBC-mode cipher suites」這邊有提到 padding oracle attack 的方式，比較一般性的解法是避開要自己決定 Encrypt-then-MAC (IPsec；也是數學上證明安全性) 或 Encrypt-and-MAC (SSH) 或是 MAC-then-Encrypt (SSL)，而是用 AEAD 類的加密元件直接躲開 padding oracle attack 的某些必要條件 (像是 AES-GCM 或是 ChaCha20-Poly1305)。
不過這也是這幾年大家才了解這樣做的重要性，當年在訂規格的時候都比較沒在在意這些...
在 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 而做的，但微軟已經不提供驅動程式的數位簽章了，所以就只好這樣搞...