新的 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 的一半,應該是還不錯...

OpenSSL 的版號規則打算要改變...

在「The Holy Hand Grenade of Antioch」這邊看到 OpenSSL 的版號規則要改變了,變得比較接近 Semantic Version 的架構。

本來是 MAJOR.MINOR.FIX[PATCH] 這樣的形式,之後打算改成 MAJOR.MINOR.PATCH,不過現有的 1.1.1 與 1.0.2 會先維持原來的規則:

The current 1.1.1 and 1.0.2 versioning scheme will remain unchanged.

另外下一個大版本會是 3.0.0,而不是 2.0.0 (被其他計畫用掉了,所以為了避免混淆中獎,就直接跳過去了):

The current development version (master branch) will be identified as version 3.0.0. The OpenSSL FIPS module currently under development will also follow this versioning scheme. We are skipping the 2.0.0 major version because the previous OpenSSL FIPS module has already used this number.

另外授權也變成 Apache License 2.0 了:

OpenSSL version 3.0.0 will be the first version that we release under the Apache License 2.0. We will not be applying the Apache License to earlier releases of OpenSSL.

我記得 Apache License 2.0 跟 GPLv2 是不相容的... 本來使用 OpenSSL 的軟體為了 OpenSSL 的授權而加的例外條款,這次又要再修嗎...?

升級 nginx 後關不掉的 TLSv1.3...

我 blog 的 nginx 是用 ondrej 的版本,最近他把套件加上 TLSv1.3 的支援 (主要是 OpenSSL 1.1.1 出了),但不知道是哪個環節出問題了,現在 TLSv1.3 關不掉 XDDD

而且包起來的 OpenSSL 很奇怪,不管什麼情況都會把 TLSv1.3 的三個 cipher 放進來:

gslin@colo-vultr-1 [~] [17:38] openssl ciphers -v 'xxx'     
TLS_AES_256_GCM_SHA384  TLSv1.3 Kx=any      Au=any  Enc=AESGCM(256) Mac=AEAD
TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any      Au=any  Enc=CHACHA20/POLY1305(256) Mac=AEAD
TLS_AES_128_GCM_SHA256  TLSv1.3 Kx=any      Au=any  Enc=AESGCM(128) Mac=AEAD

然後 nginx 只設 TLSv1.2 的情況下,用 SSL Labs 的網站掃還是會有 TLSv1.3:

ssl_protocols TLSv1.2;

然後還有遇到改了 cipher 後,跑 pkill -1 nginx 之後 client 端會回報沒有任何 cipher 可以用,直到跑了 service nginx restart 後就好的情況...

建議想用的人再等一下...

讓 OpenLDAP 伺服器使用 Let's Encrypt 簽的憑證

OpenLDAP 伺服器可以吃 Let's Encrypt 發的憑證以提供 LDAPS 服務,只是 SSL 設定方法跟其他軟體不太一樣,第一次設會花不少時間...

這邊的檔案目錄是以 Dehydrated 申請 Let's Encrypt 的憑證來設定。官方推薦的 Certbot 應該也有類似的檔案:

TLSCACertificateFile /etc/dehydrated/certs/x.y.z/chain.pem
TLSCertificateFile /etc/dehydrated/certs/x.y.z/cert.pem
TLSCertificateKeyFile /etc/dehydrated/certs/x.y.z/privkey.pem

這樣不管 Let's Encrypt 拿 Let’s Encrypt Authority X3 (目前的主力憑證) 還是 Let’s Encrypt Authority X4 (備用的憑證) 簽,OpenLDAP 這邊才會串出正確的 certficiate chain。(用 OpenSSLs_client -connect x.y.z:636 與 ldapsearch 測過)

要找問題的話,ldapsearch 有 -v (verbose) 與 -d 9 (debug) 可以看連線過程的細節,拿著錯誤訊息去餵搜尋引擎會有不少幫助...

在找資料時發現網路上有不少文件教大家直接在 client 端的 /etc/ldap/ldap.conf 修改 TLS_REQCERT 的值,從預設的 demand 改成 allow (或是 never),但這樣將強制檢查的條件改弱,安全性反而降低了。比較好的方式還是修正 server 端的錯誤設定。

OpenSSL 1.1.1 出版,TLSv1.3!

OpenSSL 1.1.1 推出了:「OpenSSL 1.1.1 Is Released」。先前在「OpenSSL 1.1.1 將支援 TLS 1.3」這邊有提到 OpenSSL 當時就計畫要等 TLSv1.3 出了才會釋出 1.1.1,結果這一等就是一年多...

這樣後續應該會有人包 PPA 出來讓大家用了...

RFC 8446:TLS 1.3

看到 RFC 8446 (The Transport Layer Security (TLS) Protocol Version 1.3) 正式推出了,也就是 TLS 1.3 正式成為 IETF 的標準 (Standards Track)。

Cloudflare 寫了一篇文章「A Detailed Look at RFC 8446 (a.k.a. TLS 1.3)」描述了 TLS 1.3 的特點,有興趣的人可以看一看,尤其是 1-RTT 的部份對效能幫助很大 (0-RTT 因為 replay attack 問題,我應該暫時都不會考慮,要等到有一個合理的防禦模型出來)。

另外一個是 OpenSSL 目前最新版是 1.1.0h,當初就決定要等 TLS 1.3 正式成為標準才會出 1.1.1 (參考「OpenSSL 1.1.1 將支援 TLS 1.3」,這也熬了一年啊... 支援後會就有很多軟體可以直接套用了,可以來期待了。