HTTP笔记5：密码学、HTTPS的原理、SSL/TLS握手流程

1 密码学速学

1.1 加密方法

1 对称加密

一个秘钥加密解密，速度快

• DES
• AES

2 非对称加密

两个秘钥，公钥、私钥

• 公钥来加密，得用私钥解密
• 私钥来加密，得用公钥解密
• 速度慢

RSA

3 用对称提高速度，用公钥保护回话密钥

1. 先用对称加密消息得到一个会话密文（密文本身很少），再把这个会话密文用公匙加密
2. 公匙密码加密的会话秘钥 与 对称加密的信息一同传输
3. 接受者用私钥解密这个会话密文，得到一个对称加密的消息
4. 接受者利用密匙解密消息

1.2 资源完整性

单向散列（hash）
把一堆数据压缩成固定长度，不能恢复，用于检测完整性

• MD5
• SHA1,SHA256

资源改变，hash值必定改变

1.3 认证 ：消息认证码

散列（hash）+共享密匙


秘钥不同的话解析出的MAC值就不同

1.4 不可否认性：数字签名

用私钥加密

发送消息同时，发送一个签名（私钥加密），但是如果消息过大，速度很慢

速度快的签名

1. 将信息通过单项散列函数加密得到散列值
2. 将此散列值使用自己的私匙加密成签名，并发送
   

1.5 证书

认证机构颁发证书 来 担保Bob的公钥
Alice使用认证机构的公钥验证数字签名，确认Bob公钥的合法性
保证了公钥在传递过程中的安全性

PKI 体系

2 HTTPS 原理概述

发送的信息需要加密，接受者需要解密这个信息
不能直接用对称加密，需要结合非对称加密

1. 浏览器先 生成对称加密的秘钥，再使用服务器的 AK（公钥）加密这个秘钥，发送给服务器
2. 服务器用私钥解密出 共享密钥（对称加密的秘钥）
3. 浏览器与服务器之间使用这个共享密匙传输数据

那么浏览器如何获取服务端的公钥（AK）？
找一个中间人做担保

1. 有一个CA权威机构，提供担保
2. 浏览器将自己支持的一套加密算法发给服务器，同时发一个浏览器随机数。
3. 服务器向浏览器发送服务器数字证书。
4. 浏览器收到证书后对证书的CA签名进行验证，如果验证通过，会从证书中拿到服务器的公钥。
5. 之后就使用AK解密后得到的的对称加密密匙进行数据加密传输

3 SSL/TLS协议握手细节

SSL/TLS协议的基本思路是采用公钥加密法，也就是说，客户端先向服务器端索要公钥，然后用公钥加密信息，服务器收到密文后，用自己的私钥解密。

两个问题

1. 如何保证公钥不被篡改？

   将公钥放在数字证书中。只要证书是可信的，公钥就是可信的。

2. 公钥加密计算量太大，如何减少耗用的时间？

   每一次对话（session），客户端和服务器端都生成一个"对话密钥"（session key），用它来加密信息。由于"对话密钥"是对称加密，所以运算速度非常快，而服务器公钥只用于加密"对话密钥"本身，这样就减少了加密运算的消耗时间。

因此，SSL/TLS协议的基本过程是这样的：

1. 客户端向服务器端索要并验证公钥。
2. 双方协商生成"对话密钥"。
3. 双方采用"对话密钥"进行加密通信。

上面过程的前两步，又称为"握手阶段"（handshake）。

具体步骤

1. 浏览器将自己支持的一套加密算法发给服务器，同时发一个浏览器随机数。
2. 服务器向浏览器发送选择的加密算法、服务器生成的随机数、服务器数字证书。
3. 浏览器收到证书后对证书的CA签名进行验证，如果验证通过，会从证书中拿到服务器的公钥。
4. 浏览器对浏览器随机数+服务器随机数进行处理，生成预备主密码。
5. 浏览器用服务器的公钥对预备主密码进行加密，发给服务器。
6. 服务器收到后使用自己的私钥解密出预备主密钥。
7. 浏览器和服务器分别使用预备主密钥和两个随机数，生成共享主密钥
8. 二者使用共享主密钥，使用对称加密算法加密数据。

常见问题

每次https请求，都需要使用上面的流程握手协商吗？
答：第一次协商主密钥后，后面的请求就使用主密钥进行对称加密通信，不需要再协商。通过会话id来识别。