在 HTTPS 时代对请求进行签名是否还有必要？

[cheetah]

今天看到百川大模型的接口文档 https://platform.baichuan-ai.com/docs/api 中要求对请求内容和时间戳进行签名，想到前几天在 V2EX 看到的帖子吐槽腾讯大模型 API 的签名( https://v2ex.com/t/975832 )。

而我们去看 OpenAI 等公司提供的 API ，是不需要这种签名的。

所以想讨论一下，在 HTTPS 时代这种签名是否还有必要？还是一种思维惯性？

我的理解：在 HTTPS 之前，这样的签名可以有效防止请求内容被篡改，是很有必要的，但现在 HTTPS 普及了，这里的好处并不存在了。另一点是重放攻击，我了解不多，请懂的朋友讲讲。

[cheetah]

@zhleonix 认真审题啊

[cheetah]

@kingfalse 讲讲，为什么可以防爬虫

[cheetah]

@wy315700 “一个是传输层安全，一个是应用层安全，根本不同的应用场景” 不等于应用层要把传输层已经解决的安全问题再解决一遍呀。你后面举得那个例子倒是有些道理的。

[rekulas]

@CRUD 那我只需要简单修改序号和时间戳就可以重放攻击了
于是为了进一步防重放你需要把时间戳等参数用 key 加密传个密文过去...
于是变成了签名

[nicoljiang]

《在 HTTPS 时代对请求进行签名是否还有必要？》

[nicoljiang]

如果不加上这些你回复里才提到的“一些前提”，单就这标题，你自己觉得没必要吗？

[j8sec]

@wudaye 内网没用，得入侵到本机才行

[j8sec]

回答下答主的问题：

**使用了 HTTPS** 只是保护了用户的数据：这种情况可以防止黑客在网络层（包括公网、内网）截取或者串改数据。
**请求签名** 通常会结合 HTTPS 使用。我们假设一种情况，如果用户本身是个黑客、攻击者，怎么防止（或者加大成本）黑客的请求篡改攻击行为？请求签名+加密就由此而生，加密请求后，如果是 Web 、安卓环境通常还需要对代码混淆、加壳，加大反编译破解成本。当然，这种操作无法杜绝攻击行为，但可以让过去几秒钟的攻击成本提升至数小时（高手），甚至数天，让攻击者的篡改得不尝失.

国产厂商还在考虑通过签名来防止篡改；而 Apple 和 Windows 在新版本终端硬件要求厂家提供 TPM 模块，提供硬件可信；同时 Google 已经考虑在 Chrome 加入网页可信验证功能了[1]，尝试从系统、浏览器底层杜绝请求篡改.

- [1]. Web Environment Integrity(网页可信环境 API) https://github.com/RupertBenWiser/Web-Environment-Integrity/blob/main/explainer.md

[Masoud2023]

我最开始也有一样的问题，我记得我甚至还发过差不多的帖子。

其实本质上这个东西依然存在的意义就是为了防止请求重放，也有可能靠那个 sign 再做一个幂等之类的。

[CRUD]

@rekulas #84 TLS 中，会对每次请求发送的数据进行 MAC 计算，MAC 算法的输入包括 数据 + 序号 + MAC 密钥，也就是说你想将某次请求的序号+1 然后进行重放的话，除了修改序号，还需要知道在握手协商环节所生成的密钥值，重新进行 MAC 计算才行。

[HTTPS 到底有多复杂，能防止重放攻击吗？]( https://zhuanlan.zhihu.com/p/360782536)

[106npo]

真有问题 Google API 早就被攻陷了,都用了十几年了,等不着现在我们来讨论.

[liu938651469]

GPT：在 HTTPS 时代，对请求进行签名的必要性取决于具体的使用情境和安全需求。HTTPS 提供了数据传输的加密和身份验证，它使用了公开密钥基础设施（ PKI ）来确保通信的机密性和完整性。但是，仍然有一些情况下，对请求进行签名可能仍然有必要：

1. **身份验证的强度**：HTTPS 可以确保通信双方的身份，但它可能无法确保请求的发出者就是合法的用户或应用程序。对请求进行签名可以增加对请求方身份的额外验证层级。

2. **完整性保护**：虽然 HTTPS 可以确保数据在传输过程中不被篡改，但它不一定能够确保请求的完整性。如果攻击者能够截获并篡改请求，签名可以用于验证请求是否在传输过程中被篡改。

3. **非 HTTPS 环境**：并非所有的通信都在安全的 HTTPS 环境下进行。在一些非 HTTPS 环境中，如局域网内部通信或内部系统之间的通信，对请求进行签名可以增加安全性。

4. **防止重放攻击**：签名可以用于防止重放攻击，攻击者可能会记录并再次发送有效请求，以欺骗服务器执行不必要的操作。签名可以包括时间戳等信息，以确保请求不会被重复执行。

5. **附加授权信息**：签名可以包括授权信息，以指定请求的权限和访问级别。这有助于服务器在处理请求时更精确地确定用户或应用程序的权限。

需要注意的是，对请求进行签名也会增加复杂性和计算成本。因此，在决定是否对请求进行签名时，需要综合考虑安全需求、性能和开发成本等因素。如果 HTTPS 提供的安全性足够满足您的需求，那么额外的请求签名可能并不是必要的。但对于某些高度敏感的应用程序或特定的使用情境，请求签名可能是一个有价值的安全增强措施。

[fengpan567]

secret 又不是只做签名校验，里面可能还包含了时间戳和身份证信息，防内鬼还是很有必要的

[FrankAdler]

有些请求是有实效性要求的，比如监测性的上报，或者需要计费，加上时间戳签名以及校验是有必要的，可能部分细分场景没必要，但是加上夜无伤大雅

[realpg]

@cheetah #46

我直接暴力破解 api key 阁下又当如何应对？
比如我知道 api key 是个 32 位 16 进制字符串，我直接暴力扫描，哪个能返回正确的 api ，说明这个 api key 是有效的。
我可能控制一大堆肉鸡去扫，万一扫到了你的，你突然发现腾讯给你的账单多了多了五百万元
你跟腾讯说你没调用五百亿次，腾讯说我这边记录调用就是五百亿次

你跟腾讯说凭啥说我调用了五百亿次
腾讯说就是五百亿次
你问腾讯 他冒充我调用凭啥？
腾讯说，凭他有你的 app secret 啊！欸不对，我怎么把 app secret 删了 那好吧 给你免了五百万

[106npo]

@realpg 有签名就没法爆破了?照样可以爆破

[cheetah]

@realpg 这个场景下签名无效。另外你有没有算过这个数量级啊，如果真可行 OpenAI 早破产了。

[Breacher]

最近在接 Stripe 的核心 API ，它的商业模式比腾讯更加复杂重要，也没有用稀奇古怪的签名。使用 HTTPS ，接口交互的流程最重要就是保护好 API key ，而不是做无用的签名，你的签名泄漏是别人自然能够循着签名文档造出一个合法的签名来。

[LynFt]

当然有必要,可以理解为君子锁,小偷去偷自行车一扛就走,那卖自行车锁的难道都是智商税?签名的目的不是防止攻击,而是提高攻击的难度

[106npo]

@LynFt 那这个问题就是已经自带一个银行保险柜级的锁之后,还要不要再加一个君子锁