Tag: cipher

nginx 記錄 TLS 連線資訊

想要在 nginx 的 access log 裡面記錄使用者在 HTTPS 連線使用的 TLS protocol 與 cipher。

在「How can I let nginx log the used SSL/TLS protocol and ciphersuite?」這邊有提到方向是 $ssl_protocol 與 $ssl_cipher (出自「Module ngx_http_ssl_module」內的 Embedded Variables 章節)。

他的方式是在前面就插入 protocol，但我希望前面的欄位保持不變，把 protocol & cipher 放到後面，所以我就加了一個 /etc/nginx/conf.d/combined_ssl.conf (這邊我用 ondrej 的 PPA，在設定檔裡會撈 /etc/nginx/conf.d/ 下的設定，不確定其他的情況如何)：

#
log_format combined_ssl '$remote_addr - $remote_user [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" $ssl_protocol/$ssl_cipher';

然後本來用 combined 的 HTTPS 設定就改成 combined_ssl。

來放一陣子再來分析，然後想看看要怎麼調整 cipher...

OpenSSL 1.1.1 將支援 TLS 1.3

OpenSSL 的文章「Using TLS1.3 With OpenSSL」提到了：

The forthcoming OpenSSL 1.1.1 release will include support for TLSv1.3.

另外也提到了 TLS 1.3 的標準是 blocker，在 TLS 1.3 沒出來前不會出 OpenSSL 1.1.1：

OpenSSL 1.1.1 will not be released until (at least) TLSv1.3 is finalised.

OpenSSL 實做的 TLS 1.3 支援了這些 cipher：

  • TLS13-AES-256-GCM-SHA384
  • TLS13-CHACHA20-POLY1305-SHA256
  • TLS13-AES-128-GCM-SHA256
  • TLS13-AES-128-CCM-8-SHA256
  • TLS13-AES-128-CCM-SHA256

GCM 的部份不算意外，比較特別的是包括了 ChaCha20 與 Poly1305 (喊很久了)，另外包括了 CCM mode 的實做...

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

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

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

這次順利打下 Blowfish 與 3DES。這兩個 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 Labs 上 SSL 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」。

有幾個新的功能以及重大的改變，包括了對 ChaCha20 與 Poly1305 的支援，並且把 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 的情況下用)，不過也已經不夠安全，能拔掉的就先拔...