Https如何保证了数据的安全？
文章主要分析和讲解突出握手的过程
1. 一种不安全通信案例
http明文传输和下方案例中数据传输都是不安全的。
2. 数字证书
2.1 为什么要有数字证书？
对于请求方来说，它怎么能确定它所得到的公钥一定是从目标主机那里发布的，而且没有篡改过呢？亦或这请求的目标主机本身就从事窃取用户信息的不正当行为呢？这时候，我们需要有一个权威的值得信赖的第三方机构（一般由*审核并授权的机构）来统一对外发放主机机构的公钥，只要请求方这种机构获取公钥，就避免了上述问题的发生。
2.2 数字证书的颁发过程
用户首先产生自己的**对，并将公钥及部分个人身份信息传送给认证中心。认证中心在核实身份后，将执行一些必要的步骤，以确信请求确实由用户发送而来，然后认证中心将发给用户一个数字证书，该证书包含用户的个人信息和他的公钥信息，同时还附有认证中心的签名信息（根证书私钥签名）。用户就可以使用该证书进行相关的各种活动。数字证书由独立的证书颁发机构发布，数字证书各不相同，每种证书可提供不同级别的可信度。
2.3 证书内容
- 持有者姓名（Common Name）
- 证书颁发机构的名称（Issuer）
- 有效日期（Validity）
- 证书持有人的公钥（Subject’s Public Key Info）
- 扩展信息 （Extension）
- 用发证机关对该证书的数字签名（Certificate Signature）
2.3 摘要算法
摘要算法是一个神奇的算法，也称为散列或者散列值。是一种与基于**（对称**或公钥）的加密不同的数据转换类型。散列就是通过把一个叫做散列算法的单向数学函数应用于数据，将任意长度的一块数据转换为一个定长的、不可逆转的数字，其长度通常在128～256位之间。所产生的散列值的长度应足够长，因此使找到两块具有相同散列值的数据的机会很少。常见的摘要算法：MD5，SHA-1，MAC（Message Authentication Code），CRC（Cyclic Redundancy Check）。
2.4 数字签名
数字签名技术就和对“非对称**加解密”和“数字摘要”两项技术的应用，它将摘要信息用发送者的私钥加密，与原文一起传送给接收者。接收者只有用发送者的公钥才能解密被加密的摘要信息，然后用HASH函数对收到的原文产生一个摘要信息，与解密的摘要信息对比。如果相同，则说明收到的信息是完整的，在传输过程中没有被修改，否则说明信息被修改过，因此数字签名能够验证信息的完整性。
数字签名的过程如下：
明文 ——> hash算法 ——> 摘要 ——> 私钥加密 ——> 数字签名
数字签名有两种功效：
一、能确定消息确实是由发送方签名并发出来的，因为别人假冒不了发送方的签名。
二、数字签名能确定消息的完整性。
注意：
数字签名只能验证数据的完整性，数据本身是否加密不属于数字签名的控制范围
SSL协议是通过非对称**机制保证双方身份认证，并完成建立连接，在实际数据通信时通过对称**机制保障数据安全性
3. 数字证书的作用
1、身份授权：确保浏览器访问的网站是经过CA验证的可信任的网站。
2、分发公钥：每个数字证书都包含了注册者生成的公钥（验证确保是合法的，非伪造的公钥），在SSL握手时会通过certificate消息传输给客户端。
3、验证证书合法性：客户端接收到数字证书后，会对证书合法性进行验证，只有验证通过后的证书，才能够进行后续通信过程。
4. SSL/TSL建立连接过程
4.1 客户端发出请求（ClientHello）
由于客户端(如浏览器)对一些加解密算法的支持程度不一样，但是在TLS协议传输过程中必须使用同一套加解密算法才能保证数据能够正常的加解密。在TLS握手阶段，客户端首先要告知服务端，自己支持哪些加密算法，所以客户端需要将本地支持的加密套件(Cipher Suite)的列表传送给服务端。除此之外，客户端还要产生一个随机数，这个随机数一方面需要在客户端保存，另一方面需要传送给服务端，客户端的随机数需要跟服务端产生的随机数结合起来产生后面要讲到的 Master Secret 。
综上，在这一步，客户端主要向服务器提供以下信息：
- 支持的协议版本，比如TLS 1.0版
- 一个客户端生成的随机数，稍后用于生成"对话**"
- 支持的加密方法，比如RSA公钥加密
- 支持的压缩方法
4.2 服务器回应（SeverHello)
服务端在接收到客户端的Client Hello之后，服务端需要确定加密协议的版本，以及加密的算法，然后也生成一个随机数，以及将自己的证书发送给客户端，这里的随机数是整个过程的第二个随机数。
最后服务端会发送一个Server Hello Done消息给客户端，表示Server Hello消息结束了。
在这一步，服务器的回应包含以下内容：
- 确认使用的加密通信协议版本，比如TLS 1.0版本。如果浏览器与服务器支持的版本不一致，服务器关闭加密通信
- 确认使用的加密方法，比如RSA公钥加密
- 一个服务器生成的随机数，稍后用于生成"对话** "( Session Secret)
- 服务器数字证书
4.3 客户端回应（Certificate Verify）
Client Key Exchange
如果服务端需要对客户端进行验证，在客户端收到服务端的 Server Hello 消息之后，首先需要向服务端发送客户端的证书，让服务端来验证客户端的合法性。（双向认证）
Certificate Verify
接着，客户端需要对服务端的证书进行检查，如果证书不是可信机构颁布、或者证书中的域名与实际域名不一致、或者证书已经过期，就会向访问者显示一个警告，由其选择是否还要继续通信。如果证书没有问题，客户端就会从服务器证书中取出服务器的公钥。然后，向服务器发送下面三项信息：
- 一个随机数。该随机数用服务器公钥加密，防止被窃听
- 编码改变通知，表示随后的信息都将用双方商定的加密方法和**发送
- 客户端握手结束通知，表示客户端的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，用来供服务器校验（使用 Session Secret 会话秘钥加密 ）
Master secret：由系列的随机数的hash值组成，用来生成 Session Secret。文末附计算方式
这个随机数，是整个握手阶段出现的第三个随机数，它是客户端使用一些加密算法(例如：RSA, Diffie-Hellman)产生一个48个字节的Key，这个Key叫 PreMaster Secret，很多材料上也被称作 PreMaster Key。
PreMaster secret 前两个字节 是TLS的版本号，这是一个比较重要的用来核对握手数据的版本号，因为在Client Hello阶段，客户端会发送一份加密套件列表和当前支持的SSL/TLS的版本号给服务端，而且是使用明文传送的，如果握手的数据包被**之后，攻击者很有可能串改数据包，选择一个安全性较低的加密套件和版本给服务端，从而对数据进行**。所以，服务端需要对密文中解密出来对的PreMaster版本号跟之前Client Hello阶段的版本号进行对比，如果版本号变低，则说明被串改，则立即停止发送任何消息。
4.4 服务器的最后回应（Server Finish）
服务端在接收到客户端传过来的 PreMaster 加密数据之后，使用私钥对这段加密数据进行解密，并对数据进行验证，这样 服务端和客户端都有一份相同的PreMaster secret和随机数，也会使用跟客户端同样的方式生成 Session Secret（秘钥）。
一切准备好之后，会给客户端发送一个 ChangeCipherSpec，告知客户端已经切换到协商过的加密套件状态，准备使用加密套件和 Session Secret加密数据了。之后，服务端也会使用 Session Secret 加密一段 Finish 消息发送给客户端，以验证之前通过握手建立起来的加解密通道是否成功。
根据之前的握手信息，如果客户端和服务端都能对Finish信息进行正常加解密且消息正确的被验证，则说明握手通道已经建立成功，接下来，双方可以使用上面产生的Session Secret对数据进行加密传输了。
4.5 ChangeCipherSpec（更改密码规范） 说明
ChangeCipherSpec是一个独立的协议，体现在数据包中就是一个字节的数据，用于告知服务端，客户端已经切换到之前协商好的加密套件（Cipher Suite）的状态，准备使用之前协商好的加密套件加密数据并传输了。
在ChangecipherSpec传输完毕之后，客户端会使用之前协商好的加密套件和Session Secret 加密一段 Finish 的数据传送给服务端，此数据是为了在正式传输应用数据之前对刚刚握手建立起来的加解密通道进行验证。
参考文献
SSL/TLS协议运行机制的概述
SSL/TLS原理详解
Https SSL/TLS Session Secret(Key)计算
Https SSL/TLS PreMaster/Master Secret(Key)计算