Https原理分析

一、Https简介

    HTTPS其实是有两部分组成：HTTP + SSL / TLS，也就是在HTTP上又加了一层处理加密信息的模块。服务端和客户端的信息传输都会通过TLS进行加密，所以传输的数据都是加密后的数据。下面具体分析是如何进行加密，解密，验证的。在了解原理之前，先熟悉下涉及的基本知识。

    由于SSL/TLS中涉及到了加密和解密算法，数字签名的知识点，下面简要说明下这几点内容：

1、加密算法

    数据加密的基本过程就是对原来为明文的文件或数据按某种算法进行处理，使其成为不可读的一段代码，通常称为“密文”，使其只能在输入相应的密钥之后才能显示出本来内容，通过这样的途径来达到保护数据不被非法人窃取、阅读的目的。

    加密技术通常分为两大类：“对称式”和“非对称式”。

    对称式加密：就是加密和解密使用同一个密钥，通常称之为“Session Key ”。常见对称加密算法：RC4，RC2，DES等。

    非对称式加密：就是加密和解密所使用的不是同一个密钥，通常有两个密钥，称为“公钥”和“私钥”，它们两个必需配对使用，否则不能打开加密文件，如果用“公钥”对数据进行加密，只有用对应的“私钥”才能解密；如果用“私钥”对数据进行加密，那么只有用对应的“公钥”才能解密。这里的“公钥”是指可以对外公布的，“私钥”则不能，只能由持有人一个人知道。常见非对称加密算法：RSA，Elgamal，Rabin等。

    非对称加密的缺点是加解密速度要远远慢于对称加密。

2、消息摘要

    消息摘要（Message Digest）又称为数字摘要(Digital Digest)。它是一个唯一对应一个消息或文本的固定长度的值，它由一个单向Hash加密函数对消息进行作用而产生。如果消息在途中改变了，则接收者通过对收到消息的新产生的摘要与原摘要比较，就可知道消息是否被改变了。因此消息摘要保证了消息的完整性。常用HASH算法：MD5，SHA1，SHA256。

3、数字签名

    数字签名主要使用私钥来加密消息摘要和其他信息，譬如一个序列号,虽然任何人都可以使用公钥解密数字签名，只有发送方知道私钥。这意味着，只有发件人可以签署了该消息。包含了信息摘要的签名表示这个签名只对这个消息有效，而且它确保了消息的完整性，即这个消息的发送过程中没人可以改变摘要并另外对它做签名。

    数字签名实例讲解：https://www.cnblogs.com/BigFeng/p/5267712.html

4、什么是SSL/TLS

    官话说SSL是安全套接层(secure sockets layer)，TLS是SSL的继任者，叫传输层安全(transport layer security)。说白点，就是在明文的上层和TCP层之间加上一层加密，这样就保证上层信息传输的安全。它存在的唯一目的就是保证上层通讯安全的一套机制。

二、HTTPS原理简析

    HTTPS很好的解决了HTTP的三个缺点（被监听、被篡改、被伪装），HTTPS不是一种新的协议，它是HTTP+SSL(TLS)的结合体，SSL是一种独立协议，所以其它协议比如smtp等也可以跟ssl结合。HTTPS改变了通信方式，它由以前的HTTP—–>TCP，改为HTTP——>SSL—–>TCP；HTTPS采用了共享密钥加密+公开密钥加密的方式。

    HTTPS在传输数据之前需要客户端（浏览器）与服务端（网站）之间进行一次握手（SSL连接），在握手过程中将确立双方加密传输数据的密码信息。

1、TLS/SSL握手流程

    握手流程，主要完成两个工作，（1） 客户端向服务器端索要并验证公钥。（2） 双方协商生成"对话密钥"。下面具体分析握手流程。需要注意的是，"握手阶段"的所有通信都是明文的。

    握手阶段涉及四次阶段

第一阶段：

    客户端向服务器发出加密通信的请求，这被叫做ClientHello请求。在这一步，客户端主要向服务器提供以下信息。

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

第二阶段：

    服务器收到客户端请求后，向客户端发出回应，这叫做SeverHello。服务器的回应包含以下内容。

• 确认使用的加密通信协议版本。如果浏览器与服务器支持的版本不一致，服务器关闭加密通信。
• 一个服务器生成的随机数，稍后用于生成"对话密钥"。
• 确认使用的加密方法，比如RSA公钥加密。
• 服务器证书。

第三阶段：

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

    如果证书没有问题，客户端就会从证书中取出服务器的公钥。然后，向服务器发送下面三项信息。

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

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

第四阶段：

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

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

    此次握手阶段结束，为什么一定要用三个随机数，来生成"会话密钥"。

    不管是客户端还是服务器，都需要随机数，这样生成的密钥才不会每次都一样。由于SSL协议中证书是静态的，因此十分有必要引入一种随机因素来保证协商出来的密钥的随机性。

    对于RSA密钥交换算法来说，pre-master-key本身就是一个随机数，再加上hello消息中的随机，三个随机数通过一个密钥导出器最终导出一个对称密钥。

    pre master的存在在于SSL协议不信任每个主机都能产生完全随机的随机数，如果随机数不随机，那么pre master secret就有可能被猜出来，那么仅适用pre master secret作为密钥就不合适了，因此必须引入新的随机因素，那么客户端和服务器加上pre master secret三个随机数一同生成的密钥就不容易被猜出了，一个伪随机可能完全不随机，可是是三个伪随机就十分接近随机了，每增加一个自由度，随机性增加的可不是一。

2、Https数据传输过程

    服务端和客户端的信息传输都会通过TLS进行加密，所以传输的数据都是加密后的数据。具体是如何进行加密，解密，验证的，且看下图。

参考链接：

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

https://blog.csdn.net/clh604/article/details/22179907

https://blog.csdn.net/wangjun5159/article/details/51510594

https://blog.csdn.net/kobejayandy/article/details/52433660