教你全面图解 https 加解密原理( 二 ) _https

文章插图

服务端选中的加密套装叫
TLSECDHERSAWITHAES128GCM_SHA256，这一串的意思是：

密钥交换使用 ECDHE
证书签名算法 RSA
数据加密使用 AES 128 GCM
签名校验使用 SHA256

接着服务给客户端发来了 4 个证书：

文章插图

第一个证书的公用名（common name）就是我们当前访问的域名 developer.mozilla.org 。
如果公用名是 *.mozilla.org 的话那么这个证书便能给 mozilla.org 的所有二级子域名使用。
第二个证书是第一个证书的签发机构（CA）的证书，它是 Amazon，也就是说 Amazon 会用它的私钥给 developer.mozilla.org 进行签名。
依此类推，第三个证书会给第二个证书签名，第四个证书会给第三个证书签名，并且我们可以看到第四个证书是一个根（Root）证书。
一个证书里面会有什么东西呢，我们可以展开第一个证书看一下，如下图所示：

文章插图

证书包含三部分内容：

tbsCertificate（to be signed certificate）待签名证书内容
证书签名算法
CA 给的签名

也就是说 CA 会用它的私钥对 tbsCertificate 进行签名，并放在签名部分。为什么证书要签名呢？签名是为了验证身份。
身份验证我们先来看一下 tbsCertificate 里面有什么内容，如下图所示：

文章插图

它里面包括了证书的公钥、证书的适用公用名、证书的有效期还有它的签发者等信息。
Amazon 的证书也具备上述结构，我们可以把 Amazon 证书的公钥拷出来，如下图所示：

文章插图

中间有一些填充的数字，用灰色字表示。可以看到N通常是一个很大的整数（二进制 2048 位），而 e 通常为 65537 。
然后我们用这个 CA 的公钥对 mozilla.org 的证书签名进行解密，方法和上面的类似：

文章插图

取解密后的数字 decrypted 的十六进制的末 64 位，即为二进制 256 位的 SHA 哈希签名。
接下来我们手动计算一下 tbsCertificate 的 SHA256 哈希值，方法是在 wireshark 里面把 tbsCertificate 导出一个原始二进制文件：

文章插图

然后再使用 openssl 计算它的哈希值，如下所示：

liyinchengs-MBP:https liyincheng$ openssl dgst -sha256 ~/tbsCertificate.binSHA256(/Users/liyincheng/tbsCertificate.bin)= 5e300091593a10b944051512d39114d56909dc9a504e55cfa2e2984a883a827d

我们发现手动计算的哈希值和加密后的证书里的哈希值一致！说明只有知道了 Amazon 私钥的人才能正确地对 mozilla.org 的证书签名，因为公私钥是唯一匹配的。
因此我们验证了第一个证书 mozilla.org 确实是由第二个证书 Amazon 签发的，使用同样的方式，我们可以验证 Amazon 是由第三个签发的，第三个是由第四个根证书签发。
并且第四个证书是根证书，它是内置于操作系统的（通过 mac 的 keychain 工具可以查看）：

文章插图

假如 Hacker 通过 DNS 欺骗之类的方式把你访问的域名指向了他的机器，然后他再伪造一个证书。
但是由于根证书都是内置于操作系统的，所以它改不了签名的公钥，并且它没有正确的私钥，只能用自己的私钥，由于公私钥不配对，很难保证加解密后的信息一致。
或者直接把浏览器拿到的证书搬到他自己的服务器？这样再给浏览器发的证书便是一模一样，但是由于他不知道证书的私钥，所以无法进行后续的操作，因此这样是没有意义的。
这个就是 HTTPS 能够验证身份的原理。另外一个例子是 SSH，需要手动验证签名是否正确。
例如通过打电话或者发邮件等方式告知服务器的签名，与自己算的证书的签名是否一致，如果一致说明证书没有被篡改过（如证书的公钥没有被改为 Hacker 的公钥）：