HTTPS备忘

TCP报文格式重要字段介绍

• 序号(Seq):32位，用来标识从TCP源端向目的端发送的字节流，发起方发送数据时对此进行标记
• 确认序号(Ack):32位，ACK=1时，确认序号字段才有效，Ack=Seq+1
• 标志位(URG、ACK、PSH、RST、SYN、FIN):
  • FIN释放一个连接

注意点

• Ack和ACK要区分
• 确认方的Ack=发起方的Seq+1，两端配对

三次握手/四次挥手

• 三次握手

1. 客户端->>服务端: 连接请求(SYN=1,seq=X)；
2. 服务端->>客户端: 授予连接(SYN=1,ACK=1，seq=Y, ack=X+1)；
3. 客户端->>服务端: 确认(ACK=1,ack=K+1)；

相当于

1. 客户端：我能说话，你能听到不？
2. 服务端：我能听到，那我说话你能听到不？
3. 客户端：我也能听到，我们开始通信吧。

三次握手就是确保两端都能正常的接收和发送。所以才说TCP是可靠的原因。

• 四次挥手

1. 客户端->>服务端：发送FIN，关闭客户端到服务端的传送，客户端进入FIN_WAIT_1状态；
2. 服务端->>客户端：收到FIN后，发送一个ACK给客户端，确认序号为收到序号+1，服务端进入CLOSE_WAIT状态；
3. 服务端->>客户端：服务端发送一个FIN，用来关闭服务端到客户端的数据传送，Server进入LAST_ACK状态；
4. 客户端->>服务端：收到FIN后，客户端进入TIME_WAIT状态，接着发送一个ACK给服务端，确认序号为收到序号+1，服务端进入CLOSED状态，完成四次挥手。

相当于

1. 客户端：我没啥数据发了，我断开了
2. 服务端：我知道你要断开了，并且告诉你我知道了
3. 服务端：我没啥数据发了，我断开了
4. 客户端：我知道你要断开了，并且告诉你我知道了

为啥挥手要四次呢？因为客户端你不发了，不代表你不能收了，我服务端没说不发，你当然不能断啦。TCP全双工通信（双轨：可以来回发送消息，单轨：一个发了，一个等待，一个轨道只能一个信号发送），所以有一方是主动断开，另一方是被动断开的。（就和分手一样一样的！！！）。

HTTP1.1/HTTP2.0

• HTTP/1.1: 持久连接(长连接)、节约带宽、HOST域、管道机制、分块传输编码
• HTTP/2: 多路复用、服务器推送、头信息压缩、二进制协议等

对称加密

• 加密和解密的密钥是一样的
• 密钥配送问题
  • 事件共享密钥
  • 密钥分配中心
  • DH密钥交换
  • 公钥密码
• 常见算法：DES（64bit，每隔7位设置一个错误检查的bit，所以共有56bit是有效的）、3DES、AES（用于取代DES）
• 如果每个客户端的密钥都是不一样的，服务端存储密钥的压力巨大，一样的话，黑客也能拿到，那加不加密都一样

非对称加密

• 客户端可以拿到公钥，服务端存储私钥
• 中间人问题：客户端无法保证拿到公钥的准确性

对称加密+非对称加密+CA认证

• CA认证：利用第三方权威机构，证明我就是我（是颜色不一样的烟火）
• 基本流程：
  1. c->s 支持的SSL版本，非对称加密算法，随机数R1
  2. s->c SSL版本，对称算法、随机数R2，证书（服务端把公钥传到CA机构，CA机构利用自己的私钥签名认证，返回给服务端的）
  3. 证书认证
  4. c->s 随机数R3 hash(R1, R2) = x
  5. hash(R1, R2) =? x => R1、R2、R3计算得出对应加密中密钥k
  6. s->c hash(R1, R2, x) = y
  7. hash(R1, R2, x) =? y => R1、R2、R3计算得出对应加密中密钥k

所以对称加密的公钥只有通信的双方才知道，也就能保证通信安全了。

安全性考虑

HTTP通信传输(当你输入https://www.baidu.com后到底发生了什么？)

1. 输入地址
2. DNS解析（根据URL找到IP地址）
3. TCP三次握手
4. 发送http请求
5. 返回http请求
6. 浏览器解析渲染页面
7. 断开连接

抓包工具

• Charles
• WireShark