// Process the message in successive 512-bit chunks:
for each 512-bit chunk of padded message do
// ...
// Add this chunk's hash to result so far:
a0 := a0 + A
b0 := b0 + B
c0 := c0 + C
d0 := d0 + D
end for
var char digest[16] := a0 append b0 append c0 append d0 // (Output is in little-endian)
本來只有 S = H(secret || message),你在不知道 secret 的情況下就可以疊字串到後面而且算出對應的 hash 值,變成 S' = H(secret || message || evildata)。
維基百科給的例子也示範了怎麼「用」,這是原始的資料以及 server 端簽出來的 hash 值:
Original Data: count=10&lat=37.351&user_id=1&long=-119.827&waffle=eggo
Original Signature: 6d5f807e23db210bc254a28be2d6759a0f5f5d99
於是我們想要蓋 waffle 參數,就變成:
Desired New Data: count=10&lat=37.351&user_id=1&long=-119.827&waffle=eggo&waffle=liege
攻擊者則可以不斷的嘗試,去猜測 padding 的結構,把計算出來對應的 hash 值丟到 server 看反應,直到看到 200 OK 的回應:
New Data: count=10&lat=37.351&user_id=1&long=-119.827&waffle=eggo\x80\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x28&waffle=liege
New Signature: 0e41270260895979317fff3898ab85668953aaa2
如同前面提到的,這是 hash function 在最後把內部狀態直接暴露出來造成的問題,在 MD5、SHA-1、SHA-2 (SHA-256、SHA-384、SHA-512) 都有類似的問題,而比較新的 hash function 在設計時就已經有考慮到了,不會出現這個問題,像是 SHA-3。
另外一方面,不要自己發明演算法,使用標準的 MAC 演算法通常是比較好的選擇。這邊用的比較廣泛的應該就是 HMAC,超過 25 年了。
Bjarmason pointed out that there is still no interoperability between SHA-1 and SHA-256 repositories, and that none of the Git hosting providers appear to be supporting SHA-256.
這點導致了目前場上看的到的服務與 open source 軟體都沒有支援的計畫,這點算是一個超級失敗的 transition plan。
這應該是第一次要把手上的專案跳 minor version 升級,看起來應該是還好,但天曉得會有什麼狀況... 看起來主要會是 sha1 要被換成 sha256 會有影響到。
另外看到這個:
SimpleTestCase now implements the debug() method to allow running a test without collecting the result and catching exceptions. This can be used to support running tests under a debugger.
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.
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.
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.
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.
從頭說明,事情發生於八月底的時候 Google 通知了 Mozilla 一連串 WoSign 出包卻沒有主動通報的事件,當時知道的大約有三或四件。而在 mozilla.dev.security.policy 不斷的討論的情況下,由於關注度變得超高,在搜尋大量的資料下發現更多問題,到現在 Mozilla 的 wiki 上已經列出了 13 個。
[...], 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.
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.
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.”
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.
GeoTrust issues a SHA-1 certificate for *.tyro.com from their Equifax root, valid until May 6th 2013.
Apr 6th 2013
A 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 2016
SHA-1 issuance ban comes into effect.
May 24th 2016
A month before their old cert expires, GeoTrust issues a SHA-256 certificate for *.tyro.com from a GeoTrust root, valid until June 23rd 2019.
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.
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”.
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.