如果把 OpenSSL 包裝成 GUI 版本

Hacker News Daily 上看到這則,蠻有趣的嘗試,如果幫 OpenSSL 包裝成 GUI 版本的話,可能會長的樣子:「If OpenSSL were a GUI」,而 Hacker News 上對應的討論在「If OpenSSL were a GUI (smallstep.com)」這邊可以看到。

要注意的是這是 mock 出來的圖,而不是真的有人這樣幹了一個版本出來。主要是在帶出 OpenSSL 這個工具極度複雜的問題,另外也因此帶出 GUI application 的取捨問題,在 Hacker News 上的討論都有人提出來。

不過讓我吸引的點反而是 mock UI 的選擇上,看起來作者選了 Platinum 風格 (Mac OS 8 & Mac OS 9),在維基百科的「Appearance Manager」這個頁面有提到:

The default look and feel of the Appearance Manager in Mac OS 8 and 9 is Platinum design language, which was intended to be the primary GUI for Copland.

是個讓人懷念的風格,而且意外的看起來反而讓 GUI 柔和不少,而且其實就功能性來說還蠻不錯的?

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

先前提到 Let's Encrypt 發出的憑證在 9/30 會產生問題,主因是 IdenTrustDST 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 (台灣時間) 會過期,今天晚上可以看一下情況...

OpenSSL 1.0.2 與 Let's Encrypt 在這個月月底的相容性問題

看到 OpenSSL 的官方居然特地寫一篇與 Let's Encrypt 的相容性問題:「Old Let’s Encrypt Root Certificate Expiration and OpenSSL 1.0.2」。

這邊提到的 OpenSSL 1.0.2 很舊了 (在 Ubuntu 16.04 內是 1.0.2g),理論上大多數的機器應該不太會遇到這個問題。

問題出自 Let's Encrypt 舊的 DST Root CA X3 將在這個月月底過期,這在 Let's Encrypt 的「DST Root CA X3 Expiration (September 2021)」這邊也有提到。

The currently recommended certificate chain as presented to Let’s Encrypt ACME clients when new certificates are issued contains an intermediate certificate (ISRG Root X1) that is signed by an old DST Root CA X3 certificate that expires on 2021-09-30.

理想上只有要任何一條 trust chain 成立,就應該會把這個憑證認為是合法的憑證,但這在 OpenSSL 1.0.2 (以及之前的版本) 不是這樣設計。

舊版的設計是只要有任何一條過期的憑證,就會把憑證認為過期而失效:

Unfortunately this does not apply to OpenSSL 1.0.2 which always prefers the untrusted chain and if that chain contains a path that leads to an expired trusted root certificate (DST Root CA X3), it will be selected for the certificate verification and the expiration will be reported.

OpenSSL 官方給了三個 workaround 可以做,另外我還有想到一個惡搞方式,是可以用其他家免費的憑證... 不過也是得測看看在 OpenSSL 1.0.2 下會不會動。

OpenSSL 3.0 釋出,使用 Apache License 2.0

OpenSSL 3.0 推出了,這是轉換到 Apache License 2.0 後的第一個正式版本:「OpenSSL 3.0 Has Been Released!」。

中間跳過 2.0 的原因在維基百科上也有提到,因為之前被 OpenSSL FIPS module 用掉了:

The major version 2.0.0 was skipped due to its previous use in the OpenSSL FIPS module.

雖然 3.0.0 看起來是大版本,不過主要的功能都在 OpenSSL 1.1.1 先加進去了,沒有什麼特別的理由現在就要升級到 3.0.0...

Squid + GnuTLS 不支援 Intermediate Certificate 的問題

先前在「架設 Proxy over TLS」這邊提到了我用 Squid 架 Proxy over TLS 的服務起來用,本來在家裡跑得好好的,但到了公司發現卻不能用,追蹤後發現是目前 Ubuntu 裡面包的 Squid + GnuTLS 沒有辦法支援 intermediate certificate 的問題,而且有人問過了:「[squid-users] HTTPS_PORT AND SSL CERT」。

這邊先講測試的方法,然後後面再講解法。

測試的方式可以用 openssl s_client -connect hostname:port 測,正常的情況會可以看到兩層。

在這邊的例子裡,R3 簽了 home.gslin.orgDST Root CA X3 簽了 R3,而 DST Root CA X3 則在 root certificate 名單中:

$ openssl s_client -connect home.gslin.org:443
depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = home.gslin.org
verify return:1
CONNECTED(00000003)
---
Certificate chain
 0 s:CN = home.gslin.org
   i:C = US, O = Let's Encrypt, CN = R3
 1 s:C = US, O = Let's Encrypt, CN = R3
   i:O = Digital Signature Trust Co., CN = DST Root CA X3
---

如果沒有送出 Intermediate Certificate 的話就會導致信任鏈無法建立,像是我故意設計的 nointermediate.gslin.com 這樣,R3 簽了 nointermediate.gslin.com,但 R3 並沒有在 root certificate 的名單中:

$ openssl s_client -connect nointermediate.gslin.com:443
CONNECTED(00000003)
depth=0 CN = nointermediate.gslin.com
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 CN = nointermediate.gslin.com
verify error:num=21:unable to verify the first certificate
verify return:1
depth=0 CN = nointermediate.gslin.com
verify return:1
---
Certificate chain
 0 s:CN = nointermediate.gslin.com
   i:C = US, O = Let's Encrypt, CN = R3                                
---

而想到的解法就是重新包一份 Squid 出來用,把本來的 --with-gnutls 改成 --with-openssl

這邊會先裝 Build-Depends 裡面指定的東西,然後加裝 libssl-dev,接著換掉 --with-gnutls 後編譯,最後產生 .deb

sudo apt install -y ed libltdl-dev pkg-config build-essential cdbs debhelper dpkg-dev lsb-release dh-apparmor libcppunit-dev libcap2-dev libdb-dev libecap3-dev libexpat1-dev libgnutls28-dev libkrb5-dev comerr-dev libldap2-dev libnetfilter-conntrack-dev libpam0g-dev libsasl2-dev libxml2-dev nettle-dev libssl-dev
apt-get source squid
cd squid/squid-4.10
sed -i -e 's/--with-gnutls/--with-openssl/' debian/rules
cd ..
dpkg-buildpackage -rfakeroot -uc -b

編好的 .deb 就可以拿到其他機器上裝了,然後就可以吐出 intermediate certificate 了...

新的 TLS 攻擊:Raccoon Attack

這次看到的是針對 TLS 實做上的問題產生的 Raccoon Attack,反正先取個名字就對了,原圖有點大張,設個 medium size 好了 XDDD:

Why is the attack called "Raccoon"?
Raccoon is not an acronym. Raccoons are just cute animals, and it is well past time that an attack will be named after them :)

先講影響的產品,首先是經常中槍的 F5,這次連 timing measurement 都不需要太準確就可以打穿:

In particular, several F5 products allow executing a special version of the attack, without the need for precise timing measurements.

OpenSSL 的部份因為從 1.0.2f 之後因為其他的 security issue 所以改善了實做方式,就不會受到這次的攻擊手法影響。

剛剛翻了一下 Ubuntu 上的的資料,看起來 16.04 (xenial) 上的 OpenSSL 就已經是 1.0.2g 了,所以目前只要是有在 Ubuntu 支援的版本應該都不受影響:

OpenSSL assigned the issue CVE-2020-1968. OpenSSL does use fresh DH keys per default since version 1.0.2f (which made SSL_OP_SINGLE_DH_USE default as a response to CVE-2016-0701).

Firefox 直接拔了 DH 與 DHE 相關的 cipher suite,反正在這次攻擊手法出來前本來就已經計畫要拔掉:

Mozilla assigned the issue CVE-2020-12413. It has been solved by disabling DH and DHE cipher suites in Firefox (which was already planned before the Raccoon disclosure).

微軟的部份則是推更新出來:

Microsoft assigned the issue CVE-2020-1596. Please refer to the Microsoft Security Response Center portal.

回到攻擊手法,這次的問題是因為 DH 相關的實做造成的問題。

TLS 要求去掉 premaster secret 裡開頭的 0,造成會因為開頭的 0 數量不同而實做上就不會是 constant time,所以有了一些 side channel information 可以用:

Our Raccoon attack exploits a TLS specification side channel; TLS 1.2 (and all previous versions) prescribes that all leading zero bytes in the premaster secret are stripped before used in further computations. Since the resulting premaster secret is used as an input into the key derivation function, which is based on hash functions with different timing profiles, precise timing measurements may enable an attacker to construct an oracle from a TLS server.

然後一層一層堆,能夠知道 premaster secret 開頭是不是 0 之後,接下來因為 server side 會重複使用同一組 premaster secret,所以可以當作一個 oracle,試著去計算出更後面的位數:

This oracle tells the attacker whether a computed premaster secret starts with zero or not. For example, the attacker could eavesdrop ga sent by the client, resend it to the server, and determine whether the resulting premaster secret starts with zero or not.

Learning one byte from a premaster secret would not help the attacker much. However, here the attack gets interesting. Imagine the attacker intercepted a ClientKeyExchange message containing the value ga. The attacker can now construct values related to ga and send them to the server in distinct TLS handshakes. More concretely, the attacker constructs values gri*ga, which lead to premaster secrets gri*b*gab. Based on the server timing behavior, the attacker can find values leading to premaster secrets starting with zero. In the end, this helps the attacker to construct a set of equations and use a solver for the Hidden Number Problem (HNP) to compute the original premaster secret established between the client and the server.

所以針對這個攻擊手法的解法就是用「新鮮的」premaster secret (像是完全不重複使用),然後保留開頭的 0,不需要去掉。而 TLS 1.3 在定義的時候把這兩件事情都做了,所以不會受到影響:

Is TLS 1.3 also affected?
No. In TLS 1.3, the leading zero bytes are preserved for DHE cipher suites (as well as for ECDHE ones) and keys should not be reused.

另外在這邊提到的 Hidden Number Problem (HNP) 也是個不熟悉的詞彙,網站上有提到論文,也就是「Hardness of computing the most significant bits of secret keys in Diffie-Hellman and related schemes」這篇:

Given an oracle Oα(x) that on input x computes the k most significant bits of (α * gx mod p) , find α mod p.

是個離散對數類的問題,之後有空再來翻一翻好了。

處理很久前用 OpenSSL 加密的備份資料

因為想要翻一些舊的文章 (小說),想把以前 BBS 的備份拉出來看看裡面有沒有,結果發現 OpenSSL 解半天都解不開,還跑去玩了 bruteforce-salted-openssl 這個專案:

Try to find the password of a file that was encrypted with the 'openssl' command.

後來也是因為這個專案提醒,發現 openssl enc 指令在 OpenSSL 1.0.x (以及之前) 預設是用 MD5 當 digest algorithm,而 1.1.x 換成了 SHA-256,而我的備份資料應該是在 0.9.x 的年代就生出來了...

指定 -md md5 後就正常解出來了:

openssl enc -bf -d -md md5 -in ooxx.tar.gz.bf -out ooxx.tar.gz

另外一個收穫是 CPU 溫度降了不少:因為跑 bruteforce-salted-openssl 的時候 CPU 到 80 度,感覺撞到安全值卡在 4.0Ghz,所以就把 CPU 電壓降了 0.1V,看起來溫度低了不少 (少了五度),但跑起來還是 4.0Ghz...

AWS ACM 支援 Private CA

AWS ACM 推出了 Private CA 服務:「How to host and manage an entire private certificate infrastructure in AWS」。

以前需要 Private CA 的話,會找個地方丟 Root CA 的 key,然後有權限的人可以連到那台機器上跑 OpenSSL 指令生出對應的 SSL certificate,現在 AWS 則是利用 HSM 架構提供服務:

主要是因為 HSM 的關係,安全性會比較好... 另外也因為是 AWS 服務的關係,上面可以看到相關的記錄,相較於以前的作法安全不少。

在 MacPorts 上裝 pyenv...

因為先前從 Homebrew 跳到 MacPorts 了,剛好有機會重新弄 pyenv,結果發現要解決的問題不少...

第一個遇到的是需要的 library 抓不到的問題,找了官方說明「Common build problems」後知道要自己加上一些環境變數讓 compiler 抓。

解決之後發現 pyenv 會自己編一個 openssl 版本給 Python 用,不會裝到系統內,但是又會因為 /usr/local/opt/ 寫不進去而失敗,所以給他一個可以寫入的目錄。

接下來是 zlib 的路徑也不在前面設定的目錄裡而抓不到,所以得想辦法再找出來塞到環境變數內... 也就是「Install failed, "zlib not available" on macOS Mojave #1219」這篇給的方法。

最後是這樣:

sudo mkdir /usr/local/opt; sudo chown "$(id -u):$(id -g)" /usr/local/opt
LDFLAGS="-L/usr/local/opt/openssl/lib" CPPFLAGS="-I/usr/local/opt/openssl/include" CFLAGS="-I/usr/local/opt/openssl/include -I$(xcrun --show-sdk-path)/usr/include" pyenv install 3.7.3

裝完後可以發現 /usr/local/opt/ 裡面沒有檔案 (但生了幾個空的目錄出來),但總算是裝起來了...

實際比較 Linode 的 Dedicated 主機與 AWS 的 c5.*

先前有提到 Linode 出了 Dedicated 主機:「Linode 推出 Dedicated CPU Instances」,現在找機會測試看看,拿了 Linode 的 Dedicated (4GB) 與 AWSc5.large 比較,同樣都是 2 vCPU 與 4GB RAM。

這邊用了 n-st/nenchOpenSSL 的 speed (包括了 aes、md5、rsa、sha1 與 sha256) 測試,我把結果都貼到這邊:「Linode (Dedicated 4GB) v.s. AWS (c5.large)」。

可以看到在 CPU 方面主要的差異是 Linode 用的是 AMD,而 AWS 用的是 Intel,所以就會有蠻多不同的數字表現...

如果仔細看 OpenSSL 的測試數據,可以看到不同演算法的差異還蠻大的,馬上可以想到的應該是硬體加速方式與 cache 架構差異造成的:

  • 在 cipher 類的測試我只測了 AES (目前的主流),小的 block (16/64/256 bytes) 時 AMD 會輸一些,但大的 block (1024/8192/16384 bytes) 反而會贏不少。
  • 在 hash 類的測試中,跑 MD5 時 Linode 則是輸一些,但 SHA1 反而是贏一些,然後 SHA256 時效能好到爆炸贏了一倍 XDDD
  • 在 public key 類的測試我測了 RSA,則是 Linode 輸的蠻慘的...

如果考慮到價位大約只有 AWS 的一半,應該是還不錯...