目前有个需求是防抓包,同时要支持证书无缝升级。(每年都要换一次证书<del>万恶之源</del>,而且运维人员换证书可能不会提前和你说。而且保证存量用户不影响升级)
目前的证书链是这样的
CA -> CA2-> AA
最开始的想法: 比对下 CA 的 hash, 和 AA 证书的 SAN(Subject Alternative Name)。 hash 在白名单并且 SAN 匹配域名那就通过。
后来发现,同样在 CA 申请的合法证书 BB.com 放在 Charles 里面竟然也能通过验证,
浏览器看了下,显示的结构变成
CA -> CA2 -> BB -> AA1
好,再改,将 SAN 验证从叶子到 root 一路验证, 凡是有 SAN 字段的,就验证 SAN,如果不匹配就报错。
然后我想到一点,如果对方从 CA2 申请一个不含 SAN 的证书,岂不是又可以跳过? 我尝试了下, 申请了一个用于代码签名的 证书 CC 放到 Charles 里面,又能跳过验证了。岂可修!!!(当然,浏览器报错)
CA -> CA2 -> CC -> AA2
对了,有时加一个自签名 ca 作为白名单,方便出 bug 自己抓包。
1
zengxs 2021-05-10 18:55:20 +08:00
你的 app 是啥技术开发的,发送 http 请求用的是啥库
|
2
liuidetmks OP @zengxs 原生的 nsurlconnection,和用什么库有关系?
|
3
zengxs 2021-05-10 18:58:39 +08:00
一般就是你自己传一套根证书列表给你的 http client 库就行了,让它别信任系统内置的证书库
|
4
ZeroClover 2021-05-10 19:31:00 +08:00
要无缝升级一般就是 PIN 中间 CA 的指纹就行了。至于用相同中间 CA 签发的其他证书,虽然能过 CA Pin 但是过不了证书有效性验证啊,SAN 是不符的。至于没有 SAN,不符合 X.509 证书规范,正规 CA 不会签出来这种证书。
|
5
ch2 2021-05-10 19:33:59 +08:00
防抓包不太可能
|
6
653513754 2021-05-10 19:51:19 +08:00
一般人不会抓包,抓包的肯定不是一般人.防不住的,增加一点点时间成本而已
|
7
liuidetmks OP @653513754 你也说了,成本问题,我相信我的接口不值得花这么大成本的,嘿嘿😁。
|
8
liuidetmks OP @ZeroClover 我看了下,ca2 那家也提供代码签名的证书的,如果用户直接拿这个放在 Charles 里面,Charles 也是可以正常工作的。
照您这么讲,我得自己实现一次 x509 规范?这个工作量太大了吧,不知道有没有小巧的第三方库,ios android 都支持。 实在不行就只能放弃堵住这条漏洞? 写到这里,忽然觉得您的意思让我检测 ca2,而不是 root ca ? ca2 专门用来签发 ssl 证书,不会去签发用于代码签名的证书? |
9
paxol 2021-05-10 21:43:18 +08:00
SSL Pinning ?
|
10
qmm0523 2021-05-10 21:53:48 +08:00
说白了,防止抓包根本不是解决问题的方法。
你防抓包是为了达成什么样的目的? 如果是为了阻止别人拿接口去写爬虫、注册机、各种自动化薅羊毛等,那可以在接口中加入 token,token 在 jni 中计算,并且想办法保护算法不被逆出来。 如果是为了担心别人通过抓包找到安全漏洞,那更加是掩耳盗铃,只有保证接口本身没有安全问题才行。 |
11
Sricecake 2021-05-10 22:21:21 +08:00
验域名
|
12
wdlth 2021-05-11 00:28:08 +08:00
@liuidetmks 有的证书供应商是这样的,如果是签署 EV 证书,会用专门的中间证书。不需要组织认证,不包含保险的 DV 证书中间证书也可能是专门用于 DV 证书的。
但是有的就很乱,比如 USERTrust RSA Certification Authority,它的子证书有 EV OV 的中间证书,还有用于代码签名的证书。 https://crt.sh/?caid=1167 加钱上 EV |
13
liuidetmks OP |
14
qq960826 2021-05-11 07:17:07 +08:00
这样防抓包根本没意义的,我之前就抓过这种 SSL pining 的包,你客户端都在用户手上,直接把 openssl 给 hook 掉有啥用
|
15
jones2000 2021-05-11 13:17:16 +08:00
app 原生直接用 tcp 自定义协议, 直接 2 进制字节发送。 通用的 http/https 防不了。
|
16
ZeroClover 2021-05-11 18:19:08 +08:00
@liuidetmks 代码签名证书根本没有 TLS 服务器证书的扩展类型,不能用于 HTTPS 。
https://vip1.loli.io/2021/05/11/5oBep3unGdNhgsX.png https://comodosslstore.com/resources/code-signing-certificate-vs-ssl-certificate-whats-the-difference/ 另外,你也说对了,用于签发 TLS 证书的中间 CA 是绝对不能用于签发代码签名或者 S/MIME 证书的,这违反 CA/B 基线。 |