Home » Posts tagged "sha1" (Page 2)

微軟預定在 2017 年的西洋情人節淘汰 SHA-1 certificate

經過多次改動後,微軟這次宣佈 SHA-1 certificate 將在明年淘汰:「SHA-1 deprecation countdown」。

影響的範圍包括 Internet Explorer 11Microsoft Edge,在 2017 年 2 月 14 日之後不信任 SHA-1 certificate:

Starting on February 14th, 2017, Microsoft Edge and Internet Explorer 11 will prevent sites that are protected with a SHA-1 certificate from loading and will display an invalid certificate warning.

與其他家類似,還是提供了管道讓企業內部建立的 SHA-1 certificate 可以用:

This will only impact SHA-1 certificates that chain to a Microsoft Trusted Root CA. Manually-installed enterprise or self-signed SHA-1 certificates will not be impacted, although we recommend for all customers to quickly migrate to SHA-256.

Google Chrome 將在 2017 的 56 版停止支援 SHA-1 SSL Certificate

在明年一月的 Google Chrome 56 將會停止支援 SHA-1 SSL Certificate:「SHA-1 Certificates in Chrome」,唯一的例外是自己建立的 CA,主要是給企業內部用的:

Starting with Chrome 54 we provide the EnableSha1ForLocalAnchors policy that allows certificates which chain to a locally installed trust anchor to be used after support has otherwise been removed from Chrome.


Features which require a secure origin, such as geolocation, will continue to work, however pages will be displayed as “neutral, lacking security”.

使用 SHA-1 程式碼的完全移除預定在 2019 年 (大約兩年多):

Since this policy is intended only to allow additional time to complete the migration away from SHA-1, it will eventually be removed in the first Chrome release after January 1st 2019.

但如果對 SHA-1 攻擊有重大突破的話也會考慮提前:

We may also remove support before 2019 if there is a serious cryptographic break of SHA-1.

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.dev.security.policy 不斷的討論的情況下,由於關注度變得超高,在搜尋大量的資料下發現更多問題,到現在 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 *.tyro.com 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 *.tyro.com 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 *.tyro.com 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 *.tyro.com 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, tyro.com’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, StartSSL.com 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 https://iclient.tyro.com/.


最後 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。這真是可喜可賀啊...

Dropbox 儲存密碼的方式

記得 Dropbox 前陣子才強迫所有使用者重設密碼:「The Dropbox hack is real」,官方的報告在這:「Resetting passwords to keep your files safe」,當時洩漏出來的資訊可以知道 2012 年的時候 Dropbox 用的是 SHA1:

What we've got here is two files with email address and bcrypt hashes then another two with email addresses and SHA1 hashes.

三個多禮拜候,Dropbox 說明了現在的密碼儲存策略:「How Dropbox securely stores your passwords」,現在是先 SHA512,再 bcrypt,然後存在資料庫裡時使用 AES256 保護:

比較特別一點的是先 SHA512 的部份,除了 72bytes 常見限制外,另外一個原因是為了避免 DoS,不過還是覺得有點怪就是了:

Other implementations don’t truncate the input and are therefore vulnerable to DoS attacks because they allow the input of arbitrarily long passwords.

而 AES256 的部份則是確保就算 SQL injection 或是其他方式將儲存的密碼撈出去後,也還有相當程度的保護能力。

GitHub 提供更輕量的 Commit Reference SHA-1 API

GitHub 提供了新的 API 讓 client 可以更省網路資源,同時 GitHub 本身也可以省下 query。雖然是 Preview 期間,但已經有專案開始用了:「Commit Reference SHA-1 Preview Period」。


curl "https://api.github.com/repos/Homebrew/homebrew/commits/master" \
  -H "Accept: application/vnd.github.chitauri-preview+sha"

現在則可以加上 If-None-Match

curl "https://api.github.com/repos/Homebrew/homebrew/commits/master" \
  -H "Accept: application/vnd.github.chitauri-preview+sha" \
  -H "If-None-Match: \"814412cfbd631109df337e16c807207e78c0d24e\""

當本地與遠端的 SHA-1 值一樣時會收到 304,而且不會吃 rate limit quota:

If the remote and your local branch point to the same SHA-1 then this call will return a 304 Unmodified status code (and not use your rate limit).

尤其是當 commit reference 指到的 commit 特別大包時,可以省下很多資源...

微軟也宣佈 SHA-1 的 SSL certificate 將於 2016 年七月停用

在「SHA-1 Deprecation Update」這篇文章中宣佈本來在「Windows Enforcement of Authenticode Code Signing and Timestamping」這邊宣佈 2017 年停用 SHA-1 SSL certificate 的進度將提前到 2016 年七月 (到 2016 六月前仍然可以使用)。

在微軟的文章裡也有提到,如同 Mozilla 在前幾個禮拜宣佈的「Continuing to Phase Out SHA-1 Certificates」計畫,也是預定把 2017 年的淘汰計畫提前到 2016 年七月。

主要是因為「對 SHA-1 的攻擊進展」這邊提到對 SHA-1 的新攻擊,所以決定提前半年...

對 SHA-1 的攻擊進展

Bruce Schneier 這邊看到對 SHA-1 的攻擊又有新的進展了:「SHA-1 Freestart Collision」。

這次的論文不是真的找出 collision,而是對 internal compression function 攻擊,不過即使如此,這是首次攻擊完整的 80 rounds:

We present in this article a freestart collision example for SHA-1, i.e., a collision for its internal compression function. This is the first practical break of the full SHA-1, reaching all 80 out of 80 steps, while only 10 days of computation on a 64 GPU cluster were necessary to perform the attack.

論文資訊可以在「The SHAppening: freestart collisions for SHA-1」這邊看到。

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

Google Chrome 對只有 SHA-1 fingerprint 的淘汰過程

現在 Google Chrome 是 37 版,接下來的幾個版本會開始針對只有 SHA-1 fingerprint 的 SSL certificate 降低安全評價:「Gradually sunsetting SHA-1」。

這是 39 版預定的情況,會出現警告:

這是 40 版預定的情況,安全 icon 會消失:

而這是 41 版直接廢止的情況,當作不合法的 SSL certificate 處理:

另外,預先安裝的 root certificate 不受影響,因為並不是看 SHA-1 hash:

Note: SHA-1-based signatures for trusted root certificates are not a problem because TLS clients trust them by their identity, rather than by the signature of their hash.

整個過程大約會在 2015Q1 告一個階段。