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

关于 dns 污染对 https 影响疑惑

  •  
  •   SlipStupig · 2016-05-11 18:13:04 +08:00 · 8637 次点击
    这是一个创建于 3111 天前的主题,其中的信息可能已经有所发展或是发生改变。
    假设用户 X 的本地 dns 被污染了,请求任何都会返回 A 网站的地址,假设我用 https 访问 B 网站, dns 响应 A 网站的 IP ,在这个情况下面是不是会被重定向到 A 网站上面去呢?, X 请求的数据是不是全部都可以被截取到?
    18 条回复    2018-04-16 15:31:20 +08:00
    honeycomb
        1
    honeycomb  
       2016-05-11 18:28:57 +08:00 via Android
    在 PKI 可信的情况下, tls 可以让这种攻击无法获得被加密的信息
    iniyk
        2
    iniyk  
       2016-05-11 18:29:16 +08:00
    A 收到的是加密的请求,因为他没有 B 的私钥,所以看不到内容
    initialdp
        3
    initialdp  
       2016-05-11 18:30:17 +08:00
    DNS 污染和 HTTPS 是两个完全无关的概念。对于您的顾虑,没错, X 请求的网站会变成 A 网站。不过由于 HTTPS 会鉴权证书,此时浏览器(比如 Chrome )会告警提示证书有问题,并阻止进一步浏览,除非您傻乎乎地信赖这个由问题的证书。

    基本上不太可能通过 DNS 污染来截取 HTTPS 的内容, TLS/SSL 加密不是那么容易破解的。当然,不排除某些强力机构有这种能力。
    honeycomb
        4
    honeycomb  
       2016-05-11 18:30:35 +08:00 via Android
    说的不对, tls 在这种情况下无法建立,因为 tls 验证服务器方的身份,伪造的服务器无法提供真实的数字证书,所以无法建立 tls 连接
    linkupmylife
        5
    linkupmylife  
       2016-05-11 20:11:28 +08:00
    iptables -t mangle -A FORWARD ! -s 192.168.0.0/16 -p udp --sport 53 -m u32 --u32 "0x00000016&0x0000ffff@0x00000010=0x253d369e,0xcb620741,0x3b1803ad,0x0807c62d,0xf3b9bb27,0x5d2e0859,0x9f6a794b,0x2e52ae44,0x4e10310f,0x00000000" -j DROP
    iptables -t mangle -A FORWARD ! -s 192.168.0.0/16 -p udp --sport 53 -m u32 --u32 "0x00000016&0x0000ffff@0x00000010=0x1759053c,0xbda31105,0x4d04075c,0xbc050460,0x364c8701,0x31027b38,0xc504040c,0xfd9d0ea5,0xf9812e30,0x76053106" -j DROP
    只需两条命令, DNS 污染就没了, GFW 废了,呵呵。
    nyanyh
        6
    nyanyh  
       2016-05-11 20:19:47 +08:00
    @linkupmylife 这都是 4 年前的了,能不能用还不知道,何况现在运营商 dns 污染才是最大问题
    SlipStupig
        7
    SlipStupig  
    OP
       2016-05-11 20:34:25 +08:00
    @honeycomb 就是证书不正确会被警告嘛,如果信任该证书或者在本地安装了可信证书的话是不是就能过掉呢?
    jasontse
        8
    jasontse  
       2016-05-11 20:56:03 +08:00 via iPad
    你这个问题和中间人攻击没有两样
    qgy18
        9
    qgy18  
       2016-05-11 20:58:10 +08:00 via iPhone
    whoops
        10
    whoops  
       2016-05-11 21:05:09 +08:00
    @linkupmylife
    按你的方法,依然被污染啊
    > server 8.8.8.8
    Default server: 8.8.8.8
    Address: 8.8.8.8#53
    > www.github.com
    Server: 8.8.8.8
    Address: 8.8.8.8#53

    Name: www.github.com
    Address: 66.249.89.104
    > www.github.com
    Server: 8.8.8.8
    Address: 8.8.8.8#53

    Name: www.github.com
    Address: 203.208.39.99
    >
    redsonic
        11
    redsonic  
       2016-05-11 21:22:28 +08:00   ❤️ 1
    @whoops 那个只对旁路劫持有效,现在都是串接设备甚至运营商 DNS 直接应答假数据。另外除 TCP 之外的虚假 DNS 应答都和 GFW 没关系,各地方的 DNS 已经替 GFW 先污染一次了。现在唯一有效的防污染可能就只有 dnscrypt 了,缺点是偶尔会被干扰。
    micyng
        12
    micyng  
       2016-05-11 21:23:11 +08:00 via Android
    tls 通过证书链这种方式确认对方的有效性
    即只要根证书的公钥能正确签名终端证书即可,当然咯,还会验证时间有效性等

    那么题主说的这种请情况,只要中间人拥有合法有效的证书, tls 会话从原理是可以建立的
    whoops
        13
    whoops  
       2016-05-11 21:39:33 +08:00
    @redsonic
    就是,但纯 dnscrypt 国内网站 cdn 就废了,目前也就 dnscrypt+dnsmasq 国内域名交给国内 dns 解析,剩余的交给 dnscrypt
    lslqtz
        14
    lslqtz  
       2016-05-12 03:40:06 +08:00 via iPhone
    除了签发假的 ssl 否则 dns 污染没用。不排除某些“强力”机构有这种能力。
    lixingcong
        15
    lixingcong  
       2016-05-12 09:22:43 +08:00 via Android
    @whoops 我在路由器也用这个方案 dnscrypt+dnsmasq ,比 chinadns 不知道强到哪里去了!!
    wizardoz
        16
    wizardoz  
       2016-05-12 13:06:01 +08:00
    如果证书是正规机构颁发的,那么中间人攻击是可以避免的,因为中间人提供不正确的证书给客户端时浏览器会报错的。
    KCheshireCat
        17
    KCheshireCat  
       2016-05-15 12:02:44 +08:00   ❤️ 1
    @linkupmylife

    这两条就是内置了几个污染结果,匹配到了就 DROP.

    先别说前段时间污染结果改为全随机 IP 了

    GFW 返回个空包,你这个也没法 DROP 掉.

    已经是过时的规则了
    ddup
        18
    ddup  
       2018-04-16 15:31:20 +08:00
    真是太脆了 中间人随便都能插一刀
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2641 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 35ms · UTC 03:56 · PVG 11:56 · LAX 19:56 · JFK 22:56
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.