为什么在HTTPS基础上仍需对接口请求和响应进行加解密？

---

HTTPS协议的基础原理与传输层保护

HTTPS（Hypertext Transfer Protocol Secure）协议是在HTTP协议的基础上，通过SSL/TLS加密层提供了数据传输的安全性。HTTPS协议的主要作用在于通过证书和加密算法，为客户端和服务器之间建立一个安全的传输隧道，使得传输过程中的数据不会被第三方窃取或篡改。它的加密主要是在传输层（Transport Layer）进行保护，确保客户端与服务器之间的通信在网络传输过程中不会被中途拦截或窥探。

应用层的数据安全需求与接口加解密的必要性

虽然HTTPS在传输层提供了加密保护，但是客户端侧仍然可能被攻击者在客户端设备上安装一个未受信任的根证书，那么攻击者就可以充当一个中间人，伪造服务器的证书，并与客户端建立一个看似合法的HTTPS连接。这种情况下，客户端会认为它正在与真实的服务器通信，而实际上所有数据都经过了攻击者的计算机，导致数据被截取。

未加密接口的风险

如果接口仅依赖于HTTPS的传输层加密而不进行应用层加密，则存在以下风险：

1.可以通过代理抓包软件，直接对请求进行抓包。以转转APP为例，我们抓取转转APP的获取首页商品信息接口，该接口并没有进行加密。

2.得到接口入参与响应后我们可以直接利用接口调试工具调用这个接口，并且可以通过修改接口参数的方式获取大量数据，如下图我设置pageSize=500，接口就一次性返回500条商品数据。

3.甚至有些工具可以直接拦截客户端发出的请求，在这次看似合法的请求中修改参数，导致出现不可预知的后果。

行业内的应用加解密案例

许多知名企业已经在接口通信中广泛应用了加解密技术。例如：

• 淘宝：在金融支付接口中，使用多层加密技术，包括传输层HTTPS和应用层的数据加密，确保交易数据的完整性与安全性。

  

• 天猫精灵APP：智能家居场景下也会有很多关于用户及产品的隐私数据，需要被保护。

  

这些公司通过应用层的加解密，进一步确保了接口通信的数据安全，避免了未授权访问和数据泄露的风险。

我们的接口加解密方案

为确保数据的安全性，我们设计并采用了以下接口加解密方案：

1. 非对称加密的密钥交换

• • 密钥管理：客户端和服务器各自维护公钥和私钥，确保双方的密钥不会被泄露或未授权使用。
  • 对称密钥加密：在客户端发起请求前，首先使用非对称加密（如RSA算法）对一个临时生成的对称密钥进行加密。这个对称密钥在整个请求和响应过程中用于数据加密，确保高效的加密处理。

1. 请求加密与签名

• • 请求加密：客户端在发出请求前，使用生成的对称密钥对请求内容（数据荷载）进行加密。这样即使请求被拦截，攻击者也无法直接读取数据内容。
  • 请求签名：在加密完成后，客户端会生成一个签名，附加到请求中，以确保该请求的完整性。签名生成基于请求内容和私钥，保证数据在传输过程中未被篡改。

1. 服务器端的签名验证与解密

• • 签名验证：服务器在接收请求后，首先使用公钥验证签名的有效性，以判断数据在传输过程中是否被篡改。若签名不匹配，则视为不合法请求，立即终止处理。
  • 请求解密：签名验证通过后，服务器使用私钥解密传输的对称密钥，再用该密钥解密请求的数据荷载，获取原始数据。

1. 响应加密

• • 响应加密：服务器在生成响应数据后，再次使用对称密钥对响应内容进行加密，然后返回给客户端。
  • 客户端解密：客户端接收到响应后，使用本地保存的对称密钥解密响应内容，确保数据在传输返回过程中也受到保护。

通过上述方案，数据在请求发起、传输、验证、响应整个生命周期中均受到加密保护，极大地降低了数据泄露、篡改和未授权访问的风险。