1
zxlzy 2021-01-13 18:58:59 +08:00
是的,证书是 CA 颁发的,如果 CA 被攻击了,签发了假的证书,https 就被破解了。
|
2
JaaaaackZheng OP @zxlzy 这样啊,我还想问一下。使用 dns 劫持的方式,我把发向 CA 服务器的请求劫持了伪造 CA 服务器,这样感觉加入 CA 也只是增加了中间人攻击的步骤而已。
|
3
ericwood067 2021-01-13 19:07:00 +08:00
@JaaaaackZheng 除非你黑了 CA 的服务器,拿到他的私钥,只劫持发给 CA 服务器的请求是没用的。
|
4
also24 2021-01-13 19:09:05 +08:00 1
简单点来说:不存在 『发向 CA 服务器的请求』
大部分 CA 的信息,是直接内置在 操作系统 / 网络库 中的。 你也可以手动信任其它 CA,来协助这些 CA 对你进行中间人(例如抓包的时候)。 另: 严格来说,OCSP 请求属于 『发向 CA 服务器的请求』,OCSP 请求也确实可以被劫持,此处暂不谈。 |
5
smileawei 2021-01-13 19:09:25 +08:00
所以 CA 供应商的审计是十分严格的。每年缴纳大量的保证金。还有各种审计。
之前中国大陆的几家 CA 公司都因为不合规被 Google 和 Mozilla 拉黑。 可以自行百度 CNNIC CA 和沃通 CA 的事情。 |
6
smileawei 2021-01-13 19:13:58 +08:00
https://www.williamlong.info/archives/4183.html
CNNIC 的这个行为就是你说的 CA 供应商做中间人。这个用户无法察觉,所以仅这一件事。CNNIC 的 CA 就彻底不被浏览器信任了。 |
7
Tumblr 2021-01-13 19:16:03 +08:00
@JaaaaackZheng #2 呃。。。怎么说呢,感觉你应该先了解一下黑 CA 服务器的难度有多大……可能比猜中私钥的难度还要大。。。不管是在物理层面(社工)还是技术层面。
首先抛开技术层面,单是物理层面的防护,就超出了相当相当相当大部分人的想象。 |
8
JaaaaackZheng OP @smileawei 我指的是增加个中间人攻击,伪装成 CA 来响应客户端请求。你好像说的跟我不是一回事
|
9
weyou 2021-01-13 19:21:45 +08:00 via Android 1
纯属想多了系列。CA 的证书内置在客户端设备中,验证都是本地验证,并没有什么 CA 服务器来帮助验证,除非你有客户端的控制权,否者单靠中间人是无法攻破 HTTPS 的
|
10
JaaaaackZheng OP @Tumblr 利用 DNS 劫持 OCSP 请求这样会很难吗,不是黑 CA 服务器喔。
|
11
also24 2021-01-13 19:23:42 +08:00 1
@JaaaaackZheng #8
因为你把证书的验证过程理解错了。 证书的验证过程不是说浏览器拿着证书去服务器问:这个证书我可以信任嘛? 而是操作系统 /浏览器 /网络库,早就内置好了自己信任的 CA 的证书,当需要验证的时候直接在本地进行比对。 这个过程中,是不存在网络请求的,自然也就无从拦截。 再次备注: 为了方便理解,这里暂时不讨论 OCSP 的情况。 |
12
also24 2021-01-13 19:24:32 +08:00
@JaaaaackZheng #10
我这里提到 OCSP 是为了防杠 ,你先假装这个东西根本不存在,不要搭理他。 |
13
JaaaaackZheng OP |
14
carlclone 2021-01-13 19:27:52 +08:00 via Android
可以,这就是 fiddler 的原理,但是只能建立新会话,已经建立的连接依旧没办法中间人攻击
|
15
weyou 2021-01-13 19:28:13 +08:00 via Android 1
你把 CA 证书和用户证书弄混了,内置的 CA 证书很少会发生改变。用户自己证书是部署在用户自己的服务器上的,在上网过程中并不再存在跟 CA 服务器的通信。
|
16
lanternxx 2021-01-13 19:33:11 +08:00 1
@JaaaaackZheng #13 SSL 证书从来就都不需要 CA 服务器介入验证,任何时候的都不需要。可信任的根证书是预置于客户端本地的。
OCSP 是用来检查证书吊销状态的,它不能使无效的证书变有效。 |
17
also24 2021-01-13 19:33:16 +08:00 1
@JaaaaackZheng #13
所以说你没理解整个证书机制,证书机制自身是不需要联网验证的。 它只需要确认,你拿来验证的这个证书,是由内置的可信任证书签发的就行了。 这个验证过程是基于签名机制的,不需要联网。 附加内容: 但这个机制有个缺陷,就是证书一旦签发,就没有撤回的机会了,因为所有的验证过程都可以离线完成。 因此才出现了前面提到的 OCSP,它需要联网查询吊销列表。 劫持它确实是可行的,但是并不能让一个不受信任的证书变成信任,只能让被吊销的正牌证书暂时不被认出。 |
18
CEBBCAT 2021-01-13 19:40:52 +08:00
干脆打回重学证书签发流程吧…… 学而不思则罔 思而不学则殆
|
19
JaaaaackZheng OP |
20
JaaaaackZheng OP (*Φ皿Φ*)知道错了各位大佬,立刻滚去学习
|
21
zxlzy 2021-01-13 20:05:07 +08:00
@JaaaaackZheng 我误解了你的意思,但是我的回复是没错的......
|
22
littlewing 2021-01-13 20:14:50 +08:00
很简单,学 12306,弹出一个框要你安装并信任证书,然后大多数不懂的人就会安装,然后就可以随便玩了
|
23
namelosw 2021-01-13 20:48:53 +08:00
这个东西跟 JWT 验签类似, 三方信任的时候, 消费方和签发方是没有请求, 单纯靠密码学原理工作的.
|
24
pkoukk 2021-01-14 09:40:17 +08:00
https 其实是一个信任链,根在 CA 证书上,只要证书没问题,整个链路都是可信的
|
25
dorothyREN 2021-01-14 10:24:41 +08:00
@Tumblr #7 CA 服务器一般都是离线的。
|
26
smileawei 2021-01-14 11:33:16 +08:00
@JaaaaackZheng #8 是中间人呀。你拿到可信的 CA 服务器。就可以自己任意签发可信的证书了。然后再做中间人肯定就没办法察觉了。
|
28
v2tudnew 2021-01-14 11:42:29 +08:00
那么问题来了,假设用户 CA 根证书被掉包,如何简单发现呢?
|
29
kajweb 2021-01-14 11:57:00 +08:00
Hi,你可以 star 我的项目: https://github.com/kajweb/stop-debugger
介绍一下:利用中间人攻击修改网页源码。 主要流程: 1 、启动服务 2 、信任 CA 证书(加到系统) 3 、启动 SNI 服务器,生成对应域名的证书 4 、愉快的代理 https |
30
julyclyde 2021-01-14 12:38:28 +08:00
问题是合规的 CA 根本不上网
|
31
disk 2021-01-14 15:50:03 +08:00
@v2tudnew 可信根证书表可以查的,比如 https://www.ccadb.org/ ,和本地比对下指纹就知道了。
|
33
mxT52CRuqR6o5 2021-01-14 16:16:27 +08:00
CA 根证书是存在浏览器或系统里的,属于先验信息
根据 CA 根证书通过信任链一层一层信任到网站的证书(如果网站的证书链不全,本地也没有缺失的链路证书,就可能导致验证失败),过程是离线的 |