SSL/TLS协议运行机制

--------------------------------------------------------------------------

对称加密和非对称加密

加密面临着一个问题，就是密钥的分发问题。也即是加密方加密时的密钥如何让解密方知道。这也正是对称加密和非对称加密的区别。

对称加密：加密和解密使用同一个密钥。常见的对称加密算法：DES，AES，3DES等等。因此加密的安全性不仅取决于加密算法本身，密钥管理的安全性更是重要。

非对称加密：加密和解密使用不同的秘钥，一把作为公开的公钥，另一把作为私钥。“公钥”是可以被公开的，接收方只需要使用自己已持有的私钥进行解密。非对称加密大致过程：

1、乙方生成一对密钥（公钥和私钥）并将公钥向其它方公开。

2、得到该公钥的甲方使用该密钥对机密信息进行加密后再发送给乙方。

3、乙方再用自己保存的另一把专用密钥（私钥）对加密后的信息进行解密。乙方只能用其专用密钥（私钥）解密由对应的公钥加密后的信息

区别：

1、非对称加密相比非对称加密算法来说，加解密的效率要高得多。但是缺陷在于对于秘钥的管理上，以及在非安全信道中通讯时，密钥交换的安全性不能保障。

2、非对称加密：公钥加密，私钥解密；公钥可以公开给别人进行加密，私钥永远在自己手里，非常安全，黑客拦截也没用，因为私钥未公开。著名的RSA加密算法用的就是非对称加密。

--------------------------------------------------------------------------

SSL/TLS协议

如果不采用加密通讯，所有信息采用明文传播，则面临三大风险：

1、窃听风险：第三方可以获知通信内容。

2、篡改风险：第三方可以修改通信内容

3、冒充风险：第三方可以冒充他人身份参与通信。

SSL/TLS的设计为了解决以上三大风险设计的，希望达到：

1、所有信息都是加密传播，第三方无法窃听。

2、具有校验机制，一旦被篡改，通信双方会立刻发现。

3、配备身份证书，防止身份被冒充

TLS 1.0通常被标示为SSL 3.1；TLS 1.1为SSL 3.2；TLS 1.2为SSL 3.3。

基本运行过程

SSL/TLS协议的基本思路是采用公钥加密法，也就是说，客户端先向服务器端索要公钥，然后用公钥加密信息，服务器收到密文后，用自己的私钥解密。类似于非对称加密。

存在两个问题

（1）如何保证公钥不被篡改？

解决方法：将公钥放在数字证书中。只要证书是可信的，公钥就是可信的。

（2）公钥加密计算量太大，如何减少耗用的时间？

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

因此，SSL/TLS协议的基本过程是这样的，其中前两步是“握手阶段”：

1、客户端向服务器端索要并验证公钥；

2、双方协商生成"对话密钥"；

3、双方采用"对话密钥"进行加密通信。

--------------------------------------------------------------------------

SSL/TLS协议握手详细过程

“握手阶段”设计四次通讯，且四次通讯都是明文通讯。

1，客户端发出加密通讯请求(ClientHello请求)

包含信息：支持的加密通讯协议版本；一个随机数；支持的加密方法；支持的压缩方法。

2，服务器回应客户端请求(ServerHelloq请求)

包含信息：确定使用的加密通讯协议版本；一个随机数；确认使用的加密方法；服务器证书。如果服务器需要确认客户端身份，还需要包含请求客户端提供客户端证书。

3，客户端回应

客户端受到服务器后，首先验证服务器证书，证书没问题后，客户端会从证书中取出公钥，之后回应客户端。

包含信息：一个随机数用于服务器公钥加密，防止被窃听；编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送；客户端握手结束通知，表示客户端的握手阶段已经结束，这一项同时也是前面发送的所有内容的hash值，用来供服务器校验。该阶段随机数，又称为"pre-master key"。此时客户端和服务端共有三个随机数，接着双方就用事先商定的加密方法，各自生成本次会话所用的同一把"会话密钥"。该密钥就是使用服务器“公钥”加密后的对称加密的密钥。为撒谎是三个随机数，解释如下：

    "不管是客户端还是服务器，都需要随机数，这样生成的密钥才不会每次都一样。由于SSL协议 中证书是静
态的，因此十分有必要引入一种随机因素来保证协商出来的密钥的随机性。对于 RSA密钥交换算法来说，
pre-master key本身就是一个随机数，再加上hello消息中的随机， 三个随机数通过一个密钥导出器最终导出
一个对称密钥。pre-master的存在在于SSL协议不信 任每个主机都能产生完全随机的随机数，如果随机数不随
机，那么pre-master secret就有可 能被猜出来，那么仅适用pre-master secret作为密钥就不合适了，因此
必须引入新的随机因 素，那么客户端和服务器加上pre-master secret三个随机数一同生成的密钥就不容易被
猜出 了，一个伪随机可能完全不随机，可是是三个伪随机就十分接近随机了，每增加一个自由度， 随机性增
加的可不是一。"

4，服务器的最后回应

服务器收到客户端的第三个随机数pre-master key之后，计算生成本次会话所用的"会话密钥"。之后发送回应。

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

注意：

生成对话密钥需要三个随机数。
握手之后的对话使用"对话密钥"加密（对称加密），服务器的公钥和私钥只用于加密和解密"对话密钥"（非对称加密），无其他作用。
服务器公钥放在服务器的数字证书之中。
整个握手过程都是非加密的，如果有人窃听通话，它可以知道双方选择的加密方法和前两个随机数。理论上只要服务器公钥足够长（2048位）pre-master key是无法被破解的。当然为了足够安全，可以替换掉默认的RSA加密算法而使用Diffie-Hellman算法（简称DH算法），此时Premaster secret不需要传递，双方只要交换各自的参数，就可以算出这个随机数。过程如下图
会话的恢复。握手阶段用来建立SSL连接。如果出于某种原因，对话中断，就需要重新握手。目前有两种方法恢复session：session ID 和 session ticket。

session ID：每次对话都有一个编号，重连时，只要客户端给出ID，服务器有这个编号的记录，双方就可以重新使用已有的“对话密钥”，不需要重新生成。当然session ID往往是只保留在一个服务器中的，所以当客户端选择和其他服务器通讯时，需要重新握手。如下图：

session ticket：重连时，客户端发送上一次通话中服务器发送过来的session ticket。这个ticket是加密的，只有服务器可以解密。里面包括了本次对话的主要信息，包括对话密钥和加密方法。session ticket可以避免session ID的缺点。如下图

参考：

http://www.ruanyifeng.com/blog/2014/09/illustration-ssl.html

http://www.ruanyifeng.com/blog/2014/02/ssl_tls.html

https://baike.baidu.com/item/%E9%9D%9E%E5%AF%B9%E7%A7%B0%E5%8A%A0%E5%AF%86

https://baike.baidu.com/item/%E5%AF%B9%E7%A7%B0%E5%8A%A0%E5%AF%86