半肾
精华
|
战斗力 鹅
|
回帖 0
注册时间 2006-5-29
|
本帖最后由 nonmoi 于 2015-4-18 13:21 编辑
1. 之前其它发生同样事故、造成更大损害的CA没有受到同等程度的处理。
2. Google对其决定的原因语焉不详，甚至在公报中可以说是自我矛盾。
3. 实际造成事故的错误方不是CNNIC，而且CNNIC给的本来就是只有两周寿命的零时证书，可以说在管理方面远强于有过同类问题的其它CA。
4. 并没有任何证据证明CNNIC对Google的调查不配合，Google自己在公报中甚至肯定了CNNIC的配合。
5. 微软和苹果没有跟进，Chrome和FF的“吊销”根证书也是针对未来的证书发布，如果CNNIC真有历史问题，难道不是应该不支持其已经发布的证书，而不是白名单进行兼容么？
综合上面几点，如果不考虑屁股，就事论事的话，Google拒绝继续信任CNNIC根证书的决定是合理的么？
因为有可能吸引政治厨或者狗粉洗地，这里先声明，本人一两年前就自主删除了CNNIC的证书，更对你们亮明屁股这件事毫无兴趣。（即，请不要说什么“CNNIC天天喂shi，早就该si。”或者“Chrome是Google的产品，爱咋样都是Google的权力。”）本帖旨在探寻网络安全技术和政策方面的问题的答案，本人也不是技术方面的专家，在此仅是抛砖引玉，预先感谢大家的配合。
Google公报全文：
Maintaining digital c**ificate security
Posted: Monday, March 23, 2015
Posted by Adam Langley, Security Engineer
On Friday, March 20th, we became aware of unauthorized digital c**ificates for several Google domains. The c**ificates were issued by an intermediate c**ificate authority apparently held by a company called MCS Holdings. This intermediate c**ificate was issued by CNNIC.
CNNIC is included in all major root stores and so the misissued c**ificates would be trusted by almost all browsers and operating systems. Chrome on Windows, OS X, and Linux, ChromeOS, and Firefox 33 and greater would have rejected these c**ificates because of public-key pinning, although misissued c**ificates for other sites likely exist.
We promptly al**ed CNNIC and other major browsers about the incident, and we blocked the MCS Holdings c**ificate in Chrome with a CRLSet push. CNNIC responded on the 22nd to explain that they had contracted with MCS Holdings on the basis that MCS would only issue c**ificates for domains that they had registered. However, rather than keep the private key in a suitable HSM, MCS installed it in a man-in-the-middle proxy. These devices intercept secure connections by masquerading as the intended destination and are sometimes used by companies to intercept their employees’ secure traffic for monitoring or legal reasons. The employees’ computers normally have to be configured to trust a proxy for it to be able to do this. However, in this case, the presumed proxy was given the full authority of a public CA, which is a serious breach of the CA system. This situation is similar to a failure by ANSSI in 2013.
This ex**ation is congruent with the facts. However, CNNIC still delegated their substantial authority to an organization that was not fit to hold it.
Chrome users do not need to take any action to be protected by the CRLSet updates. We have no indication of abuse and we are not suggesting that people change passwords or take other action. At this time we are considering what further actions are appropriate.
This event also highlights, again, that the C**ificate Transparency effort is critical for protecting the security of c**ificates in the future.
(Details of the c**ificate chain for software vendors can be found here.)
Update - April 1: As a result of a joint investigation of the events surrounding this incident by Google and CNNIC, we have decided that the CNNIC Root and EV CAs will no longer be recognized in Google products. This will take effect in a future Chrome update. To assist customers affected by this decision, for a limited time we will allow CNNIC’s existing c**ificates to continue to be marked as trusted in Chrome, through the use of a publicly disclosed whitelist. While neither we nor CNNIC believe any further unauthorized digital c**ificates have been issued, nor do we believe the misissued c**ificates were used outside the limited scope of MCS Holdings’ test network, CNNIC will be working to prevent any future incidents. CNNIC will implement C**ificate Transparency for all of their c**ificates prior to any request for reinclusion. We applaud CNNIC on their proactive steps, and welcome them to reapply once suitable technical and procedural controls are in place.
其中提到的类似事件的公报全文：
Further improving digital c**ificate security
Posted: Saturday, December 7, 2013
Posted by Adam Langley, Security Engineer
Late on December 3rd, we became aware of unauthorized digital c**ificates for several Google domains. We investigated immediately and found the c**ificate was issued by an intermediate c**ificate authority (CA) linking back to ANSSI, a French c**ificate authority. Intermediate CA c**ificates carry the full authority of the CA, so anyone who has one can use it to create a c**ificate for any website they wish to impersonate.
In response, we updated Chrome’s c**ificate revocation metadata immediately to block that intermediate CA, and then al**ed ANSSI and other browser vendors. Our actions addressed the immediate problem for our users.
ANSSI has found that the intermediate CA c**ificate was used in a commercial device, on a private network, to inspect encrypted traffic with the knowledge of the users on that network. This was a violation of their procedures and they have asked for the c**ificate in question to be revoked by browsers. We updated Chrome’s revocation metadata again to implement this.
This incident represents a serious breach and demonstrates why C**ificate Transparency, which we developed in 2011 and have been advocating for since, is so critical.
Since our priority is the security and privacy of our users, we are carefully considering what additional actions may be necessary.
[Update December 12: We have decided that the ANSSI c**ificate authority will be limited to the following top-level domains in a future version of Chrome:
.fr
.gp (Guadeloupe)
.gf (Guyane)
.mq (Martinique)
.re (Réunion)
.yt (Mayotte)
.pm (Saint-Pierre et Miquelon)
.bl (Saint Barthélemy)
.mf (Saint Martin)
.wf (Wallis et Futuna)
.pf (Polynésie française)
.nc (Nouvelle Calédonie)
.tf (Terres australes et antarctiques françaises)]
|
|
沪公网安备 31010702007642号 )
发表于 2015-4-18 10:46
