V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
baobao1270
V2EX  ›  信息安全

ACME http-01 验证的缺陷: ISP 可以合法地签发伪造的 SSL 证书

  •  
  •   baobao1270 · 2023-10-27 12:13:53 +08:00 · 3782 次点击
    这是一个创建于 389 天前的主题,其中的信息可能已经有所发展或是发生改变。

    https://blog.gslin.org/archives/2023/10/21/11401/isp-%e5%81%bd%e9%80%a0%e5%87%ba%e5%90%88%e6%b3%95%e7%9a%84-ssl-certificate%ef%bc%8c%e5%b0%8d%e6%94%be%e5%9c%a8%e5%be%b7%e5%9c%8b%e7%9a%84-xmpp-ru-%e9%80%b2%e8%a1%8c-mitm-%e7%9b%a3%e8%81%bd/

    很多人认为 ISP 并不能监听 HTTPS ,讲了很多 TLS 的原理,却没想到其实只需要简单的修改 IP 路由就能获取合法的 SSL 证书,而恰恰是 http-01 这一验证方式给了他们便利。

    42 条回复    2023-10-28 04:10:56 +08:00
    gps949
        1
    gps949  
       2023-10-27 12:44:51 +08:00
    所以需要证书透明度
    tyzandhr
        2
    tyzandhr  
       2023-10-27 12:49:58 +08:00 via Android
    这其实就是 shadow tls 的原理
    bankroft
        3
    bankroft  
       2023-10-27 12:50:04 +08:00   ❤️ 1
    还是信任问题,dns challenge 方式 nameserver 服务商也是可以获取证书的,只不过 le 公开发行的证书,而且这么干是不道德的并且可能违法
    baobao1270
        4
    baobao1270  
    OP
       2023-10-27 12:56:34 +08:00
    @gps949 CT 的话还是需要使用者主动核查……
    @tyzandhr 这个和 shadow tls 无关…… shadowtls 只是用了别人的 TLS Handshake ,而我说的是发生在证书获取层面的东西
    gps949
        5
    gps949  
       2023-10-27 12:56:56 +08:00
    这其实大概也就是为啥 EV 、OV 证书都收费甚至还很贵的原因了吧,一般 ACME 走互联网发 SSL 站点证书普遍还是 DV 类证书的操作,EV 、OV 的 CA 机构一般还是需要申请者单独提供认证材料和 CSR ,而不是走 ACME 挑战一下子就随随便便发了
    gps949
        6
    gps949  
       2023-10-27 12:57:57 +08:00
    @baobao1270 CT 核查的问题,也有提供服务的,比如 cloudflare 就可以订阅你拥有域名的 CT ,当发生证书签发时会给你推送邮件的
    cest
        7
    cest  
       2023-10-27 13:00:57 +08:00
    @gps949 #5
    机构自己卖证书也不是一天二天的事了
    经济越不好,就越多套现的
    gps949
        8
    gps949  
       2023-10-27 13:06:59 +08:00
    @cest 肯定有存在问题的,比如 CNNIC 和沃通,但一般还是靠谱的,否则主动为了挣眼前几万被 CAB 干然后失去每年千万级进账,真的是二傻子(没错,说的就前面那俩)。不过这恰恰也说明了,CA 管理严格比什么 ACME 挑战有漏洞可钻重要多了。
    tool2d
        9
    tool2d  
       2023-10-27 13:18:00 +08:00   ❤️ 2
    感觉这文章有问题,申请后的证书,是需要放到 web 服务器上来用才行。对方网站不用 ISP 的证书,申请一百个也没办法监听啊。

    而且最关键的密钥都不一样,只能自娱自乐。
    msg7086
        10
    msg7086  
       2023-10-27 13:33:41 +08:00
    @tool2d 回头 ISP 拦截掉所有的流量全部导去中间人就行了。ISP 出手搞的,怎么搞都行。
    msg7086
        11
    msg7086  
       2023-10-27 13:38:04 +08:00   ❤️ 1
    HTTP 验证伪造对 ISP 实在是太简单了。在第三方机子上申请证书,然后在交换机上把从 acme 验证服务器发来的 HTTP 包拦截下来返回 challenge 就行了,甚至连文章里说的这种物理拔线都不需要做。
    tool2d
        12
    tool2d  
       2023-10-27 13:44:26 +08:00
    @msg7086 "回头 ISP 拦截掉所有的流量全部导去中间人就行了。"

    这样做 ISP 风险很大的,还要专门弄一台流量卸载服务器伺候着,而客户的服务器相当于被完全架空。
    tyzandhr
        13
    tyzandhr  
       2023-10-27 13:46:10 +08:00 via Android
    @baobao1270 我理解的是 IP 与证书不一一对应,从而创造了可以伪造身份的机会
    lambdaq
        14
    lambdaq  
       2023-10-27 13:47:23 +08:00
    @tool2d 一般是这样操作的。你打开登录页面,走原始网站 tls 。页面加载完,流量跌 0 ,就立马断开 tcp 。

    下一步多半是提交用户名密码了,突然替换成李鬼的 tls 。这个时候也是合法的 tls 。。
    dudewei
        15
    dudewei  
       2023-10-27 13:53:20 +08:00
    E2E 的信仰又崩塌了。。。
    xmumiffy
        16
    xmumiffy  
       2023-10-27 14:17:03 +08:00 via Android
    这不算合法
    另外就算传统证书用 DNS 验证的,DNS 也有概率能被抢答
    yaoyao1128
        17
    yaoyao1128  
       2023-10-27 14:41:10 +08:00 via iPhone
    > 需要简单的修改 IP 路由
    说实话,这个并不简单()这个的前提是 托管服务提供者 做了这个而不是 平时使用的 isp 做了这个 也就是说,一般服务商不能“对特定用户”直接中间人

    而托管本质就是一个基于信任体系的问题……服务器本体还有 ip 都在那里,如果想要直接让它不能用也是可以的啊()

    这个和 dns 验证时候 dns 托管服务商能修改记录签发出来一个道理……
    idealhs
        18
    idealhs  
       2023-10-27 14:43:43 +08:00
    @tool2d #9 ISP 那边把路由导到自己的服务器上不就可以了吗
    devopsdogdog
        19
    devopsdogdog  
       2023-10-27 14:48:51 +08:00
    有点扯淡,都 isp 层面了 ,搞你还不是分分钟的事情。

    完整逻辑是,isp 拦截下来这个请求, 再去你的主机访问 .well-known/acme-challenge/xxxx ,获得 验证值, 自己再伪造个路由 过去。

    文章没怎么看明白,貌似还是猜测。 有懂的老哥科普一下
    tool2d
        20
    tool2d  
       2023-10-27 14:50:58 +08:00
    @idealhs ISP 偷偷抓一点流量还能理解。

    直接用自己的服务器替换客户服务器,这操作感觉就挺离谱的。
    expy
        21
    expy  
       2023-10-27 14:53:08 +08:00
    前几天好像发过,奇怪的是没人讨论,Hetzner 和 Linode 的机器还能用么。
    https://v2ex.com/t/984017
    Puteulanus
        22
    Puteulanus  
       2023-10-27 15:07:39 +08:00   ❤️ 1
    @tool2d ISP 对目标服务器反代就行了,就像公司行为管理的网关里面常用的,你访问 https 的网站看起来还是正常,看证书发现都是它的根证书自签的,网关以此获得一个完全监控你的传输明文,甚至篡改的能力

    这个事对 ISP 负担也没那么大,因为你访问的流量本身就要从他那过的,做点什么属于顺便的事,以前 http 没那么普及的时候网页插广告和购物网站跳返利都属于这种
    billlee
        23
    billlee  
       2023-10-27 15:54:10 +08:00
    Hetzner 和 Linode 的网络有租户隔离吗?这个攻击是 ISP 的行为还是同网络下其它租户的 ARP 攻击?
    xwh
        24
    xwh  
       2023-10-27 16:12:27 +08:00
    看完了没太理解,我理解的是 isp 只能以你的身份去通过 ca 的验证来获得一张证书,但是我没有看到 isp 如何拿到你自己申请的证书的私钥啊
    tool2d
        25
    tool2d  
       2023-10-27 16:18:30 +08:00
    @xwh 我也没看到 ISP 有偷到私钥,可能就是楼上同学说的,入口流量被完全替换了。

    你想玩原神官服,玩到 15 级,发现竟然进的是 ISP 架设的私服。
    cest
        26
    cest  
       2023-10-27 16:20:33 +08:00
    @gps949 #8
    老板几个小目标的流水跟实际的维运猴子有任何交集吗
    私卖的好处是自己的
    凡是有点脑细胞,都能做成是能力不足,手脑不协调的安全事故
    被火换个坑就行
    Reficul
        27
    Reficul  
       2023-10-27 16:26:37 +08:00
    要这么说的话,机房的老哥也能插优盘在机器上复制走证书私钥。
    ziseyinzi
        28
    ziseyinzi  
       2023-10-27 16:29:03 +08:00
    证书系统就是靠信任链维持的,可事实证明这个链条总有不可信的环节
    cest
        29
    cest  
       2023-10-27 16:30:30 +08:00
    @msg7086 #11
    这个会出事不就是因为攻击方脑瘫到搞了个 ifdown 让用户注意到
    攻击方可能没有 isp 全权限
    不然完全可以做到完全无法感知
    gps949
        30
    gps949  
       2023-10-27 16:31:51 +08:00
    @cest 你这说法就有点逗了。。。CA 发 SSL 证书可不是任何一个人单独点一下按钮搞定的事。。。除非老板不想为了小目标把整个 CA 建设合规了,让 CA 运营机制是个全是漏洞的筛子。但如果 CA 机构运营能力不够强的话,还想入根??
    leonshaw
        31
    leonshaw  
       2023-10-27 16:39:20 +08:00
    要这么说 DNS 提供商不是无敌了,cloudflare 默认就自动申请一个证书。不信任就不要用。
    cest
        32
    cest  
       2023-10-27 16:39:25 +08:00
    @gps949 #30
    ca 上了 browser 后被抓到证书外流而被撤掉的不是一个两个
    retanoj
        33
    retanoj  
       2023-10-27 17:22:32 +08:00   ❤️ 1
    @xwh
    我理解是,[你的 Linode] -> [恶意 ISP] -> [LE]
    恶意 ISP 伪造你的意图,自己生成公钥、私钥和 yourdomain.com 的 CSR ,并向 LE 申请 yourdomain.com 的证书。
    LE 向你的 yourdomain.com 进行 http-01 验证,因为验证请求流量会先过恶意 ISP 再到你的 Linode ,恶意 ISP 成功伪造了验证响应,从而拿到 yourdomain.com 证书。
    这样,以后互联网用户访问 yourdomain.com ,流量走到恶意 ISP ,恶意 ISP 可以作为 HTTPS 中间人卸载流量。
    xwh
        34
    xwh  
       2023-10-27 18:00:27 +08:00
    @retanoj #33 是的 也就是客户端一开始请求的证书就是 ca 机构签发给恶意 ISP 的,这样的话可以是合乎逻辑的,甚至给某家 ca 机构提供网络接入的 ISP 可以申请到所有使用这家 ca 机构对证书签名的网站,也不只 ISP 可以通过验证得到 ca 签发的证书了,所有的公有云厂商都可以
    bao3
        35
    bao3  
       2023-10-27 18:42:23 +08:00
    所以前几天的个人问“要不要在 https 的前提下,对传输密码进行加密”,结果一帮大聪明说完全不需要……那个帖子我连回复的兴趣都没有。
因为从的这个帖子已经是答案了。
    xmumiffy
        36
    xmumiffy  
       2023-10-27 18:52:38 +08:00 via Android
    @bao3 ISP 直接把自己毁了就为了偷你一个密码?
    yumusb
        37
    yumusb  
       2023-10-27 18:57:01 +08:00
    https://crt.sh/?q=xmpp.ru&dir=^&sort=2&group=none


    看起来是最新的这几个
    msg7086
        38
    msg7086  
       2023-10-27 19:00:10 +08:00
    @tool2d #12 只要拦截来自对应源 IP 的流量就行了。acme 验证流量来源是固定的。

    @cest #29 不太确定到底发生了什么,从日志来看像是有人物理拔线插到一台电脑上申请完了再插回去的。
    msg7086
        39
    msg7086  
       2023-10-27 19:07:16 +08:00
    @bao3 这种攻击规模已经上升到很高的层面了(大概率是某个或者多个国家的政府部门出场了)。可以走到机房里拔线,可以改路由对某个 IP 做流量绕行。到了这种规模级别你对传输密码加密已经没什么大用了,派点人上门把你服务器硬盘拔了带回去就好了。

    如果你确实是在和一些国家的谍报机关作斗争,那 HTTPS 已经远远不够了。至少也要像 USGOV 那样的防护水平才行,自建机房,政审员工,访问全部走 VPN+零信任堡垒,FIDO 加短效 SSH 证书签发,内部 PKI ,外网通信审计。
    baobao1270
        40
    baobao1270  
    OP
       2023-10-27 21:03:54 +08:00
    @gps949 嘛,我觉得这个还是需要配合和自己的 ACME Client 的日志进行比对。感觉有必要弄个自动化的工具自动核查。

    @xmumiffy 是的,但是我觉得 DNSSEC 可以一定程度上缓解这个问题。现在的 CA 做 DNS 验证应该都验证 DNSSEC 了吧。

    @yaoyao1128 其实从 「 CA 服务器 -> Web 服务器」 这条链路上的任何人都能做到这一点……更不用说还有 BGP 劫持这种大杀器

    @devopsdogdog @Puteulanus ISP 不需要去访问你的主机。他完全可以自己运行一个自己的 ACME Client ,然后把对应 IP 的流量导过去就行

    @billlee 这个看上去像是 ISP 行为(当然只是我的推测),但是理论上 IDC 和同租户做 ARP 攻击也能进行同样的攻击行为

    @leonshaw 是的,理论上不管是传统的 DNS 验证还是 ACME ,对于 DNS 提供商作恶都无能为力,我们只能选择信任 DNS 提供商

    @bao3 其实你看金融领域主流还是做加密的。可以去看看这篇文章: https://blog.huli.tw/2023/01/10/security-of-encrypt-or-hash-password-in-client-side/
    bao3
        41
    bao3  
       2023-10-27 21:08:41 +08:00
    @xmumiffy 这要看“你”是特定目标,还是群体目标。“你”是一个你,还是一群“你”
    mikewang
        42
    mikewang  
       2023-10-28 04:10:56 +08:00
    证书透明度,一定程度上让 ISP 不敢作为中间人去窃取证书。因为一旦 ISP 冒名顶替用户申请证书,那么这个记录就能被用户在 https://crt.sh/ 等网站查到,用户发现异常就可以申请吊销证书并且告它了。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   4958 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 31ms · UTC 01:11 · PVG 09:11 · LAX 17:11 · JFK 20:11
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.