网络安全篇，面对复杂多变的网络环境，我们需要掌握哪些关于网络安全的相关知识，聊一聊与网络安全相关的：HTTPS、SSL、TLS 等。
在介绍今天的内容之前，我们先来回顾下保证安全的四大特性：机密性、完整性、身份认证和不可否认；到目前为止，综合使用对称加密、非对称加密和摘要算法，安全通信的四大特性我们都已经实现了，整个过程是不是已经完美了呢？
答案不是的，这里还有一个“公钥的信任”问题。因为谁都可以发布公钥，我们还缺少防止黑客伪造公钥的手段，也就是说，怎么来判断这个公钥就是你或者某网站的公钥呢？
下面我们就来讨论下该问题，看下 TLS 是如何做的？
公钥的信任问题
你可能会想再次利用类似密钥交换的方法来解决公钥认证问题，用别的私钥来给公钥签名，显然，这会陷入无穷的信任验证过程。
这次实在是“没招”了，要终结这个“死循环”，就必须引入“外力”，找一个公认的可信第三方，让它作为“信任的起点，递归的终点”，构建起公钥的信任链。
- CA（Certificate Authority，证书认证机构）
这个第三方就是 CA。它就像网络世界里的公安局、公正中心，具有极高的可信度，由它来给各个公钥签名，用自身的信誉来保证公钥无法伪造，是可信的。
- CA 中心为每个使用公钥的用户发放一个数字证书，用以证明证书中列出的用户，合法拥有证书中列出的公钥。CA 结构的数字签名使得攻击者不能伪造和篡改证书。
世界上知名的 CA 没有几家，如 DigiCert、VeriSign、Entrust、Let`s Encrypt 等，它们签发的证书分为三种，区别在于其可信程度。DV 是最低的，只是域名级别的可信，背后是谁不知道。EV 是最高的，经过了法律和审计的严格核查，可以证明网站拥有者的身份（在浏览器地址栏会显示出公司的名字，例如 Apple、GitHub 的网站）。
DV（域名验证性证书）。最基本的审核级别，认证机构通常使用自动机制审核域名拥有权，所以成本也比较低。
OV（组织验证）。申领可以证明他拥有管理某域名的权力，审核程序通常需要经过人手处理。
EV（扩展验证）。这是最严格的审核级别，审核过程可能牵涉专业法律人员的调查及独立审计人员的确认，成本也自然更高。
CA 对公钥的签名
CA 对公钥的签名认证也是有格式的，不是简单地把公钥绑定在持有者身份上就完事了，还要包含序列号、用途、颁发者、有效时间等等，把这些打成一个包再签名，完整地证明公钥关联的各种信息，形成“数字证书”。
证书里的证明对象是一个“实体”（Common Name），可以证明任何东西，但是在互联网的环境下，这个“实体”就通常是域名了。
- 数字证书（Certificate）
CA 中心为每个使用公开密钥的用户发放一个数字证书，数字证书的作用是证明证书中列出的用户合法拥有证书中列出的公开密钥。CA 机构的数字签名使得攻击者不能伪造和篡改证书。
数字证书的实质是证书权威机构（CA）用自己的私钥，对普通用户提交的公钥和名称的绑定关系的数字签名。
证书体系
不过 CA 如何证明自己呢？这本质还是信任链的问题。“小一点”的 CA 可以让“大 CA” 签名认证，但链条的最后，也就是 Root CA，就只能自己证明自己了，这个就叫“自签名证书”（Self-Signed Certificate）或者“根证书”（Root Certificate）。对于根证书我们必须无条件相信，否则整个证书信任链就走不下去了。
有了这个证书体系，操作系统和浏览器都内置了各大 CA 的根证书，上网的时候只要服务器发过来它的证书，就可以验证证书里的签名，顺着证书链（Certificate Chain）一层层地验证，直到找到根证书，就能够确定证书是可信的，从而里面的公钥也是可信的。
根证书是自签名证书，也就是自己证明自己，是信任的起点，所以作为用户，也就是“你”，就必须信任它，否则就没有从它开始的整个证书链。所谓自签名，就是用证书里的公钥来证明证书里的公钥，自己证明自己。
1. 证书认证过程
假设现在有一个三级的证书体系（Root CA=> 一级 CA=> 二级 CA），它是如何完成证书信任链验证过程的呢？
前面我们说过，由于操作系统和浏览器都内置了各大 CA 的根证书，上网的时候只需要服务器发送来它的证书，就可以验证证书里的签名，顺着证书链（Certficate Chain）一层层地验证，直到找到根证书。
如果服务器返回的是一个二级证书，操作系统和浏览器内置的根证书（根公钥）只能解密根证书签名的证书，无法解密二级证书，只有使用一级证书的（公钥）才能解密二级证书，那么操作系统和浏览器是如何自上而上地层层解析得到根证书的呢？其实服务器返回的是一个证书链，然后操作系统或浏览器就可以使用信任的根证书（根公钥）解析根证书得到一级证书的公钥+摘要验签，然后拿一级证书的公钥解密一级证书得到二级证书的公钥+摘要验签，再然后拿二级证书的公钥解密二级证书得到服务器的公钥和摘要验签名，验证过程就此结束！
服务器在握手的时候会返回整个证书链，但通常为了节约数据量，不会包含最终的根证书，因为根证书通常已经在浏览器或者操作系统里内置了。
在这样一条信任链中，CA 的诚实可信是公钥信任体系的信任根。一旦计算机的“受信任根证书颁发机构”列表中，混入了不可信任的根证书，就可以随时签发任何名称的数字证书。由于计算机对所有受信任更证书所签发的数字证书基于不区分的平等信任，混入信任列表的恶意根证书签发的伪造证书将会危害计算机的所有安全通信，机密的信息会被解析窃听，显示为有效的数字签名和安全的 HTTPS 的连接其实际是不可信的。
2. 证书体系的弱点
证书体系（PKI，Public Key Infrastructure）虽然是目前整个网络世界的安全基础设施，但绝对的安全是不存在的，它也有弱点，关键还是信任二字。
1. CRL & OCSP
如果 CA 失误或者被欺骗，签发了错误的证书，虽然证书是真的，可它代表的网站确实假的。针对这种情况开发出了 CRL（证书吊销列表，Certificate revocation list）和 OCSP（在线证书状态协议，Online Certificate Status Protocol），两种协议用于及时废止有问题的证书。
2. 黑名单
还有一种更糟糕的情况，CA 如果被黑客攻陷，或者 CA 有恶意，因为它（即根证书）是信任的源头，整个信任链里的所有证书也就都不可信了。该种场景因为涉及的证书太多，就只能操作系统或者浏览器从根上“下狠手”了，撤销对 CA 的信任，列入“黑名单”，这样它颁发的所有证书就都会被认为是不安全的。
最后
今天我们主要了解了公钥信任的问题，CA 与数字证书。安全问题不知道有没有让你有一种“盗梦空间”的感觉？真是一环接一环。
大家也可以根据各大网站小锁头里的来理解该部分内容，下图我们可以看到由 DigiCert 签发的 github.com
总结
- 公钥的分发需要使用数字证书，必须有 CA 的信任链来验证，否则就是不可信的。
- 作为信任链的源头 CA 有时也会不可信，解决办法有 CRL、OCSP 和终止信任。
网络安全涉及了方方面面太多的知识，尤其是网络的基础知识对我们来说还是非常重要的，关于这部分大家又有什么要分享的？欢迎你的分享留言或指正。
网络安全系列专题
