HTTPS详解

0. 说明

本文章为极客时间课程<<透视 HTTP 协议>>的笔记

1. 基本概念

1.1 安全的4个特性

通信必须满足以下4个特性才能说是安全的，后面介绍的内容也是围绕HTTPS如何保证这4个特性展开：

• 机密性：指数据的加密，只有通信双方能“读懂”通信内容
• 完整性：指数据在通信过程中没有被篡改，因为光有机密性不够，黑客虽然无法读取数据，但是可以篡改数据
• 身份认证：确认通信对方的身份，如果通信的另一方是假冒网站，即使保证了机密性和完整性也毫无意义
• 抗否认性

1.2 HTTPS、SSL、TLS是什么

如下图所述，HTTP属于应用层协议（7层），下层是TCP（4层）协议，而HTTPS下面多了一层SSL/TLS（5层，会话层），也就是说HTTPS=HTTP+SSL/TLS

1.2.1 SSL与TLS关系

SSL即安全套接层（Secure Sockets Layer），在 OSI 模型中处于第 5 层（会话层），由网景公司于 1994 年发明，有 v2 和 v3 两个版本，而 v1 因为有严重的缺陷从未公开过。SSL 发展到 v3 时已经证明了它自身是一个非常好的安全通信协议，于是互联网工程组 IETF 在 1999 年把它改名为 TLS（传输层安全，Transport Layer Security），正式标准化，版本号从 1.0 重新算起，所以 TLS1.0 实际上就是 SSLv3.1。到今天 TLS 已经发展出了三个版本，分别是 2006 年的 1.1、2008 年的 1.2 和2018的 1.3。一句话总结：TLS就是标准化后的SSL

1.2.2 TLS协议组成

TLS由以下子协议组成：

• 记录协议
• 握手协议
• 警告协议
• 变更密码规范协议
• 扩展协议

1.2.3 TLS加密套件

客户端与服务端建立TLS连接时需要选择一组加密算法来实现通信安全，这些算法的组合成为加密套件（cipher suite），基本的形式是“密钥交换算法 + 签名算法 + 对称加密算法 + 摘要算法”，比如：ECDHE-RSA-AES256-GCM-SHA384表示握手时使用 ECDHE 非对称加密算法进行密钥交换，用 RSA 签名和身份认证，握手后的通信使用 AES 对称算法，密钥长度 256 位，分组模式是 GCM，摘要算法 SHA384 用于消息认证和产生随机数。

1.2.4 OpenSSL

是一个著名的开源密码学程序库和工具包，几乎支持所有公开的加密算法和协议，已经成为了事实上的标准，许多应用软件都会使用它作为底层库来实现 TLS 功能，包括常用的 Web 服务器 Apache、Nginx 等。OpenSSL 是开源的，所以它还有一些代码分支，比如 Google 的 BoringSSL、OpenBSD 的 LibreSSL

2. 机密性保证—加密算法

2.1 对称加密算法

指加密和解密使用相同的秘钥

2.2.1 TLS提供的对称加密算法

TLS提供的对称加密算法有RC4、DES、3DES、AES、ChaCha20 等，但常用的只有 AES 和 ChaCha20，其他被认为是不安全的：

• AES：Advanced Encryption Standard，密钥长度可以是 128、192 或 256。它是 DES 算法的替代者，安全强度很高，性能也很好，而且有的硬件还会做特殊优化，所以非常流行，是应用最广泛的对称加密算法
• ChaCha20：Google 设计的另一种加密算法，密钥长度固定为 256 位

2.2.2 加密分组模式

对称算法还有一个“分组模式”的概念，它可以让算法用固定长度的密钥加密任意长度的明文。
最早有 ECB、CBC、CFB、OFB 等几种分组模式，但都陆续被发现有安全漏洞，所以现在基本都不怎么用了。最新的分组模式被称为 AEAD（Authenticated Encryption with Associated Data），在加密的同时增加了认证的功能，常用的是 GCM、CCM 和 Poly1305。

把上面这些组合起来，就可以得到 TLS 密码套件中定义的对称加密算法。比如，AES128-GCM，意思是密钥长度为 128 位的 AES 算法，使用的分组模式是 GCM

2.2 非对称加密算法

对称加密算法存在一个问题：通信前如何交换秘钥，要交换秘钥必须通过网络，存在秘钥泄漏的风险，为了解决这个问题就出现了非对称加密（也叫公钥加密算法）。

它有两个密钥，一个叫“公钥”（public key），一个叫“私钥”（private key）。两个密钥是不同的，“不对称”，公钥可以公开给任何人使用，而私钥必须严格保密。公钥和私钥有个特别的“单向”性，虽然都可以用来加密解密，但公钥加密后只能用私钥解密，反过来，私钥加密后也只能用公钥解密。

2.2.1 TLS里的非对称加密算法

非对称加密算法的设计要比对称算法难得多，在 TLS 里只有很少的几种，比如 DH、DSA、RSA、ECC 等。

• RSA ：基于“整数分解”的数学难题，使用两个超大素数的乘积作为生成密钥的材料，想要从公钥推算出私钥是非常困难的
• ECC：Elliptic Curve Cryptography，基于“椭圆曲线离散对数”的数学难题，使用特定的曲线方程和基点生成公钥和私钥，子算法 ECDHE 用于密钥交换，ECDSA 用于数字签名。目前比较常用的两个曲线是 P-256（secp256r1，在 OpenSSL 称为 prime256v1）和 x25519。P-256 是 NIST（美国国家标准技术研究所）和 NSA（美国国家安全局）推荐使用的曲线，而 x25519 被认为是最安全、最快速的曲线。相比RSA，ECC秘钥长度更短，性能更高，因此在TLS1.3中废弃了RSA保留ECC

2.3 效率与安全

非对称加密算法解决了对称加密秘钥交换问题，但是效率偏低，为它们都是基于复杂的数学难题。所以TLS结合两种加密算法来保证机密性，具体来说是先用非对称加密算法交换对称加密的秘钥，然后使用对称加密方式通信。通过混合加密的方式，虽然保证了通信安全的机密性，但是完整性、身份认证、抗否认等特性还没解决。

3. 完整性保证—摘要算法

实现完整性的手段主要是摘要算法（Digest Algorithm），也就是常说的散列函数、哈希函数（Hash Function）。它能够把任意长度的数据“压缩”成固定长度、而且独一无二的“摘要”字符串，就好像是给这段数据生成了一个数字“指纹”，加密后的数据无法解密，不能从摘要逆推出原文。

常用的摘要算法有：MD5(Message-Digest 5)、SHA-1和SHA-2，其中MD5和SHA-1安全性较低，在TLS中被禁止使用，推荐用SHA-2。SHA-2 实际上是一系列摘要算法的统称，总共有 6 种，常用的有 SHA224、SHA256、SHA384，分别能够生成 28 字节、32 字节、48 字节的摘要。

完整性
摘要算法保证了“数字摘要”和原文是完全等价的，只要在原文后附上它的摘要，就能够保证数据的完整性。但真正的完整性必须要建立在机密性之上，通信时原文和摘要都需要加密，这样黑客无法获取明文就没办法篡改数据，否则篡改原文后再把摘要改了还是保证不了完整性。

4. 身份认证和抗否认保证—数字签名与证书

4.1 数字签名

非对称加密中用私钥加密，公钥解密，就是签名与验签过程，A用私钥加密后的密文如果B用公钥能解密，那说明一定是A发送的数据，同时满足了身份认证和抗否认；实际由于非对称加密低效率，所以只对原文的摘要进行签名。流程：

• 计算原文摘要，此时待发送数据包括原文和摘要
• 对摘要用私钥加密（签名），得到数字签名
• 用对称加密对原文和数字签名加密，发送给对端
• 接收端收到后用对称秘钥解密，然后用发送端公钥进行解密（验签）得到摘要
• 接收端对接收到的原文计算摘要，与上一步摘要对比是否一致

4.2 数字证书

通过前面的步骤已经保证了安全4大特性，但这里还有一个“公钥的信任”问题。因为谁都可以发布公钥，我们还缺少防止黑客伪造公钥的手段。我们可以用类似密钥交换的方法来解决公钥认证问题，用别的私钥来给公钥签名，显然，这又会陷入“无穷递归”。这时候就需要中心化的、第三方权威机构介入了，即CA（Certificate Authority，证书认证机构）。

CA 对公钥的签名认证也是有格式的，不是简单地把公钥绑定在持有者身份上就完事了，还要包含序列号、用途、颁发者、有效时间等等，把这些打成一个包再签名，完整地证明公钥关联的各种信息，形成“数字证书”（Certificate）

知名的 CA 全世界就那么几家，比如 DigiCert、VeriSign、Entrust、Let’s Encrypt（免费颁发90天过期的DV证书） 等，它们签发的证书分 DV、OV、EV 三种，区别在于可信程度。DV 是最低的，只是域名级别的可信，背后是谁不知道。EV 是最高的，经过了法律和审计的严格核查，可以证明网站拥有者的身份（在浏览器地址栏会显示出公司的名字，例如 Apple、GitHub 的网站）

4.2.1 CA如何自证

CA如何证明自己也是一个问题，小一点的 CA 可以让大 CA 签名认证，但链条的最后，也就是 Root CA，就只能自己证明自己了，这个就叫“自签名证书”（Self-Signed Certificate）或者“根证书”（Root Certificate）。你必须相信，否则整个证书信任链就走不下去了

有了这个证书体系，操作系统和浏览器都内置了各大 CA 的根证书，上网的时候只要服务器发过来它的证书，就可以验证证书里的签名，顺着证书链（Certificate Chain）一层层地验证，直到找到根证书，就能够确定证书是可信的，从而里面的公钥也是可信的。

4.2.2 证书体系存在的问题

证书体系（PKI，Public Key Infrastructure）虽然是目前整个网络世界的安全基础设施，但绝对的安全是不存在的，它也有弱点。如果 CA 失误或者被欺骗，签发了错误的证书，虽然证书是真的，可它代表的网站却是假的。还有一种更危险的情况，CA 被黑客攻陷，或者 CA 有恶意，因为它（即根证书）是信任的源头，整个信任链里的所有证书也就都不可信了。

这两种事情并不是“耸人听闻”，都曾经实际出现过。所以，需要再给证书体系打上一些补丁。针对第一种，开发出了 CRL（证书吊销列表，Certificate revocation list）和 OCSP（在线证书状态协议，Online Certificate Status Protocol），及时废止有问题的证书。对于第二种，因为涉及的证书太多，就只能操作系统或者浏览器从根上“下狠手”了，撤销对 CA 的信任，列入“黑名单”，这样它颁发的所有证书就都会被认为是不安全的。