CloudFlare 宣佈停用 RC4,並且支援 ChaCha20+Poly1305

CloudFlare 同時宣佈了停用 RC4 與支援 ChaCha20+Poly1305 的計畫:「End of the road for RC4」、「Do the ChaCha: better mobile performance with cryptography」。

2014 年年初的時候,CloudFlare 先把 RC4 從 TLS 1.1+ 的連線拿掉,而 2014 年五月時,再把 RC4 搬到 cipherlist 裡優先權最低的,成功的讓 99.9991% 的 request 改用 AES3DES (大約五個 9 ):

而九個月後的現在,CloudFlare 上 RC4 使用的比率則是降到了 0.000002%,反過來說也就是 99.999998% 的等級 (七個 9),也讓 CloudFlare 決定直接停用掉 RC4。

另外一個重大的新進展則是 ChaCha20+Poly1305,兩個都是 Daniel J. Bernstein 的作品。其中 ChaCha20 是 stream cipher,Poly1305 是 MAC。

由於 RC4 已經不夠安全,在行動平台上要夠安全必須使用 AES,但 AES 在 ARM 上面還沒有普及:在 Nexus 6 用的 ARMv7 不支援,是透過 Qualcomm Snapdragon 805 的加掛模組做的,而在低階手機支援度就更不用說了。

Google 大力推動 ChaCha20+Poly1305 的目的,是為了在行動平台上找到一個與 RC4 可以匹敵的速度,而且有著可以超越 AES-GCM 安全性的 cipher+MAC。

在 CloudFlare 採用 ChaCha20+Poly1305 前,Google 是唯一一個在 HTTPS 上大幅採用的單位,而瀏覽器的部份也只有 Google Chrome 有支援。雖然 Firefox 一直有喊著要支援,但這是個雞生蛋蛋生雞的問題,可以看到進度不怎麼快 (Bug 917571 - Support ChaCha20+Poly1305 cipher suites)。

CloudFlare 支援之後,使用 ChaCha20+Poly1305 的 pool 瞬間大了不少。可以看到一上線的使用率不算低,瞬間就有 10% 了:

希望可以推動 Firefox 快一點支援... (這是養大 pool 的下一步)

ELB 預設關閉 RC4 Cipher

Twitter 上看到 Jeff Barr 轉貼自論壇的公告:「Announcement: Elastic Load Balancing releases security update to disable RC4」。

既有的 ELB 不受影響,不過官方還是建議把現有的 RC4 關閉。新開的 ELB 如果需要 RC4 也還是可以手洞開回來:

If you require RC4 ciphers you can re-enable them by selecting the 2014-10 SSL Security Policy or by manually configuring the SSL ciphers used by the load balancer.

用 CipherScan 在 command line 下檢查系統

在「SSL/TLS for the Pragmatic」這篇裡面提到了 CipherScan 這個工具,用起來很簡單而且輸出很清楚。

直接 git clone 下來後執行就可以了,另外因為檢測 ChaCha20+Poly1305 需要新版 OpenSSL (1.0.2 才有,目前還是開發版),所以 clone 下來的時候裡面包括了一個 Linux 版的 openssl,砍掉的話他會用系統的 openssl。

像是我的 blog 就可以掃出這樣的結果:

gslin@home [~/git/cipherscan] [17:57/W4] (master) ./cipherscan blog.gslin.org:443
........................
Target: blog.gslin.org:443

prio  ciphersuite                  protocols              pfs_keysize
1     DHE-RSA-AES256-GCM-SHA384    TLSv1.2                DH,2048bits
2     ECDHE-RSA-AES256-GCM-SHA384  TLSv1.2                ECDH,P-256,256bits
3     ECDHE-RSA-AES256-SHA384      TLSv1.2                ECDH,P-256,256bits
4     ECDHE-RSA-AES256-SHA         TLSv1,TLSv1.1,TLSv1.2  ECDH,P-256,256bits
5     DHE-RSA-AES256-SHA256        TLSv1.2                DH,2048bits
6     DHE-RSA-AES256-SHA           TLSv1,TLSv1.1,TLSv1.2  DH,2048bits
7     DHE-RSA-CAMELLIA256-SHA      TLSv1,TLSv1.1,TLSv1.2  DH,2048bits
8     AES256-GCM-SHA384            TLSv1.2
9     AES256-SHA256                TLSv1.2
10    AES256-SHA                   TLSv1,TLSv1.1,TLSv1.2
11    CAMELLIA256-SHA              TLSv1,TLSv1.1,TLSv1.2
12    ECDHE-RSA-AES128-GCM-SHA256  TLSv1.2                ECDH,P-256,256bits
13    ECDHE-RSA-AES128-SHA256      TLSv1.2                ECDH,P-256,256bits
14    ECDHE-RSA-AES128-SHA         TLSv1,TLSv1.1,TLSv1.2  ECDH,P-256,256bits
15    DHE-RSA-AES128-GCM-SHA256    TLSv1.2                DH,2048bits
16    DHE-RSA-AES128-SHA256        TLSv1.2                DH,2048bits
17    DHE-RSA-AES128-SHA           TLSv1,TLSv1.1,TLSv1.2  DH,2048bits
18    DHE-RSA-CAMELLIA128-SHA      TLSv1,TLSv1.1,TLSv1.2  DH,2048bits
19    AES128-GCM-SHA256            TLSv1.2
20    AES128-SHA256                TLSv1.2
21    AES128-SHA                   TLSv1,TLSv1.1,TLSv1.2
22    CAMELLIA128-SHA              TLSv1,TLSv1.1,TLSv1.2
23    DES-CBC3-SHA                 TLSv1,TLSv1.1,TLSv1.2

Certificate: trusted, 2048 bit, sha256WithRSAEncryption signature
TLS ticket lifetime hint: 600
OCSP stapling: supported
Server side cipher ordering

Ubuntu 上把 Chrome 拔掉 RC4 連線的方法

首先先看「SSL Cipher Suite Details of Your Browser」這個網站,會列出你目前瀏覽器支援的 cipher suite,會需要知道要拔掉哪些號碼。

接下來的資料是參考「Remove RC4 from SSL/TLS ciphers in Chromium」這篇的方法。

Ubuntu 的使用者可以到 /usr/share/applications/google-chrome.desktop 這邊修改,本來是:

Exec=/usr/bin/google-chrome-stable

改成:

Exec=/usr/bin/google-chrome-stable --cipher-suite-blacklist=0x0004,0x0005,0xc011,0xc007

其中的十六進位數字就是出自最前面提到的網站:

  • 0x0004 對應 RSA-RC4128-MD5,
  • 0x0005 對應 RSA-RC4128-SHA,
  • 0xc011 對應 ECDHE-RSA-RC4128-SHA,
  • 而最後的 0xc007 對應 ECDHE-ECDSA-RC4128-SHA。

這樣就可以將 RC4 禁用掉。

NCCC (聯合信用卡處理中心) 的網站不支援 AES 加密...

看到廉價航空機票在特價跑去刷,結果刷了兩次都死在聯合信用卡處理中心的 acs.nccc.com.tw 畫面出不來。突然想到我把 RC4 關掉了,該不會是這種原因吧...

跑去「SSL Report: acs.nccc.com.tw (210.61.215.16)」這邊一看,果然是不支援 AES

抱頭痛哭啊... 只好 rollback 回來 @_@

選擇 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

SSL 3.0 爆炸,CVE-2014-3566,POODLE

這次的慘案是由 Google 的人找到 SSL 3.0 的問題:「This POODLE bites: exploiting the SSL 3.0 fallback」。

Google 提供的解法有兩種。一種是關掉 SSL 3.0,另外一種是關掉 SSL 3.0 的 CBC-mode cipher,但兩種解法都還是會痛:

Disabling SSL 3.0 support, or CBC-mode ciphers with SSL 3.0, is sufficient to mitigate this issue, but presents significant compatibility problems, even today.

提到相容性問題的原因是 Windows XP + IE6 的組合,在預設安裝下是不支援 TLS 1.0 的 (需要另外打開選項啟用),而看到那個 11.1%:


出自「Internet Explorer - IE 6 Countdown | Modern.IE

另外是 SSL 3.0 如果不支援 CBC-mode cipher 的話,也只剩下 RC4,而這早就千窗百孔了:


出自「Transport Layer Security

也因此,在 CBC-mode cipher 與 RC4 都不能用的情況下,CloudFlare 決定直接關閉 SSL 3.0:「SSLv3 Support Disabled By Default Due to POODLE Vulnerability」。

而其他廠商提供的方案也都差不多,像是 AWS 的「CVE-2014-3566 Advisory」裡建議的解法也是關閉 SSL 3.0:

This includes disabling SSLv3 on both server and client implementations.

新推出的 security policy (ELBSecurityPolicy-2014-10) 裡也直接關掉 SSL 3.0,讓真的有需要的人再手動加上去,或是選擇一月的版本。

SSL 3.0 推出 18 年後總算要被殲滅了...

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 會對整個市場有正面的影響。接下來看看還有誰會動手?

AWS ELB 加強安全性...

AWS ELB 加強對 SSL 安全性的功能:「Elastic Load Balancing – Perfect Forward Secrecy and Other Security Enhancements」。

第一個是支援 PFS (Perfect Forward Secrecy),愈大多數的實做相同,是使用 ECDH

第二個是 Server Order Preference,由 server 這邊決定最終的 cipher。

最重要的是第三個,也就是「懶人包」。推出新的 security policy ELBSecurityPolicy-2014-01,把上面兩個都設進去了。

這次的升級是對安全性的提昇...

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 企圖同時解決這兩個問題,接下來就是看時間考驗了...