25 | 固若金汤的根本（下）：数字签名与证书

保密性：靠混合加密解决，非对称加密实现对称加密秘钥传递，对称加密实现内容加密。 完整性：靠摘要算法解决。 身份认证：靠数字证书解决，数字证书因为CA机构的信任变成一个完整信任链条，从而实现通过数字证书证明了对方真实身份，但注意身份真实也可能是挂羊头卖狗肉，是一个坏人，所以，有了CRL、OCSP，还有终止信任。 不可否认：靠数字签名解决，内容摘要算法得到摘要，私钥加密摘要，对方使用对应公钥解密，得到摘要，再和自己得到的服务器提供的原文摘要对比，一致说明这个内容就是原服务器提供的，由证书说明了服务器的身份。 关于证书验证： 服务器返回的是证书链（不包括根证书，根证书预置在浏览器中），然后浏览器就可以使用信任的根证书（根公钥）解析证书链的根证书得到一级证书的公钥+摘要验签，然后拿一级证书的公钥解密一级证书拿到二级证书的公钥和摘要验签，再然后拿二级证书的公钥解密二级证书得到服务器的公钥和摘要验签，验证过程就结束了。

看了几遍大概了解为什么要这样加密的过程了 ↓ 对称加密（有密钥交换的问题） ↓ 非对称加密（基于复杂的数学难题，运行速度很慢） ↓ 混合加密（怎么保证完整性？不被修改？） ↓ 摘要算法（无法保证是用户自己） ↓ 数字签名（公钥怎么保证安全正确的？） ↓ 数字证书、CA

重放和篡改的问题没有提，黑客是解不开秘文，但是可以重复发送，需要时间戳和随机数再合起来做一个不可逆的签名，服务端收到重复的就丢弃

看完老师的文章有点迷惑，主要是没搞清完整的流程，又去找资料看了一下，说下自己的理解，老师看看对不。 数字签名和数字证书只用于TSL/SSL的握手阶段，主要是保证服务器的公钥能够正确地传给浏览器（不被中间人伪装发送假的公钥） 具体流程大概是： 1、服务器去CA机构申请证书，证书中包含了要发给客户端的公钥、签发者、到期时间等等信息。如果这样简单地把证书发给浏览器，中间人可以轻松地修改成自己的公钥，之后的通信就是不安全的了。于是需要一定的加密手段，这里的做法就是使用数字签名：将证书的信息利用摘要算法计算出摘要之后，用CA的秘钥进行加密，生成数字签名。 2、服务器将数字证书和数字签名一起发给浏览器，因为有数字签名，所以数字证书无法被中间人做修改（修改之后生成的数字签名无法被CA公钥解密），浏览器拿到数字证书之后，去本地的信任机构中查询到对应的机构，利用其公钥解密数字签名，验证证书是否有被修改过。这一步就保证了浏览器获取到的公钥一定是正确的。 3、公钥正确地传给浏览器之后，接着就是协商对称加密的密钥，然后通信等等.. 参考： http://www.ruanyifeng.com/blog/2011/08/what_is_a_digital_signature.html https://www.zhihu.com/question/52493697

问题1. 非加密算法需要公开公钥从而让客户端能解密。如果用对称加密，加密秘钥公开，就达不到加密效果了 问题2. 客户端发现当前网站的证书是二级CA，在可信任签发机构中找不到，就会去拿二级CA的数字证书的签发机构去做检查，发现它是一级CA，也不在可信任签发机构中，再找一级CA的数字证书的签发机构，发现是受信任的ROOT CA，至此完成验证。如果到最后一层CA都不受信任，就会警告用户

为什么公钥能够建立信任链，用对称加密算法里的对称密钥行不行呢？ 所谓建立信任链， 是指发送方相信公钥确实是接收方的。因为有CA的信任链和最后根CA的背书。 用对称密钥行不行呢？ 用对称密钥来确认公钥的真实性，就好像是街头对暗号。 A:枯藤老树昏鸭 B:穿条秋裤回家。 这样做确实可以确认“你就是你”，可问题是如何交换密钥呢？ 问题就又绕回到了非对称密钥了。 假设有一个三级的证书体系（Root CA=> 一级 CA=> 二级 CA），你能详细解释一下证书信任链的验证过程吗？ 没有具体实战过，我猜测如下： 二级CA交给了浏览器，CA说：“我是某宝，这是我的公钥，这个一级CA给我背书了，　你要相信我！” 浏览器再去确认这个一级CA可不可信，一级CA说：“我是公安局，这是我的公钥，这个根CA给我背书了，　你要相信我！” 浏览器再去确认这个根CA可不可信，根CA说：“我是上帝我说了算，你爱信不信”。浏览器也很无奈啊。。。只能信了。

假设有一个三级的证书体系（Root CA=> 一级 CA=> 二级 CA），你能详细解释一下证书信任链的验证过程吗？---注服务器的证书由二级CA签发。 修订的第三版，这个解答相对更完善。。。 TLS协商阶段，在交换完Client Hello/Server Hello消息后，发送方【通常是服务器】，发送Certificate消息，把证书链，包括自己的证书，二级CA证书，一级CA证书，一次性发送给接收方【通常是浏览器】。 注：每个传递过来的证书包括4部分 signedCertificate签名的证书，即浏览器点击小锁头直观可以看到的证书 algorithmIdentifier算法标记，包括了签名证书用到的摘要和签名算法，如sha256WithRSAEncryption Padding填充字符 encrpted加密摘要，注：加密摘要不包含在signedCertificate中，所以浏览器中点击小锁头看不到加密摘要。 当前接收方只有内置的Root Ca根证书，无法直接信任接收方的证书。接收方将通过证书链中包含的签发者信息，逐层向上查找直到Root Ca根证书，并从根证书开始，逐级向下做验签。首先，用根证书对一级证书做验签。具体过程是，对一级CA证书【signedCertificate】用传递过来的摘要算法【algorithmIdentifier】做摘要得到摘要1；用Root Ca根证书的公钥解密一级CA证书的数字签名【encrpted】，得到发送过来的摘要2，二者比较，如一致，则认为一级CA证书是真实有效的。类似的，继续用一级CA证书对二级CA证书做验签，二级CA证书对发送方证书做验签，如果发送方证书验证通过，则随之TLS协商进入Server key exchange阶段。

对于第二个问题证书链验证的过程，有些不理解的地方，请老师指教，您在文章说“操作系统和浏览器都内置了各大 CA 的根证书，上网的时候只要服务器发过来它的证书，就可以验证证书里的签名，顺着证书链（Certificate Chain）一层层地验，直到找到根证书”，服务器只返回了他的证书（假如返回的是二级证书），浏览器内置的是根证书（根公钥）使用根公钥只能解密根机构签名的证书，无法解密二级证书，使用一级证书（公钥）才能解密二级证。那么浏览器是怎么自下向上层层解析到根证书？我的理解的是服务器返回的是证书链，然后浏览器就可以使用信任的根证书（根公钥）解析证书链的根证书得到一级证书的公钥+摘要验签，然后拿一级证书的公钥解密一级证书拿到二级证书的公钥和摘要验签，再然后拿二级证书的公钥解密二级证书得到服务器的公钥和摘要验签，验证过程就结束了。谢谢！

到这里完全爆炸了

HTTPS四大特性机密性、完整性、身份认证、不可否认，我不是能够很好地说服我自己： 如何实现机密性？ 对称加密加密解密都用同一个秘钥，但是问题是这个秘钥的交换传输问题，我们无法保证在传输过程中有没有人修改我们的秘钥。 非对称加密分为公钥和私钥，我们可以随便散播我们的公钥，用私钥加密，但是问题是基于复杂的数学难题，所以速度比较慢。 所以我们可以用混合加密，用非对称加密的私钥加密对称加密的秘钥（即会话秘钥），这样客户端可以用服务端散播的公钥解密得到会话秘钥，以后传输过程中就用这个会话秘钥来传输。 但是这个时候，我们依旧无法保证我们拿到的会话秘钥是完整的，未经篡改的，黑客完全可以劫持我们传递私钥的这个报文，乱改一通，所以我们需要进一步实现完整性。 如何实现完整性？ 我们用摘要算法对原文(这里也就是会话秘钥)生成摘要指纹，然后用私钥加密（会话秘钥+秘钥的摘要指纹）发出去，此时客户端收到报文后，用公钥解密报文，理想情况下，还是原文+摘要的形式，这时我们用相同的摘要算法去计算原文，进行摘要对比，只要相同，那就可以保证完整性了。如果黑客在中间修改了报文，那么按照摘要算法的雪崩效应，最终是可以确定原文被修改，或者干脆就不符合格式，也就不安全了。 然后又出现了两端安全的问题？就是如何确定服务器就是那个服务器。 因为非对称加密的私钥是独有的，可以以此作为基准。我们用私钥把我们之前得到的原文（会话秘钥）的摘要再进行加密，秘钥的加密只能用公钥解开，所以客户端收到内容后，先用公钥解开当前的内容，得到的东西是原文+秘钥加密的摘要，我们再用摘要算法去算原文的摘要，用公钥再解密出服务器给我们的摘要，两相对比，如果相同，就验证了两个端点安全且内容完整未经篡改。 但是我这里有一个疑惑，这一步到底意义是什么呢？我觉得这样做只能说明公钥和私钥的对应性，充其量只能证明确实是这两个端点在通信，中间没有被篡改。那么这相当于上一步到底多出来的实际意义是什么呢？我们就算不用私钥去加密原文的摘要，实际上客户端收到报文后既然能用公钥解密出原文和摘要，并直接进行认证，也能证明两个端点公钥和私钥的一一对应吧？我甚至觉得这一步是多余的。这里希望老师解惑。 其实最关键的还是证明公钥的来源是正确的，举个������，也就是你必须确认你拿到的是淘宝的公钥。 这里我假设上面进行身份认证的签名和验签是能够说服我的，好，解决公钥来源正确的方法是引入CA。 那么CA到底是什么呢？我感觉有点理解困难。按照之前的说法，签名是指对某个摘要使用私钥进行加密的过程，验签则是用与这个私钥对应的公钥解密出摘要并进行摘要对比的过程。 那么CA对什么进行签名呢？我们把公匙、有效时间、序列号等相关信息交给CA，CA会用它的绝对保密的私钥对这些信息进行打包后加密，即签名（这里是不是就是用摘要算法做了一个指纹然后用私钥加密原文信息+摘要？？），形成淘宝独有的数字证书。 好，那我第二个问题来了，CA的私钥既然是绝对保密的，那我就把CA的私钥理解成是在服务器外的一个地方，请问我们如何把我们的公钥、序列号这些信息安全地送到CA处，并且安全地收回来？ 还有，数字证书是相当于被送回到了服务器了吗？也就是说，之前我们都是散播我们的公钥，现在变成了我们四处散播我们的数字证书？ 我们每次登陆网站，比如登陆淘宝网，是不是相当于我们拿到了这个网站发给我们的数字证书，然后我们用内置保存在操作系统和浏览器中的CA的公钥去解密数字证书，还原成（公匙+序列号等）原文信息+摘要，然后要摘要算法计算原文信息进行比对，只要对上了，我们就能根据序列号一些信息，保证我们访问的就是淘宝网？ 然后这个CA的证书体系树到底是什么？是不是其实CA机构散播的也是他们的数字证书，也就是说我们保存在操作系统和浏览器中的也是他们的数字证书？我们证明淘宝网的数字证书需要上一层CA的数字证书，但是CA的数字证书也需要证明，所以需要更上一层的CA的数字证书，所以往上找回找到根证书，我们必须相信，不然信任链走不下去了。 那么我有问题，上面文章中讲了，我们浏览器和操作系统只内置了各大CA的根证书，那么如果淘宝网的数字证书是由一个三级证书认证的，那请问这个三级证书那里来？我们去哪里找？？ 好了，假设上面的信任链走通了，我们确定了我们拿到的就是淘宝网的公钥，我们解密出了原文，在现在的分析中，也就是对称加密的会话秘钥，也验证了完整性，我们要开始用这个会话秘钥开始通信了，那么我想知道现在用会话秘钥加密传输这个过程中就没有完整性、身份认证、不可否认的问题了吗？？