1、TLS协议的工作原理
TSL设计目的：
- 身份验证
- 保密性
- 完整性
Record记录协议
- 对称加密
Handshake握手协议
- 验证通讯双方的身份
- 交换加解密的安全套件
- 协商加密参数
2、对称加密的工作原理
1）、XOR与填充
明文P和密钥K基于AES加密函数生成密文C，密文C通过网络传输给接收方，接收方拿到密文C基于相同的密钥K和AES解密函数就可以得到明文P
对称加密之所以能实现同一把密钥既能加密也能解密，就是基于对称加密与XOR异或运算
密钥序列1010和明文0110进行异或运算得到密文1100，密文1100和密钥序列1010进行异或运算得到明文0110
2）、工作模式
1）分组工作模式
允许使用同一个分组密码密钥对多于一块的数据进行加密，并保证其安全性
2）ECB（Electronic codebook）模式
直接将明文分解为多个块，对每个块独立加密
问题：无法隐藏数据特征
3）CBC（Cipher-block chaining）模式
第一组明文加密得到密文，第一组密文与第二组的明文先做一次异或再进行加密，第二组的密文与第三组的明文先做一次异或再进行加密
每个明文块先与前一个密文块进行异或后，再进行加密
问题：加密过程串行化，没完成第一步不能进行第二步和第三步的操作
4）CTR（Counter）模式
通过递增一个加密计数器以产生连续的密钥流
计数器、密钥、明文共同产生的密文就没有数据特征了，因为每一个都引入了不同的变量，同时可以并行运算
问题：不能提供密文消息完整性校验
5）验证完整性：MAC（Message Authentication Code）
发送方生成密文后，把密文和密钥使用hash算法生成MAC值，密文和MAC值传输给接收者，接收者接收到消息后，先根据同样的MAC算法和同一把密钥生成MAC值，与传输过来的MAC值比较是否相等，相等说明消息是完整的，不想等说明出现了差错
6）GCM（Galois/Counter Mode）=CTR+GMAC
3、详解AES对称加密算法
AES（Advanced Encryption Standard）加密算法
- 常用填充算法：PKCS7
- 常用分组工作模式：GCM
AES的三种密钥长度：
AES的加密步骤：
- 把明文按照128bit（16字节）拆分成若干个明文块，每个明文块是4*4矩阵
- 按照选择的填充方式来填充最后一个明文块
- 每一个明文块利用AES加密器和密钥，加密成密文块
- 拼接所有的密文块，成为最终的密文结果
1）AddRoundKey步骤
这里的密钥并不是原始的密钥，是做过密钥扩展算法的
密钥扩展是把每一轮使用的密钥生成下一轮使用的不同的新密钥
每一轮密钥是一个4*4 16字节的矩阵，先把每四个字节构成一个字，每个字4字节，把矩阵变成了4个元素的数组，基于g函数和异或生成下一轮的密钥
2）SubBytes步骤
3）ShiftRows步骤
4）MixColumns步骤
4、非对称加密与RSA算法
根据非对称加密算法生成一对密钥：公钥和私钥，公钥向对方公开，私钥仅自己使用
加密的时候使用对方的公钥加密消息，解密的时候使用自己的私钥解密
5、基于openssl实战验证RSA
1）、使用openssl基于RSA算法生成公私钥
生成私钥：openssl genrsa -out private.pem
hanxiantaodeMBP:tls hanxiantao$ openssl genrsa -out private.pem
Generating RSA private key, 2048 bit long modulus
........................+++
.................................+++
e is 65537 (0x10001)
hanxiantaodeMBP:tls hanxiantao$ cat private.pem
-----BEGIN RSA PRIVATE KEY-----
MIIEpAIBAAKCAQEAy5bTnsjJXtBMuafMmATFdAAX0jwTCpuuhclvF5y1+5gZ/uRM
dgRVwqnc3aFxHJbXv3rzwy0ehCKkOGue6Qw3FGUTWph573lNbFTI45VhsnllEvM3
cWkdljZ09LLbbOi+iuHrJV+xwauoH/UddiZ40Ih33Wg8wNSqe7KnSgBWK8ABr7Ke
YeimVrwO7hFqnOkjonD5lSamGOvEn5uqkQ5IQfc0gnPRYHrHXaw9xIZ5IRtww8pz
f+zO7XkAziWhLJ9kUtaSkL5Mifbw9kv8Gb+9epcWlBRGgFB/vPdJ+K4I59KMqAgf
zCKNEmGPT3sxBOzxpl5aV8LXFV8Da92nY0f86wIDAQABAoIBAEWF4AZdMsb6Avlz
X96Z4oPWdEwKz8XTnCl7vEAn981PB7GPbLzwhgjP0OiudN36dPqilhOUmNMusT3D
IqUa0sRYL9/EKf+pQNM5sNBm9tHnuqhZ/hjweHYPaqkVWvE6Gbd7pr1AjIdCg0tG
fSUXxjIQKD6nlfeTqBRN0ernaoXNk9K23DYVuBw4rtt4VpLlrABcX8klU1EEDy4s
lv9ZkzYV1F2brVxteaoXUqp7e4TguXLq/OpLC3fKGgn3pIpgILckB/8A3Rx6iH1/
lbj5IBxvy8tm4XtnFGt4nohkiYFlIN9wjiFYHbZ7x5i5Jgw7I1D5lIY5AyEMWyHl
35bcKuECgYEA6KO7UBZ8aYaCKcIpPbAsx6w3oY+tEUJla5G230ZPafT0UxmKLvVJ
/Q6guD850f8P/c5Qp4wZGXADRARKUCB8dqO2qE0IHlhjMq8tUf2s/mMR6lvKkh9q
KKHqiWezPvQAa0DuJ3zcWy1xliDgyOS6oE+CSCwOF+S6kZ3LEi7tGWcCgYEA4AhS
GKimUkvNPL6+j4krdx37HXuxiN5+Su+m9yv92AlIIDE6Z3BrhBRgKO/50CvVYrhL
0I8e0ZjZar+uCTwI0AsJx4wh10oPaIhGNLISXjXbX23WKasnZ/XLEhck9BIgWIf7
qX9iBln2Q4dEoUIWaYrffEd2OtezRGPdCEUyGd0CgYAUyKPwaMHer5yrXGRQ1Y96
m0ExFuPwWc0zygXbdq2bmr3FOs/kmBdvG0Jyk3t37mCgXTFJdrO7WQ2Boxx8ghp8
gu3LpW4nP+BE4++Zlp9A7trn5CF54oKadLS+Z9xUsHnlGxzrvDT3lFzEe9V5PS4L
Km9KQV1U9yNP5RgCXNzj2wKBgQCWXL9NEZRf08RyKsuXZscncZXjGev0IvC8ttBn
QL1kzAX+pUu/tTJUOaC4mSgf0eusEGnCFuzmXCJAhVn3lLWNfHsZ1TG5X1msHRqR
r5qoZJlSGVQOL3OJUOz0vVfuAGR5RvtfrcFK5gJlHFqxqLuGJtEMhqIRqEgHdMcb
D+YqeQKBgQC1Q1+2IikZSlc/Gw6rLeLcAyUerABygb+g6na27I4txpbBQWAk+D2n
rKdSWsk/9eTY5Th72T+zbxnyjaz0oCicyGsGLO0WrI0OxmpTCl5FfDbTBekb8Sps
YjCvQE22mket/sA6cYsCjtj2I4/2aNPIestlzZOeBmg22nDtLQtI9A==
-----END RSA PRIVATE KEY-----
从私钥中提取出公钥：openssl rsa -in private.pem -pubout -out public.pem
hanxiantaodeMBP:tls hanxiantao$ openssl rsa -in private.pem -pubout -out public.pem
writing RSA key
hanxiantaodeMBP:tls hanxiantao$ cat public.pem
-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAy5bTnsjJXtBMuafMmATF
dAAX0jwTCpuuhclvF5y1+5gZ/uRMdgRVwqnc3aFxHJbXv3rzwy0ehCKkOGue6Qw3
FGUTWph573lNbFTI45VhsnllEvM3cWkdljZ09LLbbOi+iuHrJV+xwauoH/UddiZ4
0Ih33Wg8wNSqe7KnSgBWK8ABr7KeYeimVrwO7hFqnOkjonD5lSamGOvEn5uqkQ5I
Qfc0gnPRYHrHXaw9xIZ5IRtww8pzf+zO7XkAziWhLJ9kUtaSkL5Mifbw9kv8Gb+9
epcWlBRGgFB/vPdJ+K4I59KMqAgfzCKNEmGPT3sxBOzxpl5aV8LXFV8Da92nY0f8
6wIDAQAB
-----END PUBLIC KEY-----
2）、使用RSA公私钥加解密
找一个原始文件，内容如下
hanxiantaodeMBP:tls hanxiantao$ cat hello.txt
hello world
加密文件，生成hello.en
hanxiantaodeMBP:tls hanxiantao$ openssl rsautl -encrypt -in hello.txt -inkey public.pem -pubin -out hello.en
解密文件，生成hello.de
hanxiantaodeMBP:tls hanxiantao$ openssl rsautl -decrypt -in hello.en -inkey private.pem -out hello.de
hanxiantaodeMBP:tls hanxiantao$ cat hello.de
hello world
6、非对称密码应用：PKI证书体系
注册用户使用RSA算法生成一对公私钥，私钥自己来保存，把公钥和个人的身份信息发起申请，给到CA认证机构。CA认证机构核实身份信息后，使用CA机构自己的私钥对这些信息进行加密，加密完成后证书就叫公钥证书
签名流程：
对传输的数据data使用hash函数生成hash值，把hash值用CA机构的私钥进行加密，得到了一串密文
验签流程：
对传输的数据data使用相同的hash函数生成hash值，把密文用CA机构的公钥进行解密，如果解密成功，证明这段信息确实是由CA机构加密的，验证CA机构身份真实性。再检查两段hash值是否匹配，如果匹配验签成功
小一点的CA可以让大CA签名认证，但链条的最后，也就是Root CA，就只能自己证明自己了，这个就叫自签名证书或者根证书
有了这个证书体系，操作系统和浏览器都内置了各大CA的根证书，上网的时候只要服务器发过来它的证书，就可以验证证书里的签名，顺着证书链一层层地验证，直到找到根证书，就能够确定证书是可信的，从而里面的公钥也是可信的
证书订阅人生成一对公私钥，把个人身份信息和公钥发给了CA登记机构，CA登记机构验证订阅人的身份，验证通过后把验证签名申请发给CA机构，CA机构用自己的私钥签名后颁发证书，最后传递给证书订阅人，证书订阅人在Web服务器上部署证书
用户建立好连接后，执行TLS握手，TLS握手的时候会先请求证书，服务器把公钥证书发给信赖方，信赖方（浏览器）根据证书链验证证书是否可信
7、非对称密码应用：DH密钥交换协议
RSA密钥交换没有前向保密性，在没有破解私钥之前，保存密文，破解私钥后，就可以解密之前所有保存的密文
DH密钥交换可以让双方在完全没有对方任何预先信息的条件下通过不安全信道创建起一个密钥，每次这个密钥都是是实时生成的，具备前向保密性
Server先生成公私钥private key1和public key1，公钥public key1发给Client，Client也生成一对公私钥private key2和public key2，公钥public key2发给Server，Client基于private key2和public key1基于一种算法生成密钥，Server基于private key1和public key2生成密钥，Client和Server生成的密钥是完全相同的，所以可以用作后面的对称加密
DH密钥交换协议的问题：
中间人伪造攻击
- 向Alice假装自己是Bob，进行一次DH密钥交换
- 向Bob假装自己是Alice，进行一次DH密钥交换
解决中间人伪造攻击：身份验证
8、TLS1.2与TLS1.3中的ECDH协议
ECDH协议是ECC算法和DH结合使用，用于密钥磋商（双方可以在不共享任何秘密的情况下协商出一个密钥），这个密钥交换算法称为ECDH。ECDH协议使用ECC算法比DH密钥交换协议计算速度更快
TLS1.2通讯过程：
- Client告诉Server自己支持哪些安全套件
- Server选择安全套件告知Client
- Server发送证书，用于Client验证身份
- 传递Server生成的公钥给Client
- 告知Server以上步骤都完成
- Client生成相应的公钥发送给Server
- Server和Client根据自己的私钥和对方提供的公钥生成密钥，两边生成的密钥是相同的
- 基于生成的密钥进行通讯加密了
openssl 1.1.1版本对TLS1.3的支持情况：
Ciphersuites安全套件
- TLS13-AES-256-GCM-SHA384
- TLS13-CHACHA20-POLY1305-SHA256
- TLS13-AES-128-GCM-SHA256
- TLS13-AES-128-CCM-8-SHA256
- TLS13-AES-128-CCM-SHA256
TLS1.3中大大减少了所支持的安全套件的数量，特别是把一些不够安全的安全套件算法全部取消了
Client Hello和Server Hello选择安全套件导致TLS1.2有一个RTT的不必要的延时
TLS1.3中，Client在握手之前预先生成公私钥，在握手的第一次中就把公钥发送给Server，Server也会生成公私钥，Client和Server根据自己的私钥和对方提供的公钥生成密钥，接下来就开始通讯了
TLS1.3支持5种加密套件，那么Client和Server通信使用哪一种呢？
Client会把这5种加密套件的公私钥全部生成，然后把5种公钥全部发给Server，由Server选定加密套件，并告知Client自己选定的公钥
9、握手的优化：session缓存、ticket票据及TLS1.3的0-RTT
1）、session缓存
第一次握手后服务器会生成一个session ID传给Client，在一定时间内，Client携带session ID再次访问Server，Server从缓存中取到session ID所对应的加密密钥，Server告知Client使用上次所使用的加密密钥即可，不需要再生成密钥
要求Client和Server缓存session ID和加密密钥
存在的问题：
- Server将session ID缓存到内存中，Server具有多个应用实例时，无法共享存储的session ID
- 在内存中缓存session ID是有内存消耗的
2）、session ticket
每一台Server不需要再耗费内存存储session ID，而是基于集群中共享的密码，使用该密码加密相关的加密信息发送给Client，下次握手的时候Client把相关的加密后的信息发送给Server，Server解密后获取上次握手成功后的密钥
3）、TLS1.3的0RTT握手
TLS1.3的0RTT是指握手的时候携带相关的数据，在一个RTT后就可以收到response，握手过程中没有占用额外的RTT，所以称为0RTT
0RTT也是在第二次握手才可以完成的，在第一次握手的时候，Client和Server将相关的密钥信息缓存下来，第二次握手基于上次缓存的信息发送给Server，如果Server上次密钥的相关信息没有过期的话，就可以解密到密钥，把相应的response发给Client
Client发送一个POST请求，使用了上次缓存的密钥进行加密，最终改变了Server数据库中的内容，如果报文被截获，截获者不需要解密报文，只需要再重新发送该报文，就可以不停改变Server数据库中的内容
所以0RTT、session ticket、session ID都需要设置合理的过期时间
10、总结HTTPS的工作模式
下面使用《趣谈网络协议》中的流程图来总结下HTTPS的工作模式：
Client会发送Client Hello消息到Server，以明文传输TLS版本信息、加密套件候选列表、压缩算法候选列表等信息。另外，还会有一个随机数，在协商对称密钥的时候使用
Server返回Server Hello消息，告诉Client，Server选择使用的协议版本、加密套件、压缩算法等，还有一个随机数，用于后续的密钥协商
Server发送服务器端的证书，然后说：Server Hello Done，我这里就这些信息了
Client从自己信任的CA仓库中，拿CA的证书里面的公钥去解密Server的证书。如果能够成功，则说明Server是可信的
证书验证完毕之后，觉得这个Server可信，于是Client计算产生随机数字Pre-master，发送Client Key Exchange，用证书中的公钥加密，再发送给Server，Server可以通过私钥解密出来
到目前为止，无论是Client还是Server，都有了三个随机数，分别是：自己的、对端的，以及刚生成的Pre-Master随机数。通过这三个随机数，可以在Client和Server产生相同的对称密钥
有了对称密钥，Client就可以说：Change Cipher Spec，以后都采用协商的通信密钥和加密算法进行加密通信了
然后发送一个Encrypted Handshake Message，将已经商定好的参数等，采用协商密钥进行加密，发送给服务器用于数据与握手验证
同样，Server也可以发送Change Cipher Spec，说：没问题，以后都采用协商的通信密钥和加密算法进行加密通信了，并且也发送Encrypted Handshake Message的消息试试。当双方握手结束之后，就可以通过对称密钥进行加密传输了
参考：
《Web协议详解与抓包实战》：https://time.geekbang.org/course/intro/100026801
《HTTPS协议：点外卖的过程原来这么复杂》：https://time.geekbang.org/column/article/9492