OpenSSL 1.1.0

看到「OpenSSL 1.1.0 released」這篇得知大家期待已久的 OpenSSL 1.1.0 出了,在 1.1.0 的重要新功能中,對 ChaCha20 + Poly1305 的支援算是大家等很久的:

  • Support for ChaCha20 and Poly1305 added to libcrypto and libssl

由於 RC4 已經被證明不安全,OpenSSL 內變成沒有堪用的 stream cipher,這邊總算要補上來了...

另外兩個也頗有趣的:

  • Support for scrypt algorithm
  • Support for X25519

多了些東西...

SWEET32:攻 Blowfish 與 3DES

最新的攻擊算是實戰類的攻擊,理論基礎以前都已經知道了,只是沒有人實際「完成」。算是近期少數直接對演算法的攻擊,而這些演算法剛好還是被用在 TLSOpenVPN 上,所以嚴重性比較高:「SWEET32: Birthday attacks on 64-bit block ciphers in TLS and OpenVPN」。

攻擊的條件是 block cipher 的 block size,而非 key length,所以就算是 256 bits 的 Blowfish 也一樣也受到影響。

這次順利打下 Blowfish3DES。這兩個 cipher 的 block size 都是 64 bits,所以對於 birthday attack 來說只要 232 就可以搞定:

This problem is well-known by cryptographers, who always require keys to be changed well before 2n/2 blocks. However it is often minimized by practitioners because the attacks require known plaintext, and reveal only little information. Indeed, standard bodies only recommend to change the key just before 2n/2 blocks, and many implementations don't enforce any limit on the use of a key.

在 OpenVPN 打 Blowfish 的部份 (Blowfish 是 OpenVPN 預設的 cipher):

In our demo, it took 18.6 hours and 705 GB, and we successfully recovered the 16-byte authentication token.

以及 HTTPS 打 3DES 的部份 (為了相容性問題):

Experimentally, we have recovered a two-block cookie from an HTTPS trace of only 610 GB, captured in 30.5 hours.

都是有可能的等級。也該來拔掉對 IE8 的支援了... orz

在 SSL Labs 上拿到 Perfect Score (完全滿分的 A+)

在「Achieving a Perfect SSL Labs Score with Go」這邊提到要如何在 Go 上面達到 SSL LabsSSL Server Test 的 Perfect Score (完全滿分的 A+),但其實裡面大多數的東西都應該適用於其他地方。

其中 Cipher Strength 這邊讓人非常意外的是,只有在關閉 HTTP/2 的情況下才有可能達到 100%,因為 HTTP/2 規定強制要支援 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,而這是 128bits cipher,會導致無法達到 100%:

No HTTP/2 for you! - HTTP/2 was enabled by default in go 1.6, however HTTP/2 mandates the support of the cipher suite TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256. As this is a 128bit cipher, it needs to be removed. The only way to achieve a perfect score now is to disable HTTP/2.

這被點出來後不知道會有什麼改變... (無論是 HTTP/2 或是 SSL Labs)

OpenSSL 1.1.0 的 Release Notes 先放出來了 (現在是 Beta 1)

雖然才 Beta 1,但 OpenSSL 先放出 1.1.0 的 Release Notes 了:「OpenSSL 1.1.0 Series Release Notes」。

有幾個新的功能以及重大的改變,包括了對 ChaCha20Poly1305 的支援,並且把 SSLv2、RC4、所有 40bits 與 56bits 的 cipher 拔掉,然後支援 Certificate Transparency

讓人頗期待... 不知道來不來得及跟上 Ubuntu 16.04

新的 RC4 攻擊:實戰化

Twitter 上看到對 RC4 的新攻擊,可以直接攻擊 TLS 與 WPA-TKIP,沒有 workaround:「All Your Biases Belong To Us: Breaking RC4 in WPA-TKIP and TLS」。

TKIP 可以在一個小時內打下來:

In practice the attack can be executed within an hour.

對於 TLS 則是 75 個小時有 94% 成功率,實際測試時只用了 52 個小時就順利攻下來:

We also attack TLS as used by HTTPS, where we show how to decrypt a secure cookie with a success rate of 94% using 9·227 ciphertexts. This is done by injecting known data around the cookie, abusing this using Mantin's ABSAB bias, and brute-forcing the cookie by traversing the plain-text candidates. Using our traffic generation technique, we are able to execute the attack in merely 75 hours.

When we tested the attack against real devices, it took merely 52 hours to successfully perform the attack.

看起來唯一的解法是停用...

CloudFlare 對 Go 上面加解密系統的改善

CloudFlare 發佈了自己版本的 Go,修改了其中的 crypto subsystem:「Go crypto: bridging the performance gap」。

文章花了不少篇幅介紹 AEAD (Authenticated Encryption with Associated Data),而目前 CloudFlare 支援的是 AES-GCM 與 ChaCha20-Poly1305,也是兩大主流,分別佔了 60% 與 10% 的 HTTPS 流量:

As such today more than 60% of our client facing traffic is encrypted with AES-GCM, and about 10% is encrypted with ChaCha20-Poly1305.

CloudFlare 提供的改進使得速度快很多,並且有考慮到 side-channel attack 的問題:

Both implementations are constant-time and side-channel protected.

                         CloudFlare          Go 1.4.2        Speedup
AES-128-GCM           2,138.4 MB/sec          91.4 MB/sec     23.4X

P256 operations:
Base Multiply           26,249 ns/op        737,363 ns/op     28.1X
Multiply/ECDH comp     110,003 ns/op      1,995,365 ns/op     18.1X
Generate Key/ECDH gen   31,824 ns/op        753,174 ns/op     23.7X
ECDSA Sign              48,741 ns/op      1,015,006 ns/op     20.8X
ECDSA Verify           146,991 ns/op      3,086,282 ns/op     21.0X

RSA2048:
Sign                 3,733,747 ns/op      7,979,705 ns/op      2.1X
Sign 3-prime         1,973,009 ns/op      5,035,561 ns/op      2.6X

AES-GCM 與 EC 的改善主要是利用 CPU 指令集加速:

[T]herefore we created assembly implementations of Elliptic Curves and AES-GCM for Go on the amd64 architecture, supporting the AES and CLMUL NI to bring performance up to par with the OpenSSL implementation we use for Universal SSL.

不過 RSA 的部份雖然幅度也不小 (比起 AES 與 EC 的部份是不大,不過純就數字來看,快了一倍多也不少),不過沒提到怎麼改善,只稍微帶過:

In addition the fork includes small improvements to Go's RSA implementation.

SSL Labs 對 RC4 的退役計畫

SSL Labs 的「SSL Server Test」是個經常被拿來檢測 SSL/TLS 相關設定的服務。

這兩天公佈了對 RC4 的退役計畫:「SSL Labs RC4 Deprecation Plan」。

分成兩個階段進行。

第一個階段會在五月啟用,對於因為需要支援舊的 client 而針對 SSLv3/TLSv1 + RC4 組合的,會給予 B 評價。而全面支援 RC4 的 (包括 TLSv1.1+) 則會給予 C 評價。

到了第二階段 (暫定九月),全面支援 RC4 的將會給予最低的 F 評價。

再度改善對 RC4 的攻擊效率...

在「RC4 must die」這個網站寫的真直接,正式標題是「Attacks Only Get Better: Password Recovery Attacks Against RC4 in TLS」。

可以在 226 次嘗試取得 TLS 裡傳輸的 password,相較於之前的 234 低了非常多。另外論文裡也說明了他們成功實作 PoC,取得 IMAP (TLS) 與 HTTP Basic Auth (TLS) 的密碼部份。

不過 RC4 的使用率比想像中高好多 (出自 ICSI Certificate Notary project 的「Connection Cipher Details」數據):

Despite 2013's high-profile attacks on the RC4 algorithm in TLS, its usage is today (March 2015) still running at about 30% of all TLS traffic.

現在的超級低標應該是 TLS 1.0 的 3DES (給 Windows XP + IE8 的情況下用),不過也已經不夠安全,能拔掉的就先拔...

CVE-2015-0204:OpenSSL 的弱點攻擊 (Android 與 iOS)

CVE-2015-0204 的說明:

The ssl3_get_key_exchange function in s3_clnt.c in OpenSSL before 0.9.8zd, 1.0.0 before 1.0.0p, and 1.0.1 before 1.0.1k allows remote SSL servers to conduct RSA-to-EXPORT_RSA downgrade attacks and facilitate brute-force decryption by offering a weak ephemeral RSA key in a noncompliant role.

本來是被 OpenSSL 標成低危險性 (出自 secadv_20150108.txt):

RSA silently downgrades to EXPORT_RSA [Client] (CVE-2015-0204)
Severity: Low

不過新的攻擊利用這個弱點放大,叫做「FREAK Attack」,可以強制使用 RSA_EXPORT suite 所列的 cipher,而這些 cipher 通常長度都不夠,於是就可以解:

A connection is vulnerable if the server accepts RSA_EXPORT cipher suites and the client either offers an RSA_EXPORT suite or is using a version of OpenSSL that is vulnerable to CVE-2015-0204. Vulnerable clients include many Google and Apple devices (which use unpatched OpenSSL), a large number of embedded systems, and many other software products that use TLS behind the scenes without disabling the vulnerable cryptographic suites.

影響的範圍主要是支援 RSA_EXPORT suite 的 server:

Websites that support RSA export cipher suites (e.g., TLS_RSA_EXPORT_WITH_DES40_CBC_SHA) are at risk to having HTTPS connections intercepted.

應該是把 !EXPORT 設上去就可以解掉,不過還是花點時間 review,把可以關掉的舊技術都拔掉會比較好。

Firefox 成為第一個預設啟用 HTTP/2 的主流瀏覽器

Firefox 36 的 Release Notes 內宣佈預設啟用 HTTP/2

Support for the full HTTP/2 protocol. HTTP/2 enables a faster, more scalable, and more responsive web.

另外 Firefox 36 也拔除 RC4

No longer accept insecure RC4 ciphers whenever possible

接下來應該是 Google Chrome 預設啟用,以及 nginx 的 server implementation...