Home » Posts tagged "tls" (Page 20)

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 的下一步)

聯想對 Superfish 的新聞稿、反安裝說明,以及影響的機器列表

Update:參考「聯想與 Superfish 的法律訴訟,以及後續的發展...」。

上一篇「聯想在筆電上安裝 Adware」由於被證實每一台機器都是一樣的 CA key,所以這把 key 將可以拿來攻擊這些電腦。

各家的 Spyware/Adware/Malware 清除軟體都把 Superfish 納入了:

聯想官方的新聞稿中裡面有受到影響的機器列表:「LENOVO STATEMENT ON SUPERFISH」。

  • G Series: G410, G510, G710, G40-70, G50-70, G40-30, G50-30, G40-45, G50-45
  • U Series: U330P, U430P, U330Touch, U430Touch, U530Touch
  • Y Series: Y430P, Y40-70, Y50-70
  • Z Series: Z40-75, Z50-75, Z40-70, Z50-70
  • S Series: S310, S410, S40-70, S415, S415Touch, S20-30, S20-30Touch
  • Flex Series: Flex2 14D, Flex2 15D, Flex2 14, Flex2 15, Flex2 14(BTM), Flex2 15(BTM), Flex 10
  • MIIX Series: MIIX2-8, MIIX2-10, MIIX2-11
  • YOGA Series: YOGA2Pro-13, YOGA2-13, YOGA2-11BTM, YOGA2-11HSW
  • E Series: E10-30

另外聯想提供了反安裝說明,除了可以用自動化程式處理外,也可以用手動刪除,第一步是先反安裝 Superfish,移除完成後要清除所有 CA root 資料,包括 Windows 系統內 (IE、Chrome、... 使用系統的 CA 資料) 以及 Firefox 的:「Superfish Uninstall Instructions」。

用自動化移除的人,建議做完以後還是手動檢查。

聯想在筆電上安裝 Adware

Update:參考「聯想與 Superfish 的法律訴訟,以及後續的發展...」。

Update:後續參考「聯想對 Superfish 的新聞稿、反安裝說明,以及影響的機器列表」。

今天的大條新聞,不少傳統媒體也都有報導:

另外「Lenovo installs adware on customer laptops and compromises ALL SSL.」這篇講得還蠻完整的。

這次的 adware 還被更歸類到 malware 就是因為他會在本機上安裝自己的 CA root,解開所有的 HTTPS traffic 並且插入廣告。而這包括了銀行網站、醫療網站、各種極度隱私的加密服務。

Is Superfish malware?

Lenovo won’t want anyone to call it that, but Superfish has been described as a piece of malware, or an adware pusher, that the Chinese firm pre-installs on consumer laptops.

在「Extracting the SuperFish certificate」這邊有告訴你方法,教你取得 SuperFish 的 protected private key & key password。不過不確定每一台機器是不是都一樣,作者把取出來的 pem 檔放在「test.pem」這邊。

記錄 Firefox/Chrome 在 TLS 的 Session Key 供 Wireshark 使用

以往要看 TLS traffic,需要用 mitmproxy 之類的軟體擋在中間,這需要在 client 端安裝對應的 CA root certificate。

而剛剛在「Decrypting TLS Browser Traffic With Wireshark – The Easy Way!」這篇文章裡面提到了如何讓 FirefoxChrome 記錄下 TLS 的 Session Key,然後倒給 Wireshark 使用。(文章裡有提到需要 dev 版本,不確定是因為新版支援的關係,還是這個功能限制在 dev 版才能用)

方法是在執行時設定 SSLKEYLOGFILE 這個環境變數,指定寫到某個檔案裡。不論是在 Windows & MacOSX & Linux 都一樣。

之後就可以把 Session Key 丟給 Wireshark 處理了,就像是這樣:(原文的範例)

關於 .onion SSL Certificate 的表決 (Tor Network)

關於 .onion 的 SSL Certificate,在 CAB Forum 這邊提出來表決了:「Ballot 144 – Validation rules for .onion names」。

有些時間限制與一般的 SSL Certificate 不太一樣:

CAs MUST NOT issue a Certificate that includes a Domain Name where .onion is in the right-most label of the Domain Name with a validity period longer than 15 months. Despite Section 9.2.1 of the Baseline Requirements deprecating the use of Internal Names, a CA MAY issue a Certificate containing an .onion name with an expiration date later than 1 November 2015 after (and only if) .onion is officially recognized by the IESG as a reserved TLD.

然後:

On or before May 1, 2015, each CA MUST revoke all Certificates issued with the Subject Alternative Name extension or Common Name field that includes a Domain Name where .onion is in the right-most label of the Domain Name unless the Certificate was issued in compliance with this Appendix F.

等投票結束後再來看...

OpenSSL 的 ECDH 中,224 bits 速度比 160/192 bits 快的原因

openssl speed ecdh 的時候發現很特別的現象:

Doing 160 bit  ecdh's for 10s: 40865 160-bit ECDH ops in 9.99s
Doing 192 bit  ecdh's for 10s: 34169 192-bit ECDH ops in 9.99s
Doing 224 bit  ecdh's for 10s: 60980 224-bit ECDH ops in 9.99s
Doing 256 bit  ecdh's for 10s: 34298 256-bit ECDH ops in 10.00s
Doing 384 bit  ecdh's for 10s: 9602 384-bit ECDH ops in 10.00s
Doing 521 bit  ecdh's for 10s: 9127 521-bit ECDH ops in 9.99s

原因是 Google 這篇論文的貢獻:「Fast Elliptic Curve Cryptography in OpenSSL」,開頭就提到:

We present a 64-bit optimized implementation of the NIST and SECG-standardized elliptic curve P-224.

而實際成果:

full TLS handshakes using a 1024-bit RSA certificate and ephemeral Elliptic Curve Diffie-Hellman key exchange over P-224 now run at twice the speed of standard OpenSSL, while atomic elliptic curve operations are up to 4 times faster.

OpenSSLCHANGES 也可以看到對應的修改,不只是 NIST-P224 有被改善,其他的 NIST-P256 與 NIST-P521 也都有被改善:

Add optional 64-bit optimized implementations of elliptic curves NIST-P224, NIST-P256, NIST-P521, with constant-time single point multiplication on typical inputs.

頗特別的...

TLS 的效能分析

看到「Is TLS Fast Yet?」這個站台,開宗明義就講了,這不是問題:

TLS has exactly one performance problem: it is not used widely enough.

Everything else can be optimized.

下面的表格分析把對於效能影響的分析寫得很清楚,除了軟體外,還包括了各家 CDN 支援的分析,可以參考一下這邊的分析。

Google Chrome 釋出 40 版

在「Stable Channel Update」這邊看到 Google Chrome 釋出 40 版,除了修正了一卡車的安全性問題外,其實我是因為發現對於使用 SHA-1 certificate 的 SSL icon 又不一樣才發現的...

Plurk 的 domain 看一下:


以及 Imgur 的 domain:

參考 Gradually Sunsetting SHA-1 這篇文章的說明。

使用 SHA-1 SSL certificate,有效期間在 2016 年的會顯示黃色三角形 icon:

Sites with end-entity certificates that expire between 1 June 2016 to 31 December 2016 (inclusive), and which include a SHA-1-based signature as part of the certificate chain, will be treated as “secure, but with minor errors”.

而有效期超過 2016 年的 SHA-1 SSL certificate 會顯示沒有安全的標記:

Sites with end-entity certificates that expire on or after 1 January 2017, and which include a SHA-1-based signature as part of the certificate chain, will be treated as “neutral, lacking security”.

不過剛剛測了一下,EV SSL 好像不在此限?

GitHub 預定再兩個星期後廢止 HTTPS 連線的 RC4

GitHub 在「Improving GitHub's SSL setup」這邊開頭就提到要拔掉 RC4

To keep GitHub as secure as possible for every user, we will remove RC4 support in our SSL configuration on github.com and in the GitHub API on January 5th 2015.

看了一下日曆,算一算其實意思就是「放完假的星期一我們就來拔 RC4」XDDD

雖然 GitHub 的人說了 Windows XP + IE8 會沒辦法用,不過翻了「Qualys SSL Labs - Projects / User Agent Capabilities: IE 8 / XP」這頁,手動打開 TLS 1.0 後應該還有 TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa)TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x13) 這兩個用 3DES 的 cipher 可以掙扎才對?

不過看 GitHub 目前的 HTTPS 設定,看起來沒打算支援這兩個:「Qualys SSL Labs - Projects / SSL Server Test / github.com」以及「Qualys SSL Labs - Projects / SSL Server Test / github.com」。

不過順便把 3DES 踢出清單也是比較安全啦...

用 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

Archives