SSL/TLS握手阶段解析

众所周知SSL/TLS是HTTPS的基石，我觉得对经常都在使用的网络需要有进一步的了解。

HTTPS协议全称（Hypertext Transfer Protocol Secure），它与HTTP协议最大的不同就在于更安全。

HTTP是明文协议，所有内容默认都没有经过加密，当然也可以由开发人员将客户端和服务端要发送的内容进行加密保护，但还是存在中间人攻击。

HTTPS就是为了更安全的让人使用网络而产生，下面是我对SSL/TLS握手阶段的一些理解：

  在客户端与服务器之间通信握手时会先协商SSL/TLS协议版本号、通信加密算法，确定好后服务器发送证书给客户端，客户端通过CA对证书进行解析，并校验证书的真实性与有效性。前两次明文对话都会携带一个随机数，在第三次对话中，客户端会将随机数3通过服务器的公钥进行加密，再传递给服务器，这样双方都拥有三个随机数。通过协商好的指定算法将三个随机数转换为对称密钥，后面都将采用对称加密通信。这个协商过程有一些细节。

  为了防止中间人攻击，引入了CA（证书颁发机构）进行监管，当客户端收到服务器发送的证书，会读取保存在系统中的CA密钥对证书解密，并检查以下信息：

• 数字签名：验证证书是否由可信任的证书颁发机构(CA)签发
• 证书链：检查从终端实体证书到根证书的完整证书链
• 有效期：确认证书在当前时间是否有效(未过期)
• 吊销状态：通过CRL(证书吊销列表)或OCSP(在线证书状态协议)检查证书是否被吊销
• 域名：验证证书中的域名与访问的网站域名是否匹配
• 密钥用途：确认证书的预期用途(如服务器身份验证)
• 基本约束：检查证书是否可以作为CA证书使用
• 扩展密钥用途：验证更具体的用途限制

如果检测出有问题，就会拒绝与服务器通信。

---

解惑环节：

为什么第三个随机数采用加密传输？
  这是为了防止中间人攻击，通过公钥加密的数据只有私钥才能解密，虽然中间人劫持了这个数据但是解密不了。当然他可能采用其他手段，假设他将服务器传输给客户端的证书劫持，替换为他自己生成的证书发送给客户端怎么办。这就体现出CA的重要性，客户端会对收到的证书通过CA进行校验，只有真实可信的证书才被允许继续通信。

为什么不直接使用非对称加密进行通信，而是协商对称加密进行通信？

  非对称加密需要消耗的计算资源开销非常高，对于小数据影响体现不大，但是对于大数据就非常夸张。而且不同的通信设备硬件资源也不同，很容易影响网络使用体验。

HTTPS协议作为无状态是如何保持状态的？

  客户端在ClientHello阶段会发送SessionID，这个SessionID就相当于会话身份，客户端和服务器会临时保存它（协商好的SSL/TLS协议版本号、通信加密算法等），在后续的通信中都会携带SessionID来保持要进行的会话，避免频繁的握手协商等步骤，减少重新建立加密连接的开销。
  需要注意的是在浏览器上关闭页面会清除SessionID信息，再打开页面会重新建立通信连接。

在一些安全要求非常高的场景中，假设在一个受CA保护的非对称加密下进行通信，那么双方都需要互换证书，如何防止中间人攻击？这是一个更复杂的话题，等以后再填坑。