非对称秘钥: 用来加密对称秘钥, 特点是: 使用公钥私钥配对来加密解密, 用于 TLS 握手阶段
对称秘钥: 用于加密后续的数据传输阶段

交互

openssl s_client -state -connect q.qunarzz.com:443
客户端 服务端
-> 发起 ssl 连接 <- 发送公钥 -> 发送对称秘钥(用公钥加密) <- 利用对称秘钥传输数据
但是上面的这种情况:
  1. 如果中间人拦截获取了 服务端发送给客户端的公钥
  2. 然后将自己的公钥发送给客户端
  3. 客户端用中间人的公钥加密了对称秘钥发送给服务端
  4. 中间人利用私钥解开了客户端发送过来的对称秘钥
  5. 将对称秘钥用 "真正的公钥" 加密之后再发送给服务端
这时候, 服务端跟客户端建立起了连接, 但是对称秘钥已经被中间人获取, 可以拦截获取所有数据.
此时, 引入了一个新的机制: 证书
服务器先生成公钥, 私钥. 将公钥提供给相关的机构 CA, 然后 CA 将公钥放进证书中, 并且颁发给服务器, 此时服务器就不是把公钥直接发给客户端了, 而是发送一个证书, 证书中加入了一些数字签名的机制, 如果中间人伪造 证书的话, 并不能获得 CA 的认证. 这里的签名操作其实也是一个非对称加密过程, 利用 CA 自己的公钥, 私钥 加密, 只不过正好反过来, 利用私钥加密, 公钥解密.
CA 其实充当了一个中介的机构.

SID

如果出现某种原因, 对话中断, 就需要重新握手, 效率比较低, 这时候引入了 session ID 的概念
重连的时候, 客户端带上这个 SID, 服务端检查这个 SID 是否有记录, 存在这个记录的话, 就可以使用已有的对称秘钥

握手

客户端 服务端
-> 发起 Client Hello 支持的协议版本 一个客户端生成的随机数, 用于稍后生成对称秘钥(pubkey) 支持的加密方法列表(加密族) 支持的压缩方法列表
<- 发起 Server Hello 确认协议版本 选定的加密方法 选定的压缩方法 一个服务器生成的随机数, 用于稍后生成对称秘钥(pubkey) 证书
-> 一个随机数(用公钥加密). 先利用上面两个随机数生成一个新的随机数称为 pre-master , 再根据这三个随机数生成一个对称秘钥 enc_key. 编码改变通知(表示随后的信息都开始用加密方法和秘钥发送) 客户端握手结束请求, 内容是前面发送内容的 hash 值, 用以校验
<- 编码改变通知(表示随后的信息都开始用加密方法和秘钥发送) 服务器握手结束请求, 内容是前面发送内容的 hash 值, 用以校验