聯想與 Superfish 的法律訴訟,以及後續的發展...

在「Download.com and Others Bundle Superfish-Style HTTPS Breaking Adware」這邊看到的 tweet,講的相當經典,把他找出來:

文章裡面提到,Superfish 這種插入 CA root certificate 的軟體攔截 HTTPS 內容,不僅僅是 Superfish,這根本是目前免費軟體的「趨勢」,包括了十大裡面的前兩名:

Two of the top ten downloads on CNET (KMPlayer and YTD) are bundling two different types of HTTPS-hijacking adware, and in our research we found that most other freeware sites are doing the same thing.

Facebook 的「Windows SSL Interception Gone Wild」提到了 Facebook 自己觀察到的情況:(SSL traffic 被 Superfish 換掉的百分比,中國地區因為廣為人知的原因,是沒有偵測到的...)

另外「Beyond Superfish: Turns out SSL-trashing spyware is widespread」也提到問題的嚴重性。

甚至有些也偽裝成遊戲:「'Superfish'-style vulnerability found in games and parental control software」:

Rogers cites products including parental control software and IP-cloaking technology as containing the weakness, while Richard says Facebook discovered the certificates being issued by a number of adware vendors disguised as games or search assistants.

實際用 Google Chrome 下載 CNET 上的 KMPlayer,發現直接擋了下來:

在之後的新版則會更明顯的顯示出來:「More Protection from Unwanted Software」。

然後是訴訟的問題,在美國已經有消費者決定對聯想與 Superfish 打集體訴訟了,後續的判賠與和解可以繼續追蹤:「Lenovo hit with lawsuit over Superfish snafu」。

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

Google 將之前買下 Skybox 公司的工具放出來 (MapReduce for C)

Zite 上看到的,Google 把之前買下的 Skybox 所開發的工具 MapReduce for C (MR4C) 放出來:「Google open sources a MapReduce framework for C/C++」。

MR4C 的程式碼放在 GitHub 上,以 Apache License Version 2.0 授權放出來:「google/mr4c」。

用 Google Analytics 偵測有多少使用者使用 Adblock

在「Find How Many Visitors Are Not Seeing Ads on your Website」這篇介紹了如何用 Google Analytics_trackEvent 偵測網站上有多少使用者使用 Adblock 類的軟體。

不過這完全會低估啊,會在意廣告而裝 Adblock 類的人之中,不少人還會順便擋掉 Google Analytics 啊 XD

不過這篇有提到一份報告,說 2014 整個 internet 使用 Adblock 的比率大約是 5%,而科技類網站會高出更多:(不過我抓不動這份 PDF...)

It is estimated that ~5% of website visitors are blocking ads (PDF report) and the situation could be far worse for websites that have a more tech-savvy audience.

Google 的 Project Zero 修正 Policy

在之前受到批評後,GoogleProject Zero 修正了對應的 Policy:「Feedback and data-driven updates to Google’s disclosure policy」。

原先的 Policy 是 90 天強制公開,修正的 Policy 有幾個改善:

  • 如果揭露日是週末或是美國的假日,會順延到下一個工作日。
  • 如果原廠有告知需要更多時間修復,Project Zero 會延長 14 天的寬限期。
  • 在公開前會申請對應的 CVE 號碼。

記錄 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 處理了,就像是這樣:(原文的範例)

Google Chrome 將會用 HTTP/2 取代 SPDY

Google Chrome 將會在接下來幾個星期的 40 版支援 HTTP/2 (現在已經是 40 版了,所以照這個說法應該是 41 一定會有?),並且在 2016 年拿掉對 SPDY 的支援:「Hello HTTP/2, Goodbye SPDY」。

接下來又是大量的 migrate 了:

We plan to remove support for SPDY in early 2016, and to also remove support for the TLS extension named NPN in favor of ALPN in Chrome at the same time. Server developers are strongly encouraged to move to HTTP/2 and ALPN.

在「Implementations」這邊可以看到 HTTP/2 支援的程度,包括了 client 與 server 的部份。

利用 WebRTC 取得瀏覽器端的 IP address

TorrentFreak 上看到的:「Huge Security Flaw Leaks VPN Users' Real IP-Addresses」。

可以在「https://diafygi.github.io/webrtc-ips/」這邊測試,就算你在 NAT 以及 VPN 後面也可以取得真實的 Public IP 資訊。

Google Chrome 的使用者可以裝「WebRTC Block」阻擋 WebRTC,而 Firefox 則可以透過 about:config 的設定關閉 media.peerconnection.enabled 這個值:

目前還不太會用到 WebRTC,先擋起來之後再說...

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 好像不在此限?