数字签名的一点疑惑

[rebeccaMyKid]

在看阮一峰的数字签名介绍，里面说：

通过替换客户端的公钥，然后再用对应的私钥，就可以欺骗客户端(具体怎么做到先不管，起码认证上能骗到了)，让客户端以为自己在跟预想的服务端通信。

（欺骗的通信公钥-私钥）

"道格想欺骗苏珊，他偷偷使用了苏珊的电脑，用自己的公钥换走了鲍勃的公钥。此时，苏珊实际拥有的是道格的公钥，但是还以为这是鲍勃的公钥。因此，道格就可以冒充鲍勃，用自己的私钥做成"数字签名"，写信给苏珊，让苏珊用假的鲍勃公钥进行解密。"

（欺骗的通信公钥-私钥 + 欺骗的 CA 公钥-私钥）

下面接着说如果有 CA 的存在，就能防止这个隐患。可我想，那同样不是可以把 CA 的公钥给换掉，再拿对应的私钥，里面放假的服务器公钥，就跟上面的引用相比，再做多一步欺骗，不也一样可以骗到？

[chinvo]

不然你以为为什么 CA 审计要求中对私钥的限制那么多

[rebeccaMyKid]

@chinvo

额，我是说，自己生成一对 CA 公钥-私钥对，然后把客户端的 CA 公钥换了，然后自己拿着欺骗的 CA 私钥，不就可以突破 CA 认证这一层了么？

[skyleft]

CA 的公钥不是那么容易换的 一般都是固定在系统里了

[chinvo]

@rebeccaMyKid #2 所以这就是为什么大家拒绝给自己的电脑装 12306 的 CA，并且不信任 CNNIC 和 WoSign 的 CA

自己信任来源不明的 CA 当然要自讨苦吃

[skyleft]

当然如果用户解除系统的限制 随便增加 CA 那就没办法了

[chinvo]

@skyleft #3 使用者是可以自己信任系统或软件没有内置的（根）证书的

[gy911201]

@rebeccaMyKid 怎么说呢，你都能在客户端上添加 CA 了，那么整个客户机对你来讲应该是处于一个不设防的状态了，此时在考虑什么链路安全是没有意义的事情了……

[rebeccaMyKid]

@chinvo 你这个说的是另外一个问题吧。假如我网站 A，是通过一个叫 B 的 CA 签的证书，那么你要骗过 CA 这层，就得把客户端里 B 的公钥换成自己的公钥，然后再用私钥去伪造一张数字证书。这样客户端就会认为从数字证书里拿到的通信公钥是可靠的。

[rebeccaMyKid]

@gy911201 哈哈哈。。好像有点道理，我较真了

[chinvo]

@rebeccaMyKid #8 你 #2 说的不就是这个问题么

[rebeccaMyKid]

@chinvo 对啊，但这个跟不信任“ 12306 的 CA，并且不信任 CNNIC 和 WoSign 的 CA ”，好像没什么关系？

[chinvo]

@rebeccaMyKid 因为 12306 的 CA 就是一个自签证书，和你的自签证书一个性质

而 CNNIC 和 WoSign 的 CA 则属于没有得到足够审计的证书，举例这两个则是说明 CA 体系最坚挺但是又最薄弱的环节

[rebeccaMyKid]

@chinvo 嗯，但是自签证书有什么关系呢，我在思考。。就是“数字证书不是由受信任的机构颁发的”，为什么会有问题，比如小明自己当 CA，自己签了一张证书，那我直接添加信任小明不就行了，小明又不可能去签百度的证书，就我的意思是，它影响不到别的，通过大 CA 签的证书。

求解~

[chinvo]

@rebeccaMyKid #13 所以这时你信任小明

公共 CA 也只不过是广受信任的自签证书

如果小明信用足够，他的 CA 也能被加进系统信任根列表

而保障他的可信程度的就是公开审计

[7654]

看看 moz 和 Google 为什么要吊销赛门铁克的证书，就是因为它私自乱发证书

[geelaw]

@rebeccaMyKid #13 如果小明 CA 可以通过一系列链条签发 baidu.com 的服务器认证证书，那就是可以签。

如果你访问 baidu.com 的时候没有检查 baidu.com 证书链条上的环节，那么可能误把小明签发出来的百度当成真的百度。

这检查工作是交给浏览器完成的，验证逻辑就是顺着链条看是不是受信 CA 发出来的。如果把证书放到你面前让你去看，你当然看得出来——因为是你自己检查的。但通常的用户（包括你我）看见软件自动检查通过就不去想了。

[rebeccaMyKid]

@geelaw

"如果小明 CA 可以通过一系列链条签发 baidu.com 的服务器认证证书，那就是可以签。"，嗯，这个学习了。
但是就算这样又如何，不是还有域名在么，那台要拿来骗人的服务器并不在百度服务器群里，就是说，用户通过*.baidu.com ，不会跟那台服务器有任何通信。

[chinvo]

@rebeccaMyKid #17 再加上中间人劫持或者 DNS 投毒

[rebeccaMyKid]

这个必须配合在 dns 上做手脚才行吧？通过*.baidu.com ，解析到我的（骗人的），通过认证的服务器上（而这个认证，就是这个 CA 要背锅的地方），是不是这么理解

[honeycomb]

@rebeccaMyKid 但是你要考虑到 CA 这个信任链不依赖也不能依赖 DNS （或者是其它形式的域名转网址服务）

或者说这里对 DNS 的要求是：它通常是正确的，且它一定会有一定频率作假／出问题。

所以现在会有 dnssec，试图用 CA 的方法来保证 DNS 返回的数据可供验证