网络篇（一）SSL/TSL协议

SSL/TSL要解决的问题

在不使用SSL/TSL加密的HTTP通信就是不加密的通信，所有的信息都是明文传播。带来了以下几个风险：

1. 窃听风险：第三方可以获取通信内容。
2. 篡改风险：第三方可修改通信内容。
3. 冒充风险：第三方可以冒充他人进行通信。

而SSL/TSL就是为了解决这三大风险而设计的：

1. 所有信息加密传播，第三方无法得知通信内容。
2. 添加信息校验机制，一旦通信信息被篡改，通信双方就能发现。
3. 添加身份证书，防止被第三方假冒。

SSL/TSL的基本运行原理

SSL/TSL基本思路采用的是公钥加密法，也就是，客户端先向服务器索要公钥，然后用公钥加密信息，服务器收到密文，然后用自己的私钥解密信息。
在实际使用中为了解决公钥被篡改的问题引入了信任的数字证书；

将公钥放在数字证书中，只要证书是可信任的，公钥就是可信的

使用非对称加密的公钥加密信息的计算量太大，为了减少计算耗时：

在每次回话中（session），客户端和服务端都生成一个“对话秘钥”，用它来加密信息。由于使用的是对称加密，
所以运算速度非常快，而服务器的公钥只用于加密“对话秘钥”本身。这样就减少了加密运算消耗的时间。

从上面我们可以大致的总结一下SSL/TSL协议的基本过程如下：

1. 客户端向服务端索要并验证公钥。
2. 双方协商生成“对话秘钥”。
3. 双方采用“对话秘钥”进行加密通信。
   前面两步又称为“握手阶段”。

握手阶段分为一下步骤

1. 客户端发出请求

客户端向服务端发送加密通信请求，并提交一下信息：

• 支持协议的版本，比如TLS 1.0版本。
• 客户端生成的随机数，用于后面生成“对话秘钥”。
• 支持的加密方法，如RSA加密。
• 支持的压缩方法。

2. 服务器回应请求

服务端收到客户端请求后，向客户端做出回应。

• 确认使用的加密通信版本，如TLS 1.0版本。如果浏览器与服务器支持的版本不一致，服务器关闭加密通信。
• 一个服务器生成的而随机数，用于随后的“对话秘钥“。
• 确认使用的加密方法，如RSA公钥加密。
• 服务器证书。
  除了以上回应，如果服务器需要确认客户端的身份，就会要求客户端提供”客户端证书“。

3. 客户端结束握手请求

客户端收到服务器的回应以后，首先验证服务器的证书。如果证书不是可信任机构颁布、或者证书中的域名与实际域名不一致、或者证书已经过期，就会向访问者显示一个警告，由其选择是否还要继续通信。
如果证书没问题，客户端就会从证书中获取服务器的公钥，然后向服务器发送以下信息：

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

上面第一项的随机数，是整个握手阶段出现的第三个随机数，又称"pre-master key"。有了它以后，客户端和服务器就同时有了三个随机数，接着双方就用事先商定的加密方法，各自生成本次会话所用的同一把"会话密钥"。

4. 服务端结束握手请求

服务端收到客户端的第三个随机数pre-master key后，经过计算生成本次会话所用的秘钥。然后向客户端发送一下信息：

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

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

本文章仅仅是个人学习记录。
参考自SSL/TLS协议运行机制的概述