選擇 OpenSSL Cipher 時的參考資料

Qualys SSL Labs 在「User Agent Capabilities」有提供不少好用的資料,其中每個 client 點進去以後就可以知道支援哪些 cipher,像是「User Agent Capabilities: Android 2.3.7」這頁裡面可以看到只支援 SSLv3 以及 TLSv1,而支援的 cipher 大多都比較弱一點 (3DES 的 112bits 以及 RC4/AES 128bits 為主):

就用這些資訊去湊,設上去後再實際測試 :o

JPEG 用 AES-CBC 加密後變成 PNG,用 3DES-CBC 解密後變成 PDF...

直接練出一份 PoC 讓大家看:「a JPEG that becomes a PNG after AES encryption and a PDF after 3DES decryption」,這是原始檔:(這邊直接引用 Google Code 上的 image)

透過 AES-CBC 加密後會是這樣的圖片:

透過 3DES-CBC 解密後則是這樣的 PDF:

CloudFlare 停用 RC4 後的現象,以及後續...

今年一月的時候 CloudFlare 宣佈針對使用 TLS 1.1+ 的使用者停用 RC4:「Killing RC4 (softly)」。

而現在 (五月) 則直接從 cipher priority 上拔掉 RC4:「Killing RC4: The Long Goodbye」。

切換後的資料其實非常有趣:

可以看到本來用 RC4 的有兩塊,一塊是 ECDHE-RC4,一塊是 RSA-RC4。在 RC4 被拿掉後,就流竄到 ECDHE-AES-CBC 與 RSA-AES-CBC... (這兩個本來就可以預期)

但冒出 RSA-3DES 是怎樣 XDDD

Anyway,CloudFlare 在目前市場上算是很大的 provider,由他們出面率先拔掉 RC4 會對整個市場有正面的影響。接下來看看還有誰會動手?

ChaCha20-Poly1305 在 Android 上帶來的效能

Google 主推的 ChaCha20-Poly1305Android 上的 Chrome 可以看出顯著的效能差異:「Speeding up and strengthening HTTPS connections for Chrome on Android」。

在加密速度上與 AES-GCM 的差異:

AES-GCM 畢竟是標靶,被打爆本來就是預期中的事情,在 Google 大力推動下,應該是還蠻有機會成為主流...

不過隔壁棚好像還是沒什麼進展,不知道要等到何時:「Bug 917571 - Support ChaCha20+Poly1305 cipher suites」。

MySQL 5.7.4

在「The MySQL 5.7.4 Milestone Release is available」這篇可以看到 MySQL 5.7.4 的消息。除了 InnoDB 的改善外,可以看到對 AES 加密的功能 (AES Encryption Modes)。

不過...

Historically, and still used as defaults in 5.6 and 5.7, we are using a relatively small key size (128 bits, corresponding to “SECRET” according to NSA) and block mode (ECB, encrypting equal blocks with equal code blocks) to calculate the cipher.

居然是支援 ECB,這會不會驚爆我的眼球啊,我以為最少是 CTR...

ECB 代表相同內容的 block 就會被加密成相同的密文,這樣就有很多可以攻擊的方式了。而 CTR 至少可以抵抗這一點...

另外一個賣點是「InnoDB Spatial Indexes in 5.7.4 LAB release」,目前只支援二維資料:

Currently, InnoDB spatial index supports only two dimension data, but we do have plan to extend to multi-dimension. In addition, we are doing more performance tuning to make it more efficient.

R-tree 實做的,畢竟是個開始...

ChaCha20-Poly1305 將被移植到 OpenSSH 上...

Slashdot 上看到 ChaCha20-Poly1305 將被移植到 OpenSSH 上:「OpenSSH Has a New Cipher — Chacha20-poly1305 — from D.J. Bernstein」。

上個月 Google Chrome 決定在 32 版 (現在 31 版了) 要支援 ChaCha20-Poly1305 (參考「Google 對四個 Cipher 的分析... (以及 ChaCha20-Poly1305)」),這個月 OpenSSH 就打算要跟進了...

提案人 Damien Miller 在 blog 上提到為什麼他想將 ChaCha20-Poly1305 移植到 OpenSSH 上的原因 (「ChaCha20 and Poly1305 in OpenSSH」),主要是因為 AES-GCM 與 Encrypt-then-MAC 都必須傳輸 plaintext 的長度,這點讓人很不舒服。另外一個是 AES-GCM 的效能一直都是個議題。

ChaCha20-Poly1305 以 stream cipher 企圖同時解決這兩個問題,接下來就是看時間考驗了...

FreeBSD 對 OpenSSH 的安全性更新...

讓我意外的是,只有 FreeBSD 10.0-BETA (還沒出 RELEASE 的版本) 有問題,9.2-RELEASE 並不在內:「OpenSSH AES-GCM memory corruption vulnerability」。

本來 9.2 的機器有上 workaround 把 AES-GCM 強制拔掉,看起來可以 revert 回來了...

Google 對四個 Cipher 的分析... (以及 ChaCha20-Poly1305)

Google Online Security Blog 上對四種 cipher 的分析:「A roster of TLS cipher suites weaknesses」。

分別是 RC4、AES-CBC、AES-GCM、ChaCha20-Poly1305 四個 cipher。其中 RC4 與 AES-CBC 的問題都很多,而 AES-GCM 與 ChaCha20-Poly1305 是目前還沒有有效攻擊的 cipher。

前面三個都算熟悉,第四個是到是頗意外會出現... 不過 ChaCha20-Poly1305 不只一家打算跳下去實做了:

ChaCha20 與 Poly1305 都是 D. J. Bernstein (djb) 的作品,不知道 OpenSSL 會不會納進去...

在「ChaCha20 and Poly1305 for TLS」這邊有些為什麼有了 AES-GCM 後還要用 ChaCha20-Poly1305 的原因,主要是速度考量。兩者的速度差非常多...

OpenSSH 安全性問題...

Twitter 上看到 Gasol 轉推的 OpenSSH 安全性問題:「OpenSSH Security Advisory: gcmrekey.adv」。

開頭就直接寫:

If exploited, this vulnerability might permit code execution with the privileges of the authenticated user and may therefore allow bypassing restricted shell/command configurations.

這噴飯了... OpenSSH 的安全性相當強,這次出這種包... XDDD

影響的範圍是 OpenSSH 6.2 與 6.3,並且 OpenSSL 有編 AES-GCM:

OpenSSH 6.2 and OpenSSH 6.3 when built against an OpenSSL that supports AES-GCM.

如果不允許升級到 OpenSSH 6.4,那麼暫時性的解法是不允許 AES-GCM,在 /etc/ssh/sshd_config 內可以設:

Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc

結果 FreeBSD 9.2 看起來在範圍內中槍,先上 workaround 再來等 freebsd-update 提供的修正吧...

因為 NIST 而換掉 AES?

Slashdot 上看到有人因為最近 NIST 被抖出來的事蹟 (SHA-3 的問題),而決定換掉 AES:「Silent Circle Moving Away From NIST Cipher Suites After NSA Revelations」。原報導在「Non-NIST Cipher Suite」。

換掉 AES 不確定這是不是好主意...

Rijndael 從 1998 年公開後,2001 年被選為 AES,之後被廣泛應用在所有資安協定上,也因為被廣泛應用,全世界打了這十多年下來,都還是屬於可用的狀態。換成其他 cipher 會比較安全嗎?