简单易懂的https原理解析
https与http的区别
http是明文传输的，非常不安全，容易被人窃取和篡改传输的内容。
https通过混合加密、摘要算法、数字证书等技术解决了http传输不安全的问题。
https其实就是在http与TCP之间多加一层SSL或TLS协议。
混合加密
要理解混合加密，需要先理解对称加密和非对称加密。
对称加密
对称加密就是加密和解密都使用同一个密钥，这种方式加解密速度快但是不安全，如果密钥被对方窃取到，就可以很简单的解密出数据。
非对称加密
非对称加密就是加解密使用的密钥不是同一个密钥，而是一对密钥------公钥和私钥。这密钥对是由服务端生成的，私钥一般是服务端自己保存，而公钥则会通过某种途径发放给客户端。非对称加密的特点就是公钥加密的数据只有对应的私钥能解密，私钥加密的数据只有对应公钥能解密。
比如客户端利用服务端发放的公钥对即将传输的数据进行加密，服务端利用私钥对客户端发送过来的数据进行解密。
但是由于非对称加密的性能较低，所以一般不会直接使用非对称加密传输数据。非对称加密更常用的场景是数字签名，这种场景一般是服务端用自己的私有加密，客户端用服务端的公钥解密。而且加解密的对象不是数据，而是通过hash算法以即将传输的数据作为参数算出的一个hash值，这个hash值经过服务端的私钥进行加密之后，就是数字签名。
- 服务端对要传输的数据通过hash算法算出一个hash值，然后对这个hash值使用私钥进行加密。
- 客户端接收到加密后的数字签名和数据后，通过公钥解密得到服务端算出的hash值。
- 客户端自己再通过相同的hash算法计算得出hash值。然后两个hash值进行比较，如果相等则说明数据确实是来源于服务端，这个数据是可信的；如果两个hash值比较后发现不相等，那就说明这个数据是被篡改过的，不是来源于服务端的数据。
非对称加密由于使用的是一对密钥而不是同一个密钥，所以安全度相比对称加密要高，但是加解密速度较慢。
混合加密解析
由于对称加密不安全，非对称加密性能又较差，所以就组合它们俩，就有了混合加密。
首先通过非对称加密，客户端使用服务端公钥把数据传输时使用的对称密钥加密传输给服务端，服务端使用私钥解密得到对称密钥。然后后续客户端与服务端之间使用对称密钥进行数据传输。
- 一开始，客户端利用服务端发放的公钥，给对称密钥进行加密，加密后的对称密钥发送给服务端。
- 服务端接收到加密后的对称密钥之后，就利用自己的私钥进行解密，得到客户端发来的对称密钥。
- 此时客户端和服务端都拥有了同一对称密钥，后续客户端和服务端之间的数据传输都使用该对称密钥进行加密。
混合加密问题
混合加密有一个问题，就是服务端的公钥如何传输给客户端而不被中间者篡改，如果这个问题不解决，单靠混合加密也是不安全的，典型的例子就是中间人攻击。
所以还需要数字签名和数字证书。数字签名是通过摘要算法算出的hash值再利用服务端私钥加密得到的，而数字证书则是由有公信力的CA机构颁发的CA证书。
摘要算法
摘要算法可以让数据接收方校验接收到的数据是否与数据发送方发送的数据一致。
数据发送方通过一个约定好的hash算法，待传输的数据作为参数，算出一个hash值，把这个hash值与数据一起传输。接收到数据的一方，根据约定好的hash算法，利用接收到的数据作为参数，算法出一个hash值，然后把这个算出来的hash值与接收到的hash值进行比较，如果两hash值相等，则校验通过，否则校验不通过。
通过摘要算法，数据接收方就可以验证数据发送方发来的数据是否完整，是否与数据发送方发出的数据一致。这种方式可以解决数据在传输的过程中由于一些意外情况导致的数据错乱的问题，但是无法防止他人的恶意攻击。
比如发送的报文被第三者截获，可以修改掉数据，然后用相同的算法重新计算hash值，这样接收数据的一方也无法发现。因此通常这个hash值还要用私钥进行加密，变成一个数字签名。
数字签名的原理上面已经描述过，可以看出有了数字签名，只要不发生中间人攻击，就没啥问题。但是如果服务端颁发的公钥被中间人截获，他自己重新生成一对新的公私钥，再把中间人自己的公钥冒充服务端的发给客户端，那么客户端还是不知道的。于是就需要用到数字证书。
数字证书
数字证书原理
为了解决公钥被伪造的问题，就需要用到数字证书，数字证书使得客户端能够验证他接收到的公钥是否可信。
- 首先，服务端把自己的公钥注册到CA机构。
- CA机构利用摘要算法，以服务端的公钥为参数，算出一个hash值，然后利用CA机构自己的私钥对这个hash值进行加密得到一个数字签名。CA机构把数字签名和服务端公钥作为CA证书的一部分，给服务端颁发一个证书。
- 客户端请求服务端时，服务端首先给客户端发送CA机构颁发的证书。
- 由于有公信力的CA机构的公钥都已经预置到操作系统里面，客户端可以通过操作系统内置的CA机构公钥对证书中的数字签名进行解密，得到hash值，再以证书中的服务端公钥为参数算出另一个hash值，如果两个hash值一致，则校验通过，说明服务端公钥可信，否则就是校验不通过，不会使用该公钥加密传输数据。
- 如果校验通过，客户端使用这个公钥进行加密传输。
为什么通过CA证书可以解决中间人攻击的问题呢？
因为CA机构的私钥，中间人是没有的。而CA机构的公钥又是操作系统内置，操作系统内置的都是有公信力的CA机构的公钥。
因此，即使中间人截获了服务器传输给客户端的证书，自己搞一个假证书，里面带上自己的公钥，等这个假证书传到客户端，客户端也是校验不通过的。
https握手流程
如果使用https协议，那么在TCP三次握手完毕后，要进行TLS协议的握手流程。
- 客户端生成一个随机数C并向服务端发送，服务端返回一个ack报文
- 服务端生成一个随机数S并向客户端发送，再发送证书，然后再发送一个Done报文，客户端收到Done报文后返回一个ack报文
- 客户端验证证书是否有效，如果证书验签通过，则取出里的服务端公钥，然后客户端生成一个随机数pre-master key，使用服务端的公钥加密，发送个服务端
- 客户端和服务端双方，使用随机数C、随机数S、随机数pre-master key生成一个对称密钥
- 客户端发送报文告知服务端后续使用对称密钥通讯，然后发送Finished报文，服务端返回一个ack报文
- 服务端发送报文告知客户端后续使用对称密钥通讯，然后发送Finished报文，客户端返回一个ack报文
可以看到，客户端使用服务端公钥加密传输的并不是对称密钥本身，而是一个随机数。而对称密钥是通过三个随机数计算生成的，这三个随机数分别是客户端生成的随机数C、服务端生成的随机数S、以及客户端生成并使用服务端公钥加密传输的pre-master。
