SSL/TLS 的問題...

這篇與「對稱式加密系統的爆炸歷史 (Authenticated encryption 的問題)」這篇相關,建議可以一起看一看。

TLS (Transport Layer Security),前身是 SSL (Secure Sockets Layer),是目前 HTTPS 所使用的加密協議。發展的順序上是 SSLv2、SSLv3、TLSv1、TLSv1.1、TLSv1.2。

然後有兩篇文章可以看:

第一篇文章講 Padding oracle attack,第二篇文章是酸 SSL/TLS 的修正愈修愈歪... XD

AES 這類的 block cipher 在加密或解密時會要求切齊 block size,以 AES 的要求就是 128bits (16 bytes)。

而對於不齊的資料要怎麼加密呢?其中一個方法是 PKCS#7:(圖片取自第二篇文章)

Padding

要想辦法補齊 128bits (16bytes),如果像上圖需要補 7bytes 進去,就都補上 x07 (剛好就是補上長度),另外在最後面會補上 padding 的長度,而問題出就出在這個設計先天就有缺陷:在 SSL/TLS 所使用的 MAC-then-Encrypt 中,MAC 只計算原文的值,沒有保護到 padding 的部份,於是就可以針對 padding 的部份想辦法找到洞鑽。

pseudo code 可能是這樣:

// Decrypt to plaintext + mac + padding
$plaintext_mac_padding = decrypt($ciphertext);
if (NULL != $plaintext_mac_padding) {

    // Now decode padding part
    $plaintext_mac = decode_padding($plaintext_mac_padding, $padding_length);
    if (NULL != $plaintext_mac) {

        // Now check MAC part
        $plaintext = check_mac(plaintext_mac);
        if (NULL != $plaintext) {

            // Now it's okay
        }
    }
}

攻擊者亂改 $ciphertext 會導致解出來的 padding 也亂掉,但早期的 SSL 會回傳「padding error」這種對攻擊者有利的資訊,而導致攻擊者可以利用這個資訊想辦法得知更多內容。

而 TLS 並沒有從根本改善,而是試著加上機制補西牆:當遇到錯誤時就跳過,不要傳回錯誤資訊。

但因為攻擊者亂改封包造成 decode_padding() 會失敗,而沒有呼叫到 check_mac()。這導致了大量的計算時間差與能量差,而使得攻擊者可以藉由這些資訊而得知是否成功。而官方在 TLSv1.2 的建議是再補上機制來補洞:

In general, the best way to do this is to compute the MAC even if the padding is incorrect, and only then reject the packet. For instance, if the pad appears to be incorrect, the implementation might assume a zero-length pad and then compute the MAC.

而官方認為雖然這樣還是有 timing channel,但已經小到會被雜訊覆蓋,所以「應該」可以解決問題:

This leaves a small timing channel, since MAC performance depends to some extent on the size of the data fragment, but it is not believed to be large enough to be exploitable, due to the large block size of existing MACs and the small size of the timing signal.

於是,只要覺得「應該安全吧」,就會「應該會被破」:「Lucky Thirteen: Breaking the TLS and DTLS Record Protocols」:

The attacks apply to all TLS and DTLS implementations that are compliant with TLS 1.1 or 1.2, or with DTLS 1.0 or 1.2. They also apply to implementations of SSL 3.0 and TLS 1.0 that incorporate countermeasures to previous padding oracle attacks. Variant attacks may also apply to non-compliant implementations.

這 SSL/TLS 的設計讓人補到快起笑了... XD

資安的東西通常是愈複雜就愈容易被抓問題出來,在 SSL/TLS 的歷史包袱下,不知道什麼時候才想換 Encrypt-then-MAC 來改善底層問題...

加快 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 一般的情況下看起來沒得用,所以就自己取捨啦...

對稱式加密系統的爆炸歷史 (Authenticated encryption 的問題)

在「Disasters」這邊列了不少對稱式加密系統 (secret-key cryptography) 爆炸的歷史,其中提到了很多 Encrypt 與 MAC 結合時的問題 (Authenticated encryption)。另外 Colin Percival 在 2009 年的時候有寫了一篇為什麼要用 Encrypt-then-MAC 的文章:「Encrypt-then-MAC」,當時 Colin Percival 寫的時候大家還是不能理解,但現在回頭看上面的爆炸歷史應該就清楚很多了 XDDD

SSH 協定是使用 Encrypt-and-MAC (傳輸「密文」與「明文的 MAC 值」)。在 2008 年時 SSH 使用 CBC 模式時會有安全問題:對 128bits CBC mode system (像是 aes128-cbc),任意位置的 32bits 有 2-18 的機會可以解出原文。(CVE-2008-5161,論文是「Plaintext Recovery Attacks Against SSH」)

TLS 1.0 (SSLv3) 使用 MAC-then-Encrypt (傳輸「明文與明文的 MAC 值」加密後的結果)。1999 年就知道這個方法不可靠,不過到了 2011 年時才被拿出來示範,也就是 BEAST attack。(CVE-2011-3389,在 ekoparty Security Conference 上的「表演」:「BEAST: Surprising crypto attack against HTTPS」,連結1連結2)

OpenSSLGnuTLS 所實作的 DTLS 在 2011 年也被炸到,其中 OpenSSL 是 100% plaintext recovery,GnuTLS 是 4%。(CVE-2012-0390,論文是「Plaintext-Recovery Attacks Against Datagram TLS」)

而 Encrypt-then-MAC (傳輸「密文」與「密文的 MAC」) 是三者裡面最不容易出包的作法,而且被證明 Provable security:Encrypt 與 MAC 所用的 crypto system 的安全強度不會因為 Encrypt-then-MAC 而減少。而這也是 IPSec 的作法。

附帶一提,其中 Provable security 這個詞,並非表示「可被證明是安全的」,在「In defense of Provable Security」這篇文章裡有比較完整的說明。通常是指安全強度不會因為這個系統而降低:以 Encrypt-then-MAC 的例子來說,如果 Encrypt 的部份用 DES,或是 MAC 用 CRC32,那麼 Encrypt-then-MAC 並不會提供更強的安全性...

總而言之,MAC-then-Encrypt 與 Encrypt-and-MAC 的方式要小心才能避免各種攻擊 (像是不能用 CBC mode),而 Encrypt-then-MAC 可以讓設計協定的人放鬆到「只要 Encrypt 與 MAC 都夠強」系統就沒問題。在 Authenticated encryption 裡提到的 ISO/IEC 19772:2009 支援六個模式,有些有專利問題,有些演算法看起來就很複雜 (於是就容易出包),其中 Encrypt-then-MAC 看起來是個還不錯的方案...

這次 TURKTRUST 誤發 *.google.com SSL 憑證...

這次 TURKTRUST 誤發 *.google.com 憑證被 Google 當初佈下的網子抓到:「Enhancing digital certificate security」。

首先是每次 CA 出問題後都會對目前的 PKI 提出質疑的文章 (像是「TURKTRUST Incident Raises Renewed Questions About CA System」),在沒有有效的方法可以取代目前的 PKI 前,都是吵一吵之後就沒有結論,所以先不管這個題目。

想要提出來的是 Google 這次抓到的機制:「Public Key Pinning Extension for HTTP」,目前狀態仍是 draft。不過 Google 在 Google Chrome 13 就已經實作一部分了,並且把一堆 domain 寫死進去:「View of /trunk/src/net/base/transport_security_state_static.json」,可以看到 Google 的 domain 只允許這些 CA 簽:

      "name": "google",
      "static_spki_hashes": [
        "VeriSignClass3",
        "VeriSignClass3_G3",
        "Google1024",
        "Google2048",
        "EquifaxSecureCA",
        "GeoTrustGlobal"
      ],

任何想要在太歲爺上動土的都會被抓包 XD

另外 Google Chrome 還是沒有 Certificate 相關的 API,目前只有 API Proposal 掛著:「webRequest SSL Hooks」,相較於 Firefox 有不少 extension 可以用,這方面 Google Chrome 就差了不少...

Firefox 11 將會支援 SPDY Protocol

Firefox 預定在 11 (現在是 8) 支援 SPDY Protocol:「(SPDY) Implement SPDY protocol」,除了 Google Chrome 自家瀏覽器支援外,總算有個大的也要支援了...

所以現在除了 Chrome、Kindle Fire 以外,又多了 Firefox 支援...

不過 ApacheF5 什麼時候會支援呢... mod-spdy 看起來... 呃...

維基百科全面支援 HTTPS (SSL)

維基百科在官方的 Blog 上宣佈,所有的服務都支援 HTTPS (SSL):「Native HTTPS support enabled for all Wikimedia Foundation wikis」,也就是說,像是「https://zh.wikipedia.org/wiki/Wikipedia:首页」這樣的網址都支援了。

除了 *.wikipedia.org 以外,*.wikimedia.org 也支援了,於是包括像是 upload.wikimedia.org 也都可以使用 HTTPS:(圖片取自 File:Minori-Chihara-Animelo-Summer-Live-2011-08-27-21-41.jpg)

當然,還是有一些 script 寫死用 http,接下來應該都會被修正...

安裝 Certificate Patrol 增加對最近 SSL Certificate 問題的抵抗性...

這只能掙扎,但還是要掙扎啊!

Certificate Patrol 是一個 Firefox 延伸套件,你可以設定在新看到 SSL Certificate 的時候跳出一個視窗來告訴你這個 SSL Certificate 的資訊:

如果你平常有在用 https://mail.google.com,結果突然發現有天跳出視窗,你就應該要有所警覺了...