https原理及流程

web通信主要用http、https两种方式，我们都知道https相对http来说更安全，因为https是基于加密传输的，但是具体https的原理之前我一直没弄懂过。。

https=http+ssl，https相当于在http的基础上加了ssl(Secure Sockets Layer 安全套接层)，ssl在传输层对网络进行加密。

当前计算机的通信主要面对两大类威胁，即主动攻击和被动攻击

当客户端传输信息给服务端的时候，如果没有加密算法，信息容易被截获甚至篡改，为了保障通信的安全，目前主要的加密方式有对称加密和非对称加密两种。

对称加密：加密密钥和解密密钥是相同的 

非对称加密：私钥是保密的，公钥向公众公开，信息发送方用公钥加密信息，发送给信息接受方，接收方用私钥解密信息。

在实际的web通信中，只要发送方和接收方知道密钥，而其他第三方不知道，那么这种使用对称加密的方式就是可靠的，但是在实际的应用场景中，用多个客户端请求同一个服务器，当他们都使用同一个加密算法，相同都密钥的时候，这无异于是不安全的

所以实际上A端、B端。。。使用哪种加密算法不应该是固定的，而应该随机生成，像下面这个亚子

所以客户端和服务器又一个协商用那个加密算法的过程，那么，，这个协商过程，也设计到信息传输，是不是也不安全呢。。。

所以协商过程也得加个密吧？协商过程怎么加密？不能再用对称加密了，不然这问题还就用无止境了。看看上图这网络结构，非对称加密还挺适合的，server有一个私钥，而其他网络节点有公钥，用私钥加密的信息公钥都能解，而公钥加密的信息只有私钥能解，服务器只要自己保存好私钥，把公钥公开，其他客户端就能用公钥加密了。

因此https采用非对称加密算法来解决对称加密的协商过程那么，客户端要如何获取公钥呢？如果服务器将公钥分发，势必会出现公钥被劫持的情况吧，黑客可以劫持公钥，对服务器发出的信息进行破解

所以我们希望客户端看到的是真真正正的服务器发送过来的公钥，服务端看到的是真正客户端发送过来的信息，希望信息不被截获和篡改。这里就需要第三方对信息双方的身份进行一个确认，这就是ssl 证书的作用，ssl证书中包含了证书办法机构，有效期，公钥、证书持有者、签名，通过第三方的校验保证了身份的合法，解决了公钥获取的安全性

如上图所示，在第 ② 步时服务器发送了一个SSL证书给客户端，SSL 证书中包含的具体内容有证书的颁发机构、有效期、公钥、证书持有者、签名，通过第三方的校验保证了身份的合法，解决了公钥获取的安全性

以浏览器为例说明如下整个的校验过程：

（1）首先浏览器读取证书中的证书所有者、有效期等信息进行一一校验

（2）浏览器开始查找操作系统中已内置的受信任的证书发布机构CA，与服务器发来的证书中的颁发者CA比对，用于校验证书是否为合法机构颁发 

（3）如果找不到，浏览器就会报错，说明服务器发来的证书是不可信任的。

（4）如果找到，那么浏览器就会从操作系统中取出  颁发者CA  的公钥，然后对服务器发来的证书里面的签名进行解密

（5）浏览器使用相同的hash算法计算出服务器发来的证书的hash值，将这个计算的hash值与证书中签名做对比

（6）对比结果一致，则证明服务器发来的证书合法，没有被冒充

（7）此时浏览器就可以读取证书中的公钥，用于后续加密了

 

总结一下：

HTTPS要使客户端与服务器端的通信过程得到安全保证，必须使用的对称加密算法，但是协商对称加密算法的过程，需要使用非对称加密算法来保证安全，然而直接使用非对称加密的过程本身也不安全，会有中间人篡改公钥的可能性，所以客户端与服务器不直接使用公钥，而是使用数字证书签发机构颁发的证书来保证非对称加密过程本身的安全。这样通过这些机制协商出一个对称加密算法，就此双方使用该算法进行加密解密。从而解决了客户端与服务器端之间的通信安全问题。