HTTP协议有哪几种加密方式呢

  后面的第三步和第四步是进行真实生产环境数据请求过程

  第四步发送完成后，客户端接收到服务端加密的数据serverX使用公钥publicKey解密即可

  第五步和第六步就是对称加密，每次携带协商好的对称加密密钥randomNumber进行数据交互。

• 这种方式的加密数据依然存在漏洞，这里的漏洞在于第一步验证服务端公钥CPK；通过客户端系统内写死的证书与CPK的验证。客户端（手机之类的）被我们拿回家去，把客户端中的写死的证书给换了，换成charles或者fiddler这种拦截者的证书。
  
  

  为了避免这种请求发生，现在手机一般不允许被获取超级权限，所以你的证书就修改不了。

• 另一种方式是通过修改客户端处理发送请求和接收请求的方法，把验证证书的那段逻辑机制给干掉，不论是谁的CPK都认为是正确的CPK。
  
  

  防止验证逻辑机制***掉，监测系统内有无 干掉验证证书工具，如果存在不运行该客户端，直接退出。

在看到https协议的时候，首先要明确一点知道，https协议包括对称加密，非对称加密，证书验证的http协议；不能看到https协议就说非对称加密。
HTTP明文传输

类似于如下图的明文传递，如果在客户端与服务端加上拦截，拦截传递的报文，那么轻松可以知道他们之前传输的内容是啥，将无秘密可言。

HTTP对明文加密传输（对称加密）

我们已经知道了，明文传递是不安全的，在客户端和服务端之间加了拦截可以轻松获取报文。为了解决这个问题，对客户端和服务端进行加密传输。
服务端和客户端共同持有 相同密钥 key，在传输的过程中对报文data进行加密成x，不管是客户端还是服务端收到另一端的密文，使用 相同密钥 key进行解密。这种加密方式也是对称加密。
缺点： 都有缺点，在互联网软件中，客户端是众多的。如果是客户端和服务端，客户端的密钥对应服务端的密钥是唯一的，此时服务端仅仅存放这个加密密钥就已经很多了，这种方式不可取。
另一种方式是客户端和服务端有相同的密钥，但是如果伪造一个客户端，骗到这个密钥，其他客户端发送的加密报文无异于是明文传递了。

注： 其实大部分公司的RESTFul接口调用就是采用对称加密这种方式，每个客户端与服务端存放的都是不同的密钥。究其原因是因为业务量小，服务端能够针对每个客户端存放这么多密钥。
HTTP非对称加密方式

非对称加密方式请求建立需要完成四个步骤（这里不是指协议层面的那种三次握手，这里的非对称加密方式已经是建立了连接）
非对称加密，客户端存放了公钥publicKey，服务端存放了私钥secretKey。公钥每个客户端都可以获取，而私钥只有服务端才有。

1 客户端向服务端明文请求获取公钥publicKey
2 服务端明文响应把publicKey响应给客户

  后面的第三步和第四步是进行真实生产环境数据请求过程

3 客户端通过获取的公钥publicKey，对发送的data进行加密x = encode(publicKey, data)，以密文x发送给服务端
4 服务端接收到第三步的密文x，使用私钥secretKey进行解密data = decode(secretKey, x) 得到客户端发送的data数据。服务端响应数据serverData，使用私钥加密后 serverX = encode(secretKey, data) 发送给客户端。

  第四步发送完成后，客户端接收到服务端加密的数据serverX使用公钥publicKey解密即可

缺点： 非对称加密解决了客户端与服务端存放密钥的问题，服务端只需存放公钥和私钥即可。在客户端请求时，下发一个公钥给客户端。但是但是这里有一个致命的缺点，客户端向服务端发送数据，只有私钥才可以解密，那么只要服务器不被攻击，客户端向服务端发送的报文是无法破解的；然而公钥是公开的，其他客户端很容易获取到，在服务端向客户端发送加密报文，这个报文很容易使用获取到的公钥进行破解。对于非对称加密，这也是不安全的。
HTTP协议非对称与对称加密结合方式

前面有对称加密和非对称加密的HTTP协议，他们都有各自缺点。对称加密要想安全服务端需要针对不同客户端都持有不同的密钥；而非对称加密在服务端向客户端发送时密文时，由于公钥很容易获取，服务端向客户端发送的密文无秘密可谈。
通过上文的论述，非对称加密的优点是解决了对称加密的服务端存放密钥过多的问题，如果将对称和非对称结合，那么是一种很好的解决方式。

第一步和第二步与非对称加密没有区别，客户端向服务端请求公钥publicKey，服务端下发响应公钥publicKey；
3 在完成第一步和第二步后，客户端随机生成一个随机数randomNumber，通过公钥publicKeyx = encode(publicKey, randomNumber)加密发送给服务端；
4 服务端获取到密文x，使用私钥secretKey进行解密得出报文randomNumber；关键的来啦，那么此时服务端知道randomNumber内容，以randomNumber为对称加密的密钥。服务端响应给客户端一个OK，同意randomNumber为后续对称加密的密钥。（在一些抓包过程中，你可以看到服务器在响应报文只有一个OK或者success，目的就是这一步）

  第五步和第六步就是对称加密，每次携带协商好的对称加密密钥randomNumber进行数据交互。

注： 这里有人会问，服务端根据协商好的密钥randomNumber还需要存取很多的密钥；在我的开发经验中，服务端不保存，是每次请求是客户端会发送通过publicKey加密的randomNumber，然后服务端使用私钥secretKey解密出randomNumber。然后再根据解密后的randomNumber，再去解密对称加密的密文数据。
缺点： 通过对称与非对称结合的方式认为已经无懈可击了。然而在第一步是有破绽的，因为第一次请求publicKey无法保证能够有效到达服务端；所以拦截者的破解方式应运而生。 下面详细解释一下，怎么把对称与非对称结合的方式破解掉。

在客户端向服务端请求的还未开始前，在服务端和客户端之前添加一个拦截者。
1 客户端向服务端请求公钥pk，此时拦截者接收到客户端请求公钥，拦截者自己请求服务端获取真正的pk；然后把自己的pkH发送给客户端；
2 客户端接收到pkH生成一个随机数randomNumber，使用pkH拦截者公钥加密发送给服务端；拦截者立马拦截这种请求，使用自己的私钥skH去解密pkH加密的密文，得到randomNumber。拦截者获取randomNumber后，根据自己获得的服务端pk对randomNumber随机数字进行加密，发送给服务端。
3 服务端响应randomNumber密钥可以作为对称加密的密钥，发送给客户端，拦截者会立刻拦截这种请求，然后拦截者再发送给客户端说是可以的。
第五步和第六步就以及后继的操作一直是，客户端发送给服务端，其实不是发送给服务端而是发送给拦截者了。然后拦截者再发送给服务端。通过这种操作，拦截者能够看到所有服务端与客户端的所有的请求报文。所以对称和非对称加密是不安全的。
HTTP协议非对称与对称加密结合 + 证书验证形式

通过对称加密和非对称加密结合形式，从缺点我们看出，客户端与服务端被拦截后，拦截者自己伪造一个公钥pkH发送给客户端。然后客户端还是认为这个公钥是服务端的，傻傻的拿着这个伪造的公钥发送加密发送数据。
解决这个缺点就是使得客户端有能够知道公钥和私钥是不是服务端发送的；不要让客户端傻傻的，让他有一个能去验证公钥的地方，每次拿到公钥给验证公钥地方去验证一下，这个公钥是不是合法的。不是合法的，不能再请求客户端了，有人做手脚了。
1 CA证书写入服务端中，CA证书含有CPK和CSK；在客户端请求服务端公钥pk时，服务端为了保证他的是有特点的（为了客户端验证公钥是否有问题），对其公钥pk使用CA证书的私钥csk进行加密。
2 服务端将加密的公钥pk密文License响应给客户端，客户端拿到已经加密后的密文License，对License用cpk解密得出pk。

此时会有疑问，客户端解密License是需要向CA证书结构请求公钥cpk解密，在网络请求这中间可能会被拦截。为了避免该问题再次发生，CA证书在服务端和客户端均直接写死在操作系统内。写死在操作系统内的证书用公约cpk解密出License，如果解不出或者其他情况，那么就不是服务端公钥。

• 这种方式的加密数据依然存在漏洞，这里的漏洞在于第一步验证服务端公钥CPK；通过客户端系统内写死的证书与CPK的验证。客户端（手机之类的）被我们拿回家去，把客户端中的写死的证书给换了，换成charles或者fiddler这种拦截者的证书。
  
  

  为了避免这种请求发生，现在手机一般不允许被获取超级权限，所以你的证书就修改不了。

• 另一种方式是通过修改客户端处理发送请求和接收请求的方法，把验证证书的那段逻辑机制给干掉，不论是谁的CPK都认为是正确的CPK。
  
  

  防止验证逻辑机制***掉，监测系统内有无 干掉验证证书工具，如果存在不运行该客户端，直接退出。

1 举报