Imgur 也漏資料了... (帳號與密碼)

Imgur 官方發佈公告說明他們發現資料洩漏了:「Notice of Data Breach」,資料的洩漏是發生在 2014 年,包括了帳號與密碼:

Early morning on November 24th, we confirmed that approximately 1.7 million Imgur user accounts were compromised in 2014. The compromised account information included only email addresses and passwords. Imgur has never asked for real names, addresses, phone numbers, or other personally-identifying information (“PII”), so the information that was compromised did NOT include such PII.

然後 2014 年用的是 SHA-256

We have always encrypted your password in our database, but it may have been cracked with brute force due to an older hashing algorithm (SHA-256) that was used at the time. We updated our algorithm to the new bcrypt algorithm last year.

以單台八張 GTX 1080hashcat 的速度來看 (出自「8x Nvidia GTX 1080 Hashcat Benchmarks」),是 23GH/z 左右:

Hashtype: SHA256

Speed.Dev.#1.: 2865.2 MH/s (96.18ms)
Speed.Dev.#2.: 2839.8 MH/s (96.65ms)
Speed.Dev.#3.: 2879.5 MH/s (97.14ms)
Speed.Dev.#4.: 2870.6 MH/s (96.32ms)
Speed.Dev.#5.: 2894.2 MH/s (96.64ms)
Speed.Dev.#6.: 2857.7 MH/s (96.78ms)
Speed.Dev.#7.: 2899.3 MH/s (96.46ms)
Speed.Dev.#8.: 2905.7 MH/s (96.26ms)
Speed.Dev.#*.: 23012.1 MH/s

這對於鍵盤可以打出的所有字元來計算 (95 chars),八個字的密碼只要 3.33 天就可以跑完;如果只考慮英文數字 (62 chars),九個字的密碼只要 6.81 天。

這些還不是最新的 GPU,而且是單機計算,對於現在的攻擊應該會用 ASIC,可以考慮多三到四個數量級的數度在算 (看財力才會知道買多少機器)。

不過 Imgur 的帳號主要是參與討論 (因為不用帳號密碼也可以上傳圖片),一般比較不會在上面註冊... 真的有註冊的因為沒有其他個資,主要是怕共用密碼的問題。如果有用 password manager 應該也還好。

GitHub 明年關閉 SSH 上 SHA1 相關的 Kx (Key Exchange) 演算法

GitHub 定下落日條款了:「Weak cryptographic standards deprecation update」。

這次目標是 diffie-hellman-group1-sha1diffie-hellman-group14-sha1,同時啟用了 diffie-hellman-group-exchange-sha256

Since the announcement, we have been focusing on the impact of disabling the diffie-hellman-group1-sha1 and diffie-hellman-group14-sha1 key exchanges for SSH. As of last week, we have enabled diffie-hellman-group-exchange-sha256. This key exchange method is widely supported and will allow most legacy clients to seamlessly transition away from diffie-hellman-group1-sha1 and diffie-hellman-group14-sha1.

明年二月拔掉 diffie-hellman-group1-sha1diffie-hellman-group14-sha1

This is a very small percentage of traffic, but we would like to see if we can reduce the incompatible traffic percentage even further before disabling support for the older key exchange algorithms on February 1, 2018.

Mozilla 對 WoSign 事件的決策 (草稿階段)

在「Mozilla 在考慮移除 WoSign 的 CA Root」這邊提到的事情,隨著時間的發展,大家發現事情愈來愈誇張。

在兩個小時前 MozillaGervase Markham 提出了對 WoSign + StartCom 處置的草稿:「WoSign and StartCom」,草稿在 Google Docs 上的「WoSign and StartCom」這邊可以看到。另外 Mozilla 在 wiki 上「CA:WoSign Issues」將 WoSign + StartCom 的事情都整理了出來,也是重要的資料。

文章很長,先講結論:目前 Mozilla 打算把 WoSign 與 StartCom 所簽出的 certificate 都照當年 CNNIC 的方式拔掉。

從頭說明,事情發生於八月底的時候 Google 通知了 Mozilla 一連串 WoSign 出包卻沒有主動通報的事件,當時知道的大約有三或四件。而在 不斷的討論的情況下,由於關注度變得超高,在搜尋大量的資料下發現更多問題,到現在 Mozilla 的 wiki 上已經列出了 13 個。

而這邊以 Mozilla 最後整理的草稿,將 13 個事件整合起來成幾件來說明:

WoSign and Back-Dated SHA-1

在瀏覽器會對 2016 後所簽出直接跳 error 的情況下 (像是「An update on SHA-1 certificates in Chrome」),直接偽造是 2015 年簽出的 certificate。

WoSign’s Ownership of StartCom

Mozilla 的 CA program 要求當公司擁有權轉移時必須揭露:

[...], Mozilla’s program requirements say that a change of CA ownership must be disclosed. In this case, that was not done - and in fact, the change was directly denied a few months after it happened.

直到最近被抓到而揭露後,發現 WoSign 所揭露的也不正確,StartCom 已經開始使用 WoSign 的 infrastructure 了:

More recently, even after the evidence of total control was public, WoSign referred to their interest in StartCom in a press release as “an equity investment”, and maintain that the two businesses continue to be separate even today. They say “the original system ... of StartCom remains unchanged”.

However, there is technical evidence that around a month and a half after the acquisition, StartCom issuances switched to using WoSign’s infrastructure - either the same instance of it, or their own instance.

而 Mozilla 要求 WoSign 提供他們產生 serial number 的程式碼時:(在 WoSign 簽出重複的 serial number 問題時得到的)

Mozilla asked WoSign how they generated their serial numbers, and was told that they used the Java package java.crypto.SecureRandom. They supplied the following code snippet:


However, as can be seen from this simple test harness, this code snippet does not produce serial numbers matching WoSign’s idiosyncratic pattern.

再度發現 WoSign 給的程式碼對不上。(hey)

然後再多方面分析後發現 WoSign 宣稱跟 StartCom 只共用 CRL/OCSP (revoke 機制) 是假的。Mozilla 由多方面判斷發現,至少程式碼是共用的 (i.e. clone),甚至猜測整個系統都是共用的 (在更後面提到):

We believe that, taken together, all this shows that StartCom’s certificates are now being issued using either WoSign’s existing infrastructure or a clone of it, and that WoSign’s operational control of StartCom began straight after the November 1st 2015 sale date. This evidence should be compared against WoSign’s recent assertion that “Even now, it still independent in the system, in the validation team and management team, we share the CRL/OCSP distribution resource only.”

SHA-1 Exceptions Process

再來是講一些背景。因為金流產業到了 2016 年還是有系統不支援 SHA-256 certificate,而 CA/Browser Forum 已經禁止簽發 SHA-1 憑證了,所以 2016 年二月的時候 WorldPay 跑上來尋求例外:

This became clear in February of 2016, where a payment processor called WorldPay applied to the CAB Forum for an exception so they could acquire 8 SHA-1 certificates to keep SSL working for their legacy payment terminals. Their CA was unable to help them because of the ban in the CAB Forum Baseline Requirements, and to issue in violation of the ban would lead to a “qualified” (not clean) audit, which might lead to browsers no longer accepting their audit as valid to keep them trusted.

而在亞利桑那的 face-to-face meeting 中剛好就討論了這點,允許 Symantec 簽發,而要提出來的是,WoSign 的 Richard Wang 也在場:

This issue was discussed at length in the CAB Forum face-to-face meeting from 16th-18th February 2016 in Scottsdale, Arizona (where Richard Wang of WoSign was present). Mozilla then had a public discussion about it in our policy forum starting on 23rd of February. In the end, the browsers reluctantly agreed to let Symantec issue these certificates for Worldpay - or rather, they agreed to accept that Symantec’s next audit would be qualified in this way.

所以 Mozilla 再次強調,當下大家的結論是特別許可,簽發被禁止的 SHA-1 certificate 是很嚴重違反規定的事情:

Even at this point, in February 2016, it was (or should have been) clear to all CAs, including WoSign, that issuing SHA-1 certificates in violation of the ban was a Very Big Deal, and that permission had to be sought from the browsers in order for the CA not to face difficulty.


接下來是 Tyro,這是一家澳洲金流廠商,直接複製草稿上的時間表:

Feb 3rd 2010GeoTrust issues a SHA-1 certificate for * from their Equifax root, valid until May 6th 2013.
Apr 6th 2013A month before their old cert expires, GeoTrust issues a replacement SHA-1 certificate for * from a GeoTrust root, valid until June 7th 2016. A simple roll-over replacement.
Jan 1st 2016SHA-1 issuance ban comes into effect.
May 24th 2016A month before their old cert expires, GeoTrust issues a SHA-256 certificate for * from a GeoTrust root, valid until June 23rd 2019.

但 Tyro 在 2016 年五月拿到的 SHA-256 憑證很明顯不合用,於是試著找 SHA-1 憑證... 結果不管怎樣,後來拿到了 StartCom 所簽出來的 SHA-1 憑證,而藉由技術上的 pattern 可以發現這是 back-dated (偽造日期簽發):

But the strong evidence is that this SHA-256 certificate did not meet Tyro’s needs. We can see a SHA-1 certificate for * which was logged in CT on June 8th 2016, a day after their previous SHA-1 certificate expired. This certificate is not issued by GeoTrust (who still provide the cert for their main website) or Comodo,’s usual providers, but by StartCom. And the notBefore date is that magic date of 20th December, 2015 - a date on which, as noted above, was closed for upgrading, and on which we have seen many Macau certificates issued by WoSign, which we believe are back-dated.


The SHA-1 certificate in question is still in use today on


最後 Mozilla 得到的結論:

  • StartCom are using WoSign’s infrastructure (the same or a clone);
  • Certificates on this infrastructure with a notBefore of 2015-12-20 (China time) are indeed back-dated - this further confirms our suspicions about the Macau certificates we saw issued by WoSign; and
  • StartCom’s hierarchy has been directed by management to mis-issue “WoSign-style”.

同時他們認為最後一點是最嚴重的一點,你必須將 StartCom 視為與 WoSign 完全同樣的公司,所有對 WoSign 的檢查與處置都必須相同對應到 StartCom 上:

This last point is important; the practices at WoSign are now being seen at StartCom. Therefore, we conclude that all of ownership, infrastructure and control are sufficiently common between the two companies that it would therefore be reasonable for any action Mozilla chooses to take against WoSign to also be taken against StartCom and vice versa.

另外一個很嚴肅的問題,CA 架構是建立在稽核機制上,而 WoSign 所選擇的稽核單位無法稽核出應有的「多個問題」:

WoSign’s auditors, Ernst & Young (Hong Kong), have failed to detect multiple issues they should have detected. (Issue J, Issue X)

提案的處理方式類似於 CNNIC 當時被拔掉的方式,針對某個日期之後的都不信任。這同時包括了 WoSign 與 StartCom 的 certificate。這真是可喜可賀啊...

OpenSSL 產生並簽出 SHA2 (SHA256) 的憑證

因為 Google Chrome 39 出來的關係,一些以前簽出來只包含 SHA-1 的 SSL certificate 因此導致了綠色 icon 變成黃色 icon,所以都要重簽一次產生 SHA-2 資訊。

有人說可以只要在簽名產生 crt 的部份做就好,不過這邊還是都提出來,並且給驗證的方式。

如果本來就已經有寫好 script,那麼只要在產生 csr 與簽名產生 crt 的步驟都加上 -sha256 就可以解決了。

這是產生 csr 的:(${HOST} 以及 subj 的內容自己代換)

openssl req -new -key ${HOST}.key -subj "/C=TW/ST=Taiwan/L=Taipei/O=MyOrganization/OU=MyUnit/CN=${HOST}" -sha256 -out ${HOST}.csr

而 csr 檢查的方式是:

openssl req -in ${HOST}.csr -text

看 Signature Algorithm 是不是 sha256WithRSAEncryption。

簽名產生 crt 也要加上 -sha256

openssl x509 -req -days 365 -in ${HOST}.csr -CA ca/ca.crt -CAkey ca/ca.key -sha256 -out ${HOST}.crt

而 crt 檢查的方式是:

openssl x509 -in ${HOST}.crt -text

一樣是看 Signature Algorithm 這邊是不是 sha256WithRSAEncryption。

產生 SHA256 的 SSL Certificate

在「Adding an (SHA256 signed) SSL certificate」這篇文章裡提到要如何簽出帶 SHA256 的 SSL certificate,重點在於要先生出有 SHA256 的 CSR,然後拿著這份給 CA 簽。

先照抄過來,看起來是有 encrypted 過的版本:

openssl genrsa -aes256 -out example-encrypted.key 2048
openssl rsa -in example-encrypted.key -out example-decrypted.key
openssl req -new -sha256 -key example-decrypted.key -out example.csr


openssl genrsa -out example.key 2048
openssl req -new -sha256 -key example.key -out example.csr

然後照著文章裡的說明輸入對應的資訊,然後拿著這份 CSR 檔給 CA 簽。


oclHashcat-plus 提供了透過 GPU 破解的 benchmark 數據:

可以看到 PBKDF2、sha512crypt $6$ 以及 bcrypt $2a$ 的速度慢得很漂亮 XD 不過 SHA512 的速度比 SHA256 慢不少倒是頗意外...

PBKDF2 的使用率很高 (因為無線網路 WPA/WPA2 的規格),所以各語言的普及率也高不少,如果要找個標準來用的話,PBKDF2 相當不錯...

FreeBSD Ports System 拿掉 MD5 檢查了...

在「MD5 for distinfo has been deprecated」這邊看到 FreeBSD Ports System 拿掉 MD5 檢查了 (會被忽略而不檢查)。

PR (Problem Report) 可以在「ports/149657: [] deprecate MD5 checksums in distinfo」查到。

翻了 cvs log,SHA256 是五年前 (2005) 加到 的:「Diff for /ports/Mk/ between versions 1.517 and 1.518」,總算在今天把 MD5 取代了:「Diff for /ports/Mk/ between versions 1.651 and 1.652」。