HTTPS实现安全通信机制的原理

现在很多网站已经逐渐使用HTTPS来代替HTTP来保障通信安全。和HTTP相比，HTTPS不再采用明文传输数据，第三方无法窃听通信的内容，也无法篡改内容或者伪造身份。

HTTPS采用SSL/TSL协议，TSL协议可以看做是SSL的升级版本，其实大部分情况下他们都指代一个东西。

建立一个可靠的HTTPS连接涉及到四次通信:

第一次：客户端-->服务器：

主要提供以下信息：

• 支持的协议版本，比如TLS1.0
• 支持的加密方法，比如RSA公钥加密
• 支持的压缩方法
• 一个客户端生成的随机数，稍后用于生成“对话密钥”

第二次：服务器-->客户端

主要提供以下信息：

• 确认使用的协议版本，如果不符合就关闭通信
• 确认使用的加密方法
• 服务器证书（包含给客户端使用的公钥）
• 一个服务器生成的随机数，稍后用于生成“对话密钥”

第三次：客户端-->服务器

• 一个客户端生成的随机数。该随机数用服务器公钥加密，防止被窃听。
• 编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送
• 客户端握手结束通知，表示客户端的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，用来供服务器校验。

第四次：服务器-->客户端

• 编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送
• 服务器握手结束通知，表示服务器的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，用来供客户端校验。

至此，整个握手阶段全部结束。接下来，客户端与服务器进入加密通信，就完全是使用普通的HTTP协议，只不过用"对话密钥"加密内容。

这里有需要注意的几点：

• 服务器提供给客户端的证书中包含公钥。对于非对称加密RSA来说，对于公钥加密的内容，只有私钥才能解密。
• 证书是分级的，称为证书链。下一级证书的摘要由上一级证书的私钥签名。签名和加密不一样，签名是要用私钥签，用公钥验证的，刚好相反。当需要验证下一级的证书是否可靠的时候，我们用上一级证书提供的公钥对签名的摘要进行解密，然后把解密出来的摘要和我们自己计算出来的下一级证书摘要进行对比，如果完全一致，就说明下一级证书是可靠的，从而完成验证。
• 当验证到受信任的根证书时，就能够确定要验证的证书是可信任的了。根证书一般由数字证书认证机构CA颁发，在你的浏览器的可信任证书列表里面，浏览器根据这个列表来判断根证书是否可信。
• 随机数总共有三个，其中第三个是用公钥加密的，其他两个都是明文的。之所以使用三个随机数，是为了确保生成的“对话秘钥(Session Key)”不容易被破解