罗剑锋透视HTTP协议学习笔记---25 | 固若金汤的根本（下）：数字签名与证书

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

黑客虽然拿不到会话密钥，无法破解密文，但可以通过窃听收集到足够多的密文，再尝试着修改、重组后发给网站。因为没有完整性保证，服务器只能“照单全收”，然后他就可以通过服务器的响应获取进一步的线索，最终就会破解出明文。

—这里说的是对称加密的安全性和算法，秘钥长度，分组模式相关。比如以AES128-ECB方式加密，明文特征无法被隐藏，容易被破解；AES-CBC缺少hmac，无法保证消息的完整性；所以安全套件通常选AES-GCM，明文特征被隐藏并带有hmac，所以数据完整性是通过hmac保证的，而hmac和特定分组方式相关,另外GCM是对密文用对称秘钥做哈希摘要，不同于一般的无参数的哈希算法[参考陶辉72讲]

摘要算法解决数据完整性问题
算法SHA2
特点，对数据进行处理后生成一个定长的字符串，此字符串具有唯一性，原文微小的变动都会引起字符串剧烈的变动。【雪崩效应】
流程
原文+SHA2哈希码加密后传送到接收端，解密后，取得原文和哈希码，对原文进行SHA2哈希计算，结果和原哈希码比较，如果一致则说明原文在传输中没有被篡改。

数字签名和验签的原理图：

首先要澄清一个概念，数字签名对应与现实世界的签名，是对某文件条款内容的认同。数字签名及验签过程中传递两样东西，原文和摘要，原文是明文，不加密，摘要要用私钥加密。
过程是
0. 上图是原理图，具体到TLS握手，证书通过Certificate消息发送，包括了公钥，有效期等信息【原文】和指纹【数字签名】
1. 发送方根据原文【消息的signedCertificate部分】算出摘要，并用私钥加密，得到数字签名，和原文一同发给对端。
2. 接收方用公钥解密数字签名【消息的encrpted小节】，得到发送方传递过来的摘要
3. 接收方对原文做摘要，并比对2份摘要，如果一致，则证明发送方的身份是公钥的所有者。
注：encrpted是加密的签名而网站上直接查看的指纹是解密后的签名，所以对不上。

数字签名和数字证书
数字证书是由CA背书并签发的证明文件，包括了被签发者的公钥和版本，签发者，有效期，序列号，用途等信息【原文】，打包后再用CA的私钥签名，以证明被签发者的身份。
数字签名对应现实世界的签名，签名者自己证明其有效性，但他人无法确保其真实性。因为签名可以伪造，或当事人有恶意。
数字证书对应现实世界的证书，比如身份证，毕业证，由权威机构背书，证明其真实性，按级别分为DV,EV,OV.

证书类别
DV[Domain validated]
OV[organization validated]
EV[extended validation]
三种证书的安全强度是一致的，只是对申请者的审核严格程度逐步加强。

课后作业：

为什么公钥能够建立信任链，用对称加密算法里的对称密钥行不行呢？
不行，对称加密无法解决秘钥传递问题
而公钥的信任链中有个各方都信任的Root 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阶段。

附：数字证书验签流程图

整个证书的验证流程是
通过Issuer’s–Owner’s获得证书链的所有证书,根证书是内置的，CA,Owner的证书是随Certificate发送的
根证书验证CA
CA验证Owner
验证的依据是用上级证书的公钥验证下级证书的签名