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 會比較安全嗎?

手機網路的不安全性...

在整理舊文章的時候看到有人對 GSM 網路以及 3G/LTE 網路的安全性進行分析:「On cellular encryption」。

2G 網路 (GSM 網路) 已經是不安全的架構,主因是 30 年前可用的技術受限,加上當時的美國法令嚴格管制加密技術出口,所以整個通訊協定放了一堆後門...

3G 網路建立時 AES 也還沒出來 (1998 年 NTT DoCoMo 建立第一個非商用性質的 3G 網路),當時選用的 KASUMI cipher 後來被打趴好幾次...

4G/LTE 用的技術就更新了,當然是另外的故事,不過還是把手機網路當作不安全的媒介會比較好...

加快 SSL 加解密速度...

看到 Ash Wu 貼的「5 easy tips to accelerate SSL」:

先列出原作者在文章裡給的結論:

ALL:!ADH:!EXP:!LOW:!RC2:!3DES:!SEED:RC4+RSA:+HIGH:+MEDIUM

不過,現在考慮 SSL 效能以行動平台為主 (因為桌機用軟體計算也超快),而行動平台中 iOS 可以對 AES 與 SHA1 硬體加速 (iOS 4.3+),Android 一般的情況下看起來沒得用,所以就自己取捨啦...