Home » Posts tagged "ssl" (Page 25)

Wildcard EV Certificate...

Netcraft 這篇「Wildcard EV certificates supported by major browsers」提到幾個重點...

首先是 EV 規範內禁止使用 Wildcard certificate (出自「Guidelines ForThe IssuanceAnd Management Of ExtendedValidationCertificates」):

Wildcard certificates are not allowed for EV Certificates.

然後還是有人發 *.cclearning.accenture.com,而且主流瀏覽器會正常照 EV 模式顯示出來:(這邊拿 Google Chrome 的範例,原文有所有截圖)

只有 Safari 的手機版本當作普通 certificate 處理的:(下面兩張圖,上圖是桌機版,下圖是手機版)

被抓出來鞭後應該會修正... 吧?

Update:感謝 comment 的糾正,Safari 的地方寫錯了...

SNI 支援 (單一 IP 多個 SSL Certificate)

Twitter 上看到 yllan 提到 SSL certificate 的問題:

這是看 client 對 Server Name Indication 的支援程度而決定的。

在維基百科說明中「Browsers with support for TLS server name indication」這段裡面列出來的瀏覽器,可以看出來其實最大的問題就是 Windows XP 上的 IE{6,7,8} 不支援。(但 Windows Vista 以及 Windows 7 的 IE{7,8} 支援 SNI)

手上一時間找不到 Windows XP + IE{6,7,8} 的數量,但 gs.statcounter.com 上有幾個數字可以參考。

首先是台灣 IE8 的用戶數量:

再來是 Windows XP 數量:

以這兩個圖的資料來看,還是不太能用啊... :o

SSL/TLS 的 Perfect Forward Secrecy...


寫這篇順便測試 MathJax 的效果...

因為 NSA 的惡搞,這陣子 PFS (Perfect Forward Secrecy) 突然被拿出來討論:

在講 PFS 前,得先講 Diffie-Hellman key exchange (D-H)。

D-H 是利用這個等式:

$$(g^a)^b \equiv (g^b)^a \mod p$$

其中 \(p\) 是大質數,而 \(g\) 是 \(p\) 的 primitive root (即不存在任何 \(n < p\) 可以使得 \(g^n \equiv 1 \mod p\))。 而因為當 \(p\) 夠大時,要從 \(g^a \mod p\) 計算 \(a\) 就是離散對數問題,而離散對數問題是已知沒有有效率計算的問題,所以我們會假定當 \(p\) 夠大時,傳輸 \(g^a \mod p\) 是無法用合理資源計算得知 \(a\)。

因此,Alice 與 Bob 就可以產生自己的 private secret \(a\) (Alice) 與 \(b\) (Bob),計算出 \(g^a\) 與 \(g^b\) 後公開傳輸給對方,當 Bob 收到 Alice 提供的 \(g^a\) 時就計算 \((g^a)^b \equiv g^{ab} \mod n\),而 Alice 收到 Bob 提供的 \(g^b\) 後可以計算 \((g^b)^a \equiv g^{ba} \equiv g^{ab} \mod n\)。

而攻擊者只拿到公開的 \(g^a\) 與 \(g^b\) 以及 \(g\),無法計算出 \(g^{ab}\),於是就雙方就建立一組 shared secret 了。

回到 SSL/TLS 的問題上,由於 RSA 加解密的速度並不快,所以 SSL/TLS 是在 RSA 的保護下交換 RC4 或是 AES 所需要的金鑰 (key)。

交換 key 這件事情除了可以直接交換以外,還可以利用 D-H 交換。

D-H 交換可以確保當 RSA key 被破解時還要再破每個 session 的 D-H 所產生出來的 key,而直接交換的話,只要破一把 RSA key 就可以解出所有 traffic 了。

而 PFS 會被提出來,是因為目前消息指出 NSA 其實有在錄下 SSL/TLS 流量,等哪天有機會取得 RSA key 的時候 (無論是硬解,或是其他方式),就有機會能夠一次破一卡車資料... (因為目前大部分的 SSL/TLS 流量都沒有上 PFS)

雖然 PFS 會慢一些,不過已經確認 NSA 打算來搞了,所以還是乖乖加上去吧... @_@

AWS CloudFront 可以用自己的 SSL Certificate 了...

以往 CloudFront 只能用 *.cloudfront.net 當作 SSL domain,但在今天公告的「Custom SSL Domain Names and Root Domain Hosting for Amazon CloudFront」這篇說明內,宣佈可以上傳自己的 SSL certificate 使用了。

目前的價錢是 USD$600/month,不過是以小時計算。即使拋開錢的問題,在 CloudFront 已經支援 SSL 的前提下 (而且因為是 *.cloudfront.net,理論上是 cookie-free domain),技術面上暫時想不到什麼好處... 在 DNS 端自己混合多家 CDN 是個可能的方向?

OCSP 是如何影響 HTTPS 的效率...

Netcraft 從 2012 年 11 月開始偵測 OCSP 的 availability,然後發現各家 OCSP 的穩定性都不太好:「Certificate revocation and the performance of OCSP」。

OCSP 是 Online Certificate Status Protocol 的縮寫,當 HTTPS 連線建立中,client 可以透過 OCSP 詢問這份 certificate 是否有效。這是 PKI 架構下的事後補救機制,因為已經發出去的簽名是無法被收回的,只好靠連線時再查詢。

另外一個機制比較舊,叫 CRL (Certificate Revocation List),則是屬於清單類的機制,更新速度比 OCSP 慢。

目前是以 OCSP 為主,而舊的平台 (就是 XP 上的 IE) 則只支援 CRL。

可以看到 OCSP 檢查打開後對於速度的影響,有的影響很明顯,有的還好。而原文下面很多張 uptime 圖表也可以看出來各家 OCSP 的穩定性其實不怎樣,有些是直接上 Akamai 解決,有些是上 CloudFlare 解決 (然後遇到幾次 CloudFlare 爆炸就跟著炸 XD)

目前瀏覽器大多都是 soft-fail,也就是查不到就當作 pass。照目前的穩定性要推動 hard-fail (查不到就 break) 應該是頗有難度...

對於 HTTPS 速度很在意的人可以看一下內文的說明,可以挑 OCSP 速度比較快的幾家簽,對速度會有幫助...

Hostname 最後面的點 (dot) 會造成的影響...

在這邊探討了 FQDN 形式 (hostname 最後面有 dot 結尾的形式) 對於瀏覽器的影響:「The danger of the trailing dot in the domain name」。

影響包括了 HTTPS 的 SSL Certificate 會失效:

另外,cookie domain 會不一樣,所以在有 dot 的頁面上登入後,重導到沒有 dot 的網址上會讀不到 cookie 而造成登入失敗。

瀏覽器應該對 dot 處理嗎?一時間想不到有什麼問題,不過好像又不應該處理...

Facebook 將全面支援 SPDY...

在「Facebook Adds SPDY Support!」看到 Facebook 將全面支援 SPDY 的消息。

Facebook 的 *.fbcdn.net 在二月先上 SPDY 了:

I managed to find this image uploaded by Varun Kumar on February 1 2013, showing that Facebook’s CDN hostname *.fbcdn.net was serving static resources like images and JavaScript via SPDY.

m.facebook.com (行動版) 也上 SPDY 了,不過要 Android 3+ 才支援。

目前 SPDY 主要支援的平台是 Firefox 13+ (11+ 支援,但預設沒開),Google Chrome 與 Android 3+,市占率大約 50%... 好像也不少?(參考:Can I use SPDY networking protocol?)

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 來改善底層問題...

Archives