网络原理|[网络] SSL/TLS协议的原理机制 TLS协议|网络协议|密钥协商|S

文章目录

- 概述
- SSL/TLS的历史
- 加解密的两种方法
- 保护数据内容的两个方面
- - 数据解密内容是否正确
  - 对称密钥协商过程
- 中间总结
- 对称密钥协商过程（进阶）
- 最后总结

概述我们每天都在使用互联网，所有数据都要通过计算机网络进行传输，网络本身只具备传输数据的能力，并不能保证数据的安全性。
数据在公共网络中移动的时候，很容易被第三方截获、篡改，造成信息泄漏、中间人攻击等各种网络安全性问题。
这就是计算机网络的真实情况，也是SSL/TLS协议诞生的背景！
要解决的问题：能够在不安全的网络环境中，安全的传输数据。
安全性体现在两个方面：

数据可以被截获，但是内容不能泄漏。
数据无法被篡改，一旦中途被篡改，客户端或者服务端拿到数据后立即就能发现。

SSL/TLS的历史 1994年，NetScape公司设计出SSL（Secure Sockets Layer）协议1.0版，但是未发布。
1995年，NetScape公司发布SSL 2.0版，很快发现有严重漏洞。
1996年，SSL 3.0版问世，得到大规模应用。
1999年，互联网标准化组织ISOC接替NetScape公司，发布了SSL的升级版TLS 1.0版。
2006年和2008年，TLS进行了两次升级，分别为TLS 1.1版和TLS 1.2版。
2011年发布了TLS 1.2的修订版。
2014年提出TLS 1.3版本，直到2018年才正式纳入标准。
综上所述，SSL和TLS就是同一个东西，因为历史版本原因，有了两个名字，可以认为TLS是SSL的升级版。
但是更为常用的名字还是SSL，所以下文为了叙述方便，统一称为SSL协议。
加解密的两种方法实现SSL协议的安全性，基本思路就是数据加密。
从密码学原理来看，加解密需要密钥，具体方法可分为两种：

对称加密：加解密使用同一个密钥，这个密钥既能加密，又能解密。
非对称加密：加解密使用一对密钥，密钥分公钥和私钥，公钥加密只有私钥能解，私钥加密只有公钥能解。

SSL就是基于这两种加密方法，完成数据安全性的保障，具体怎么运用的，继续看下文。
保护数据内容的两个方面先来做一个约定：在网络通信过程中，发送数据的一方称为客户端，接收数据的一方称为服务端，从网络中窃取数据的一方称为第三方。
SSL协议采用对称加密来保护数据，客户端和服务端在发送数据之前，协商出一个密钥，发送者用这个密钥对数据加密，之后再扔到网络中传输，服务端拿到数据后用相同的密钥解密，还原数据内容。
在网络传输过程中，如果数据被第三方截获，他没有对称密钥，是解不出来数据内容的。因此，数据内容可以得到保护，不会泄漏。
如果第三方截获密文数据以后，尝试替换或者修改密文数据，客户端或服务端拿到数据以后，用对称密钥解不出来正确内容，立刻就能知道数据出现了问题！
此时，就会出现两个问题：

解密数据以后，客户端和服务端怎么知道数据内容是否正确？
这个对称密钥是怎么协商出来的？

数据解密内容是否正确
不论客户端还是服务端，解密结果无非就是两种情况：

解密失败！可以判定数据一定不对，因为解密算法都搞不定。
解密成功！收到了内容，但是内容对不对不知道。

此时，就需要网络应用层协议发挥作用了，比如客户端发送的是http协议内容，如果服务端能够解析成功，那内容就是对的，如果解析失败，内容肯定是有问题的！客户端同理。
至于错误内容，到底是双方发的就有问题，还是被第三方篡改的，已经不重要了。
SSL协议只是保证双方都能够正确接收到彼此传输的内容，在解密成功的情况下，判断内容对不对是应用层协议的事情。
通常来讲，如果数据被第三方篡改了，即使解密成功了，得到的内容也是一堆乱码，除非第三方真的神通广大，拿到了对称密钥，给出了正确的密文数据！
对称密钥协商过程
这个过程就是SSL协议最核心也是最关键的部分，理解了对称密钥协商过程，也就真正理解了SSL协议。
客户端和服务端所有通信都是基于网络的，因此，对称密钥协商过程也是通过网络进行的，不仅如此，协商过程发送的数据内容几乎还都是明文传输的！
密钥协商过程中的所有元数据都能被第三方截获！
客户端和服务端在第三方监视下协商出对称密钥，还能不被第三方获取到，这就是SSL协议的巧妙之处！
具体实现要用非对称加密方法，服务端提前在本地环境中生成非对称密钥，私钥自己保管好，公钥可以给任何人。
协商过程如下（先这样理解，实际有出入，后面进阶部分纠正）：

客户端通过网络请求，向服务端索取公钥。
客户端随机生成一个对称密钥。
客户端将对称密钥用公钥加密，然后通过网络发送给服务端。
服务端拿到以后用私钥解密，得到对称密钥。

因为公钥加密只有私钥能解，而私钥只有服务端有，所以，第三方即使截获到密钥协商数据，因为没有私钥，也无法解密获取对称密钥。
中间总结至此，SSL协议工作原理机制就算是讲完了，稍微总结一下：

SSL协议实现包含两种加密方法：对称加密，非对称加密。
非对称加密只进行一次，就是最开始协商对称密钥的时候，目的就是为了能安全传输对称密钥。
对称加密为应用层协议数据进行加密，数据内容由应用层协议定义。
对称加解密的效率远高于非对称加解密，所以，两种加密方式结合使用，也是SSL协议在保障安全的前提下尽可能提高效率的办法。
如果不考虑效率问题，SSL协议完全可以有另外一种实现方案：通信过程全部采用非对称加密方式，客户端和服务端各自保管私钥，互换公钥，之后的过程使用非对称加密传递数据。

对称密钥协商过程（进阶）文章上半部分是对SSL协议最基本的原理分析，下半部分详细讲述一下对称密钥的协商过程，属于原理进阶吧。
前面为了好理解些，将对称密钥协商过程归纳如下：

客户端通过网络请求，向服务端索取公钥。
客户端随机生成一个对称密钥。
客户端将对称密钥用公钥加密，然后通过网络发送给服务端。
服务端拿到以后用私钥解密，得到对称密钥。

其实，这样说是不对的，真实原理过程比这复杂些～～～
真实环境中，协商对称密钥相对比较复杂的，实现方案从理论上讲不唯一，有多种理论参考模型，虽然手段可能有差异，但是目的都是为了保障数据的安全性。
对称密钥协商过程又叫“握手阶段”，可类比传输层TCP协议的握手阶段，只不过TCP是三次握手，标准的SSL协议模型是四次握手。
第一次握手
客户端发出加密通信请求，称为ClientHello，提供以下一些信息：

客户端支持的协议版本，比如TLS 1.0版。
客户端生成一个随机数，稍后用于生成"对话密钥"。
客户端支持的对称加密方法，比如RSA公钥加密。
客户端支持的压缩方法。

第二次握手
服务端收到请求后回应数据，称为SeverHello，回应信息：

服务端确认使用的加密通信协议版本，比如TLS 1.0版本。如果没有匹配版本，服务端关闭加密通信。
服务端生成的一个随机数，稍后用于生成"对话密钥"。
确认使用的加密方法，比如RSA公钥加密。
服务端数字证书，证书里面包含服务端基本信息以及公钥。

数字证书可以通过各种途径自己生成，但是这样的证书没有社会公信力，还是容易被第三方冒名顶替。
正确的做法是，拿着自己的基本信息和公钥去找权威证书颁发结构，也就是常说的CA机构，从他们哪里获取具有公信力的证书。
CA机构会用自己的私钥对证书进行签名，所以这样的证书是无法被篡改的，也能得到所有客户端的认可和校验。
第三次握手
客户端收到响应信息后，首先要验证服务端数字证书，如果证书颁布机构不可信、或者证书中包含的基本信息与服务端不一致、又或者证书已经失效，就会告知当前用户，询问用户是否还要继续通信。
如果数字证书验证通过，或者用户人为选择继续通信，客户端就从证书中提取服务端公钥，并向服务端再次发送信息：

再次生成一个新的随机数，用服务端公钥加密。
客户端加密方法变更通知，表示随后信息都将用双方协商的加密方法和对称密钥发送。
服务端握手结束通知，表示服务端的握手阶段结束。这一项同时也是前面发送的所有内容的hash值，用来供服务端校验。

第四次握手
注意前面握手阶段提到的随机数，到目前为止，双方都掌握了三个随机数。
两个由客户端生成，一个明文传输给服务端，一个用服务端公钥加密后传输给服务端。
一个由服务端生成，明文传输给客户端。
确定好这三个随机数，客户端和服务端就可以在各自的本地环境中，根据密钥生成器生成对称密钥。数学原理可以保证客户端和服务端生成的密钥是一样的，并且，该密钥无需再次经过网络传输，可以有效避免对称密钥的泄漏问题！
因为第三个随机数是用公钥加密传输的，第三方无法解开，所以，即使第三方截取到另外两个随机数，也不可能根据密钥生成器生成协商出来的对称密钥！
因此，对称密钥就在不安全的网络环境中，安全的产生了。
服务端验证客户端的hash值，并生成对称密钥以后，返回客户端响应信息：