使用 https 后，还有必要用 md5(secret+参数+时间戳)类似这样的方法做数据完整校验吗？

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

• 请不要在回答技术问题时复制粘贴 AI 生成的内容

这是一个创建于 2363 天前的主题，其中的信息可能已经有所发展或是发生改变。

前几天和一个群友争论这个来着，我觉得没有必要再这么做了。https 已经在传输层保证了请求不被篡改和完整性。两者都用的话，算是增加一些别人调用你接口的门槛？但是感觉门槛并不高，在客户端都能找到。

看知乎上有类似话题 https://www.zhihu.com/question/52392988

但是觉得答案都不是太满意。回答说是请求过了负载均衡后，在内网是明文传输，所以不安全？

因此想来看看各位 v 友是怎么看待这个事情。

群友

md5

门槛

知乎

32 条回复 • 2018-07-10 16:37:20 +08:00

zjp

2018-07-09 22:53:32 +08:00 via Android

https 防止不了伪造和重放，这两点理由都足够了

FanWall

2018-07-09 22:58:58 +08:00 via Android

有必要，例如
1、防重放
2、还有纠正一点，加密的代码就算都在客户端不等于门槛就不高，很多这些大厂的客户端加固混淆强度也是不弱的，至少不是说一个初级的黑客抓一下包就知道原始数据了。自然是不存在绝对安全，但可以为黑客制造一些难度啊

dawniii

2018-07-10 00:32:35 +08:00 via Android

@zjp @FanWall 多谢两位的回答。有点疑惑的是，你们说的重放是指中间监听密文重放吗？我记得 ssl 的密文是有序号的，不知道能不能防止这种重放。可能我理解的有偏差。

yumumu

2018-07-10 00:36:04 +08:00 via Android

@zjp 如果有证书校验的话是可以做到防止伪造的

zjp

2018-07-10 00:46:15 +08:00 via Android

@yumumu 安卓端没看到几个软件校验证书的，随便抓包…我也很奇怪为什么不校验

zjp

2018-07-10 00:51:51 +08:00 via Android

@zjp 好像搞错了什么…我想说的伪造和重放都是 Http 层的啊，和证书、SSL 都没有关系

just1

2018-07-10 00:53:21 +08:00

都进内网了啥事干不成？

FanWall

2018-07-10 00:54:41 +08:00 via Android

@yumumu #4
@zjp #5
证书校验的应用很多，只能说可以防止简单的中间人，但一样可以伪造，只能说增加难度，不能说完全防止。

@dawniii #3
这里的重放我不是指 TCP 层面的重放，而是 HTTP 协议层面的重放，其实可以和伪造放一起看待，我是这么理解的，专业的见解等楼下。

seeker

2018-07-10 00:55:31 +08:00

@dawniii TLS 握手的时候攻击，可以重放。http://blog.valverde.me/2015/12/07/bad-life-advice/

crab

2018-07-10 00:56:46 +08:00

@dawniii

防止重放一般 md5(secret+参数+时间戳) & 时间戳

honeycomb

2018-07-10 00:59:01 +08:00 via Android

@dawniii 客户端因为这样那样（比如恶意调用，bug ）的重放。

比如在 v2 发帖，客户端没收到确认发帖成功回复，这个时候用户又点了几次发帖键，发出了几个相同的请求，如果有参数签名无论如何最多只会有其中一个有效，就不容易出现一个帖子发了两遍的问题。

akira

2018-07-10 01:59:51 +08:00

上 https 可以过滤掉百分之九十只会抓明文包的
做个数据校验又可以过滤掉百分之九十不会本地逆向的

安全措施这种东西，在成本允许范围内，从来都是只会嫌少不会嫌多的

chengxiao

2018-07-10 05:36:50 +08:00

回去看抓包的...现在还有不会抓 https 包的吗？

lslqtz

2018-07-10 07:44:11 +08:00

@chengxiao 设备本地上 hpkp，啥抓包都玩完

iwtbauh

2018-07-10 07:48:06 +08:00 via Android

HTTPS 可以保护免受重放攻击，因为 TLS 不是纯粹的加密，中间人拿到密文后并不能直接发送给服务器，必须握手，而握手后

iwtbauh

2018-07-10 07:49:35 +08:00 via Android

HTTPS 可以保护免受重放攻击，因为 TLS 不是纯粹的加密，中间人拿到密文后并不能直接发送给服务器，必须握手，而握手后密钥是新的，所以并不能用之前的密文。

所以中间人是根本没有机会实施重放攻击。

abc612008

2018-07-10 07:52:41 +08:00

secret 一般不是鉴权用的吗…… https 的防止伪造只是对于中间人来说的吧，恶意用户主动伪造 https 是没法阻止的。

mengzhuo

2018-07-10 09:24:54 +08:00

TLS"只"保证传输层的保密防篡改防冒充。名字都起得相当好，Transport Layer Secure。
对 LZ 的问题，人家不保证，你需要的是防止业务请求重放和鉴权。
md5 这个就已经是个漏洞了，自欺欺人而已。

p.s. 说能抓 https 包的，你们怕不是对 TLS 有什么误解吧？
你们都能物理接触或者有控制权的情况下，任何安全措施都是白搭。
说中间人的，你们试试双向证书校验的环境下抓抓包？

owt5008137

2018-07-10 09:43:11 +08:00 via Android

数据完整性校验 AEDA 了解一下？防重放的话 DH/ECDH 或者 RSA 每次服务端随机密钥。防中间人劫持可以通过只信任你自己的 CA 实现。

所以最简单的方法就是 https 配成密钥协商 ecdh+证书认证 ecdsa+加密算法 aes-128/192/256-gcm 或者 chacha20-poly1305。然后客户端设置成只信任自己的 CA。

完事儿。

he15hiss

2018-07-10 09:44:03 +08:00

首先看你这个接口是否公开的，如果是公开的，任何浏览器都可以访问，那不存在加密一说(大家都能看)，当然如果这个接口带有一些敏感信息，应该加密，如果是想让别人抓不了这个接口，那双向认证了解一下

wizardoz

2018-07-10 09:54:49 +08:00

https 不只是 http + SSL，https 还包含了 CA 证书，中间人是无法伪造证书的。
还有 https 抓包的，没有服务端私钥，你能解密抓到的包？

dawniii

2018-07-10 09:57:03 +08:00

@dawniii 非常感谢大家的回复，受益匪浅。上面很多说的重放，原来是指的业务上的重放。

@seeker 发的这篇文章挺好的，解释了为什么 tls 不会被中间人重放。

http://blog.valverde.me/2015/12/07/bad-life-advice/

TLS 通过为每个连接导出一组新密钥并为每个记录分配唯一的序列号来保证加密流是不可重放的。
这可以防止攻击者复制这些记录并在另一个连接上重放这些记录，因为加密密钥不匹配。
在同一连接上重放它们也不起作用，因为序列号不匹配，并且记录将被拒绝。

但是中间人可以破坏连接，有的客户端会实现自动重试一次，这样来达到客户端自己重放的效果。

一般类似支付的接口，应该都是有业务状态来保持幂等的，发生重复支付的几率应该很低。

@honeycomb 您说的客户端抽风等原因，导致重复发帖的问题。貌似用到 nonce timestamp 来做请求的验证就行。并不需要再加一个 md5 校验，因为 tls 已经保证了请求的完整，感觉 md5 这部分事情做的重复了。

暂时的结论是 https 已经满足大部分场景，保证了请求的完整、不被篡改、加密。
md5(secret+参数+时间戳)这种方式，有两个作用。第一个是防止业务上的重放（如果只是防止业务重放是没必要 md5 的），第二个是增加恶意调用接口的门槛。

a7a2

2018-07-10 09:59:03 +08:00

https 不能保证不被篡改和完整性。

中间人攻击，真是过浏览器证书认证的中间人攻击。
假设攻击者是另外一个 ssl 证书提供商+勾结电信运营商或入侵你 dns 系统呢？
政府具备以上权限

玩过一下阿里 api 市场，人家阿里也是做数据完整校的。
不信技术也信人家大企业。

BOYPT

2018-07-10 10:08:57 +08:00

传输层和业务层的“安全”完全是两个层面的东西，各有各的应用和需求，不能混为一谈。

另外楼上有说安卓不校验证书，这点不是很准确，Android 7+是强制独立 app 校验证书，我尝试系统安装自签证书，vpn 中间人抓包一些 app 的 https，都不能成功，直接拒接握手； Android 6 上是可以的。

dawniii

2018-07-10 10:13:14 +08:00

@a7a2 如果被这么高权限机构的针对，那么自己写的类似 md5 签名方法，感觉也是不堪一击啊。。。

a7a2

2018-07-10 10:21:23 +08:00

@dawniii 看了我最后一段了嘛？阿里如何做的跟上即可。
加了据完整校的话可以越过我上面说的第二段，至少加大了难度。

dawniii

2018-07-10 10:30:45 +08:00

@a7a2 想了想得分两种情况来看，服务端调用还是客户端调用。
如果是在服务端调用 api，这个 md5 里有一个保密的 secret，篡改的难度还是挺大的。如果是客户端调用的话，就会比较不堪一击了。

iwtbauh

2018-07-10 11:44:47 +08:00 via Android

@a7a2 那么这个 CA 证书就会随后被各大操作系统和浏览器厂商拉黑。这么快就忘了上回的 CNNIC 乱签证书事件了？
如果客户端可控，HTTPS public key pinning 了解一下

a7a2

2018-07-10 11:46:26 +08:00

http(s) header：
sign=md5(客户端 ip+body 内容+公共 secret 通过 https 获取+如需要认证类的加上用户名手机号码之类+每个安装前先注册，每个安装 app 内置不同的 userSecret，这个 userSecret 存到后端数据库，就是说每个安装都即时编译即时下载，这样破解一个客户端不影响其他用户，反中间人修改数据的+不重复的 timestamp 就是精确要高+hash 版本号)
timestamp=timestamp 的具体数字
hashVersion=1.0
mobile=13516521122

公共 secret 不出现在 header 中，公共 secret 可控制频率之类，看客户端业务类型设计了，实时性高的这个不要了

这个 hash 方式入侵 /破解者是未知的.

以上方式有一个绝对反中间人修改数据的，每一个安装量都内置不同的 userSecret，userSecret 在请求中不需要暴露在 header 中，神一般存在。这个是以前准备写 VPN 时候想到的

@dawniii

反正如果我是技术负责人我一定要求加上，安全最重要

小锁是用来防君子的，遇上大劫匪也无可奈何。正如贪腐成本不大的我也贪

想象一下我是一个垃圾技术员但是我管理着广东电信所有路由，突然有天发现你安装量上亿的 app 没有数据完整性校验，我开个菠菜网站在你 app html 页面插入广告。

Heavytiger

2018-07-10 12:10:52 +08:00

mark

zjp

2018-07-10 12:30:17 +08:00 via Android

@BOYPT 还是你这样表述明晰，md5(secret+参数+时间戳)是业务的需要

关于校验证书的，安卓 7 确实已经不信任自签证书。但我要说的安卓软件内置的校验，我只遇到过酷安有

xud6

2018-07-10 16:37:20 +08:00

secret 是为了增加伪造难度吧。如果用了 HTTPS Client Authentication 的话感觉没有也没关系。