DV 是最低的 ， 只是域名级别的可信 ， 背后是谁不知道 。 EV 是最高的 ， 经过了法律和审计的严格核查 ， 可以证明网站拥有者的身份（在浏览器地址栏会显示出公司的名字 ， 例如 Apple、GitHub 的网站） 。
不过 ， CA 怎么证明自己呢？
这还是信任链的问题 。 小一点的 CA 可以让大 CA 签名认证 ， 但链条的最后 ， 也就是Root CA ， 就只能自己证明自己了 ， 这个就叫“自签名证书”（Self-Signed Certificate）或者“根证书”（Root Certificate） 。 你必须相信 ， 否则整个证书信任链就走不下去了 。
文章插图
有了这个证书体系 ， 操作系统和浏览器都内置了各大 CA 的根证书 ， 上网的时候只要服务器发过来它的证书 ， 就可以验证证书里的签名 ， 顺着证书链（Certificate Chain）一层层地验证 ， 直到找到根证书 ， 就能够确定证书是可信的 ， 从而里面的公钥也是可信的 。
证书体系的弱点
证书体系（PKI ， Public Key Infrastructure）虽然是目前整个网络世界的安全基础设施 ， 但绝对的安全是不存在的 ， 它也有弱点 ， 还是关键的“信任”二字 。
如果 CA 失误或者被欺骗 ， 签发了错误的证书 ， 虽然证书是真的 ， 可它代表的网站却是假的 。
还有一种更危险的情况 ， CA 被黑客攻陷 ， 或者 CA 有恶意 ， 因为它（即根证书）是信任的源头 ， 整个信任链里的所有证书也就都不可信了 。
这两种事情并不是“耸人听闻” ， 都曾经实际出现过 。 所以 ， 需要再给证书体系打上一些补丁 。
针对第一种 ， 开发出了 CRL（证书吊销列表 ， Certificate revocation list）和 OCSP（在线证书状态协议 ， Online Certificate Status Protocol） ， 及时废止有问题的证书 。
对于第二种 ， 因为涉及的证书太多 ， 就只能操作系统或者浏览器从根上“下狠手”了 ， 撤销对 CA 的信任 ， 列入“黑名单” ， 这样它颁发的所有证书就都会被认为是不安全的 。
HTTPS 建立连接当你在浏览器地址栏里键入“https”开头的 URI ， 再按下回车 ， 会发生什么呢？
浏览器首先要从 URI 里提取出协议名和域名 。 因为协议名是“https” ， 所以浏览器就知道了端口号是默认的 443 ， 它再用 DNS 解析域名 ， 得到目标的 IP 地址 ， 然后就可以使用三次握手与网站建立 TCP 连接了 。
在 HTTP 协议里 ， 建立连接后 ， 浏览器会立即发送请求报文 。 但现在是 HTTPS 协议 ， 它需要再用另外一个“握手”过程 ， 在 TCP 上建立安全连接 ， 之后才是收发 HTTP 报文 。
这个“握手”过程与 TCP 有些类似 ， 是 HTTPS 和 TLS 协议里最重要、最核心的部分 ， 懂了它 ， 你就可以自豪地说自己“掌握了 HTTPS” 。
TLS 协议的组成在讲 TLS 握手之前 ， 我先简单介绍一下 TLS 协议的组成 。
TLS 包含几个子协议 ， 你也可以理解为它是由几个不同职责的模块组成 ， 比较常用的有记录协议、警报协议、握手协议、变更密码规范协议等 。

• 记录协议（Record Protocol）规定了 TLS 收发数据的基本单位：记录（record） 。 它有点像是 TCP 里的 segment ， 所有的其他子协议都需要通过记录协议发出 。 但多个记录数据可以在一个 TCP 包里一次性发出 ， 也并不需要像 TCP 那样返回 ACK 。
• 警报协议（Alert Protocol）的职责是向对方发出警报信息 ， 有点像是 HTTP 协议里的状态码 。 比如 ， protocol_version 就是不支持旧版本 ， bad_certificate 就是证书有问题 ， 收到警报后另一方可以选择继续 ， 也可以立即终止连接 。
• 握手协议（Handshake Protocol）是 TLS 里最复杂的子协议 ， 要比 TCP 的 SYN/ACK 复杂的多 ， 浏览器和服务器会在握手过程中协商 TLS 版本号、随机数、密码套件等信息 ， 然后交换证书和密钥参数 ， 最终双方协商得到会话密钥 ， 用于后续的混合加密系统 。
• 最后一个是变更密码规范协议（Change Cipher Spec Protocol） ， 它非常简单 ， 就是一个“通知” ， 告诉对方 ， 后续的数据都将使用加密保护 。 那么反过来 ， 在它之前 ， 数据都是明文的 。

稿源：(未知)

【傻大方】网址：http://www.shadafang.com/c/111J2Hc2020.html

标题：深入浅出 HTTPS (详解版)( 四 )