https加密机制解析

本质：采用非对称加密方式，用于加密的密钥是客户端生成的随机密钥

转载：https://blog.csdn.net/handsomexiaominge/article/details/81158431

https是目前最流行运用最广泛的安全http形式，早年由netscape首创，目前所有的浏览器均支持此技术，这篇博文主要简单的解析https的加密机制

从下图可以了看出，https和http最主要的区别在于，https比http多了一层加密层SSL/TLS，接下来会简单解释https相关的加密原理

理解https的加密原理，首先要了解一下以下概念

数字加密
数字加密由明文，密钥，密文组成，明文通过密钥的加密，会生成对应的密文，目前主流加密方式有对称加密和非对称加密

对称加密：
对称加密是指对数据的加密和解密用的是同一个密钥，可以用密钥对明文进行加密，反之亦然，性能相对于非对称加密会好一些，速度较快，在对称加密算法中常用的算法有：DES、3DES、TDEA、Blowfish、RC2、RC4、RC5、IDEA、SKIPJACK、AES等

非对称加密：
非对称加密跟对称加密不同，密钥分为公钥和私钥，数据通过公钥加密之后，可以用私钥进行解密，反之，用私钥进行加密之后，也可以用公钥进行解密，公钥一般是分发给客户端使用，对外是公开的，而私钥则一般是服务端保留，不对外公开，常用的非对称加密算法有RSA、Elgamal、背包算法、Rabin、D-H、ECC等，目前RSA是应用最广泛的非对称加密算法

数字签名
正式一点说，数字签名就是附加在报文上的特殊校验码。通俗简单一点说，用私钥加密产生的密文称之为签名，一般用来校验身份，证明作者编写了这段报文，举个栗子，一段报文里有a,b,c三个字段，为了证明这段报文是真正的作者发送的，没有经过他人篡改，作者会用自己持有的私钥将当前报文进行加密产生密文，然后随同报文一起发送出去，之后持有公钥的用户会用公钥将报文解密，将解密之后的明文和发送过来的报文实体进行对比，如果此时所有的字段都匹配上了，即可验明身份，可参考以下流程

数字证书
数字证书可以理解为http通信过程中的一张id卡，用于识别身份，使用上述提到的数字签名技术，证书中会包括对象名称，过期时间，证书发布者，来自发布者的数字签名，公钥等字段，https通信过程中使用数字证书来验证通信这的身份，权威机构（例如CA）颁布的证书可以被大部分的客户端所信任，具体的交互过程下面会提到，关于证书的构成可以看一下这张图

https加密机制
首先，https的作用在于，防止http通信过程中，信息被第三者监听，甚至篡改，比较被人熟知的手法称为中间人攻击，攻击手法大概可以用下图表示

当无加密的http通信被第三方拦截，第三方攻击者即可随意篡改报文，攻击方法运用最广泛的莫过于dns劫持，http网站之所以会被无端挂广告，正是因为运营商在通信过程中修改了返回的报文，在返回的数据中添加了广告代码。

正是出于防止篡改的目的，https通信过程发生了以下的步骤：

1.客户端发送初始请求该请求包含客户端支持的加密算法列表供服务器选择，出于性能考虑，这些算法一般来说都是对称加密算法

2.服务器接收请求，返回服务器生成的数字证书和选择的加密算法，此时公钥作为证书的一部分一并传给客户端

3.客户端接收服务器传回的证书和加密算法，此时，客户端，例如浏览器会首先校验证书的合法性（校验方法后续详细说），如果此时校验失败，客户端会立刻发出警告，由用户决定是否继续，如果校验成功，此时客户端则会针对服务器传回的加密算法，生成一个随机的密钥，并用公钥加密之后，发送给服务端

4.服务端接收到客户端传回的随机密钥之后，用持有的私钥进行解密，取得客户端发送的随机密钥，此时服务端会使用当前密钥，对数据进行对称加密之后传给客户端

5.客户端取得加密数据之后，用上一个回合生成的密钥解开密文，取得响应数据

6.客户端和服务端会持续使用约定的密钥对数据进行加密交互

关于证书认证
那么，客户端是怎么校验当前的证书是否合法的呢，包括以下几个方面

1.证书有效日期

当前日期如果已经超过了有效期或者证书尚未被激活，则有效性验证失败

2.证书颁发者可信度

客户端会维护一个证书机构信任列表，可信任的机构（如CA）颁发的证书会被客户端所信任，用户自主导入的证书，也会被客户端所信任，当证书颁发机构不被信任时，有效性验证失败

3.签名校验

这也是最关键的一步，上文提到，服务端对证书签名的时候是对报文用私钥进行加密，此时客户端需要用公钥对签名进行解密，然后跟报文的关键字进行比较，有任何一项匹配不上，都会导致有效性验证失败，这一步主要是防止请求被篡改

4.站点身份校验

这一步浏览器会校验证书中的域名和当前客户端所对话的服务端的域名是否匹配，防止服务器复制他人的证书，如果不匹配，校验失败

关于中间人攻击与https
那么，是否使用https就能避免中间人攻击了呢，答案其实是否定的，考虑以下这种情况，当中间人也拥有权威机构颁布的证书，并且中间人拦截了客户端和服务器通信，此时当客户端开始和服务端进行通信时，第三方拦截者会把请求拦截下来，把自己的公钥发送给客户端，并且伪造一个请求给服务端，并接收服务端传回的公钥，这样一来，客户端用公钥加密的数据，第三方拦截者能用自身的私钥解开，对于服务端用私钥加密回传的数据，拦截者能用公钥解开，此时，所有的交互中间人都将一清二楚，包括最终双方约定的对称加密密钥，并且客户端和服务端并不会发现任何的异常

所以，如何解决这个问题，答案是内置公钥，客户端提前将服务端颁布的根证书导入，保证客户端始终使用了正确的公钥，这也是支付宝等金融机构会提示用户安装根证书的原因，防止数据泄露或者被篡改，当然安装根证书必须十分谨慎，一旦被误导安装了错误的根证书，导致的后果将十分严重
--------------------- 
作者：小敏哥 
来源：CSDN 
原文：https://blog.csdn.net/handsomexiaominge/article/details/81158431 
版权声明：本文为博主原创文章，转载请附上博文链接！