You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
47 lines
2.9 KiB
47 lines
2.9 KiB
5 years ago
|
---
|
||
|
|
深入理解 HTTPS
|
||
|
|
---
|
||
|
|
|
||
|
|
> 内部分享大纲，PPT 见文末。
|
||
|
|
|
||
|
|
今天给大家带来的分享主题是：深入理解 HTTPS。
|
||
|
|
|
||
|
|
HTTPS 的产生是为了解决 HTTP 的不安全性，它包括三个方面：
|
||
|
|
|
||
|
|
1. 机密性
|
||
|
|
2. 完整性
|
||
|
|
3. 身份验证
|
||
|
|
|
||
|
|
那 HTTPS 是如何解决的呢？其实不过是在 HTTP 之下 TCP 之上加了一个 TLS 层。
|
||
|
|
|
||
|
|
TLS 层最核心的就是加密套件，如下所示，下面就以该加密套件解读 TLS：
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
其中 ECDHE 密钥交换协议用于协商出对称加密所需的密钥，也就是 AES 算法，它的密钥长度为 128 位，工作模式为 GCM。非对称加密算法 RSA 用作身份验证，SHA256 是一种 MAC 算法，用于解决完整性。
|
||
|
|
|
||
|
|
以上已经解决了机密性和完整性，但是身份验证还需要 PKI 的参与。
|
||
|
|
|
||
|
|
PKI 即公钥基础设施，服务器会把它的公钥（也就是 RSA 的公钥）给 CA 机构，CA 机构会给服务器签发一个数字证书。在客户端建立连接的时候，服务器会通过 Certificate 子消息将证书链传给客户端，告诉客户端我就是你要通信的那个人。
|
||
|
|
|
||
|
|
RSA 也能作为密钥交换算法，但是因为其性能低下，需要大量指数运算消耗 CPU，同时又不具备前向安全性，所以现在基本上看不到采用 RSA 来实现密钥交换。
|
||
|
|
|
||
|
|
为了解决运算效率以及保障前向安全性，目前都会使用 ECDHE 作为密钥交换。
|
||
|
|
|
||
|
|
ECDHE = ECC + DH，即 ECC 椭圆曲线 + DHE 密钥交换。动态的 DH 每次协商都是生成不同的 DH 参数保证了前向安全性，而且 ECC 密钥长度短，运算块，但却不失安全性。
|
||
|
|
|
||
|
|
224 位的 ECC 密钥能够达到 2048 位的 RSA 的安全强度。
|
||
|
|
|
||
|
|
对称加密，加密解密使用同一个密钥，对称加密的工作原理可以简单的看成是异或运算。但是实际情况下，明文长度肯定远大于密钥长度，这就需要对明文进行拆分，每一个分组是 16 字节，采用可以采用的分组模式有 ECB、CBC 和 CTR，ECB 不能隐藏数据特征，CBC 不能并行执行，所以通常采用 CTR 工作模式。当然，如果最后一个明文块不足 16 字节，就需要对其进行填充，填充方式一般采用 PKCS#7。
|
||
|
|
|
||
|
|
了解了密码学之后，TLS 就简单的一批了。拿 WireShark 抓一下 TLS 包，分析一手，完事～
|
||
|
|
|
||
|
|
TLS 握手过程如下：
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
但是每次进行 HTTPS 连接都需要 TLS 握手吧？
|
||
|
|
|
||
|
|
肯定不是，所以有了 TLS 会话机制，可以基于 Session ID 和 Session Ticket。
|
||
|
|
|
||
|
|
TLS 在 2018 年正式发布，它移除了很多已证明不安全的套件，在第一次握手时客户端把所有的密码套件及其公钥都发给了服务端，也就不再需要 Server Key Exchange 和 Client Key Exchange，从 2 RTT 到 1RR。同时，TLS 1.3 支持基于会话恢复的 0RTT 握手。
|