1
hiplon 2020-03-30 12:13:27 +08:00 1
dns 劫持和 https 有什么关系
|
2
titanium98118 2020-03-30 13:16:57 +08:00
dns 劫持和 https 有什么关系
|
3
keyfunc 2020-03-30 13:23:54 +08:00
dns 劫持和 https 有什么关系
|
4
V69EX 2020-03-30 13:27:03 +08:00
全站所有引用资源也 https 化了么?没有的话,还是有可能被劫持的……
|
5
est 2020-03-30 13:41:52 +08:00
dns 劫持和 https 有什么关系
|
6
perfectworks OP @V69EX 做了,但还被劫持了
|
7
perfectworks OP @est https 做了,出现 dns 劫持应该会看到个不合法的证书页吧
|
8
V69EX 2020-03-30 13:47:46 +08:00
@perfectworks 你确信页面里没有引用第三方的广告或统计类资源?那些资源或许是 https,但它们仍有可能再引用 http 的资源。
|
9
also24 2020-03-30 13:48:52 +08:00 via Android
楼主是否方便把劫持前的网址,和劫持后的页面内容截图发一下?
|
10
est 2020-03-30 13:51:11 +08:00
@perfectworks 或许用户先访问你们 80 端口然后跳转到 https 呢?
|
11
hiplon 2020-03-30 13:56:58 +08:00
怕带错,我回一下吧,你就算做了 https,全站 https 也好,用户访问你的你的网站首先做的是 dns 请求,dns 劫持就是对这个 dns 请求返回错误的 IP,那么 IP 都是错的,就和你的服务器站点做不做 https 无关系,因为用户访问的 IP 地址就不是你的站的。所以要弄清整个访问的流程。
|
12
doveyoung 2020-03-30 14:59:04 +08:00
dns 劫持和 https 有什么关系
已经,成为复读机了,回不去了……( dog |
13
WingkitNg 2020-03-30 15:01:44 +08:00
116.199.0.200
116.116.116.116 210.21.4.130 |
14
also24 2020-03-30 15:03:16 +08:00
@hiplon #11
你这个理解是错误的,如果楼主的站点做了全站 https 和 HSTS,那么用户如果访问到了其它 IP,由于 https 证书不符,浏览器是会弹出警告提示中止访问的。 但是如果楼主的站点存在非 https 的资源,那还是有可能遇到劫持的情况,或者没有开启 HSTS,也有可能遇到降级攻击,所以我觉得楼主最好发一下具体的网址,这样可以具体排查。 |
15
hiplon 2020-03-30 15:20:08 +08:00 via Android 1
@also24 我明白你的意思,但是我说的过程没错,造成 hsts 报错和证书中止的本质就是因为服务器证书不符,证书不符的原因就是劫持的 ip 上面没有真正的证书。我说的是 dns 劫持与 https 没关系
|
16
also24 2020-03-30 15:24:08 +08:00
@hiplon #15
可能是楼主描述的过于简略导致出现了理解偏差。 楼主所说的 『 DNS 劫持』其实不止在说劫持这个技术手段,也代指了劫持的后果(跳转至其它网站,页面内插入广告等),楼主在 7 楼也补充了他的想法。 『 DNS 劫持』这个词确实经常被这样使用,可能你之前没有遇到过这样省略描述的就产生了误解。 |
17
no1xsyzy 2020-03-30 15:28:42 +08:00
先怀疑下是否真的是 DNS 劫持吧。
哪个 DNS 服务器,在解析何网站时被劫持了? Network 标签页看数据包? |
20
perfectworks OP @est 不会,因为 URL 是 server 下发的
|
21
perfectworks OP @V69EX 不会,确定过
|
22
perfectworks OP @hiplon 你说的没错,但这样劫持会挂在 TLS 的证书验证上,就是页面变红出现不合法证书提示
|
23
perfectworks OP @no1xsyzy 是,所以我在寻求珠江宽频的 DNS 服务器来验证 DNS 劫持的想法
|
24
perfectworks OP @also24 虽然我们的 Nginx 没有禁止 80 端口的 HTTP,但我们确认下发的地址是 HTTPS 的,同时内容中也不包括任何 HTTP 请求(源码确认的,另外 HTTPS 页面包含 HTTP 请求会被浏览器挂掉的吧)。
HSTS 第一次知道,正在了解 |
25
also24 2020-03-30 22:58:33 +08:00
@perfectworks #24
另外 HTTPS 页面包含 HTTP 请求未必会被浏览器挂掉,可能只是不再显示安全标记。 HSTS 你可以理解为强制 HTTPS,常用 Chrome 的话,你可以注意到,某些网站证书出错的时候是不允许忽略的,就是因为启用了 HSTS,某种角度来说,这个其实也依赖于浏览器的具体实现。 由于你提供的关于劫持的信息有限,暂时无法给出更多的猜测。 |
26
perfectworks OP @WingkitNg 感谢。但看起来在北京访问不了……
|
27
perfectworks OP @also24 被劫持的是 iOS/Android 下的 WebView 。iOS 开启了 NSAllowsArbitraryLoads,所以感觉有可能是开了这个参数后会忽略证书不合法的报警?除了这个也想不到问题了,CNNIC 证书泄漏自签名的可能性实在是天方夜谭。
|
28
also24 2020-03-30 23:05:49 +08:00
@perfectworks #27
按道理来说 ATS 只是限制访问非 https 页面,禁用 ATS 应该不至于禁用掉证书校验。 能否补充说明一下劫持后的表现,是跳转去了其它站点,还是修改了你的站点的返回内容? |
29
perfectworks OP @also24 目前只有用户截图,所以看不太出来
现在是卡在了复现问题这一步,找用户确认结果的流程会比较长,所以先看看技术上有什么可行性再去验证 我感觉无论是跳转走,还是修改内容,在 HTTPS 下都应该不可能。甚至我觉着是有可能用户装了私有证书,但找用户确认过之后也不是这个问题 |
30
also24 2020-03-30 23:19:16 +08:00
@perfectworks #29
如果你支持了一些比较旧的加密算法,原理上来说是可能实施降级攻击的。 另一方面,自定义 Webview 的过程中,也要注意是否正确处理了 onReceivedSslError ( Android ) allowsAnyHTTPSCertificateForHost ( iOS )之类的回调或配置。 |
31
perfectworks OP @also24 禁止低版本加密算法这个,有什么解决方案么?是需要配置 WebView ?
|
32
also24 2020-03-30 23:31:26 +08:00
@perfectworks #31
是在服务端配置,不要支持 SSLv3 之类的危险版本算法,具体你可以搜索 『 https 降级攻击 』 |
33
perfectworks OP @also24 thx,打开了新世界的大门
|
34
Xusually 2020-03-30 23:46:58 +08:00
@perfectworks 当你更新了 nginx 的配置,拒绝了降级请求(例如老旧的 SSLv3 )之后,打开你的 nginx 日志,新的世界欢迎你,满屏不停的在刷类似这种:SSL routines:SSL23_GET_CLIENT_HELLO:unsupported protocol
互联网充满着恶意。 |
35
perfectworks OP @also24 @Xusually 看了 cipher list,目前只有 tls1.0/1.1/1.2 。testssl 也跑了下,输出放在 https://gist.github.com/perfectworks/2926bec64ba040c3bad78e54a9e3e3da 了
不确定 TLS1/1.1 会不会是问题,能帮忙看看么 |
36
also24 2020-03-31 00:12:11 +08:00
@perfectworks #35
我不是专门搞安全方面的,所以不敢肯定,只能大致猜测。 看到 ssllabs.com 也针对 TLS1/1.1 站点调低了评级,猜测还是有问题存在。 大致翻找了一下,TLS1 是会受到 『 BEAST 攻击』的影响的,确实存在安全隐患。 但是我查看了一下这种攻击方式的条件,感觉并不适合用来做单纯的页面劫持,直觉上你遇到的问题应该不是这种类型的攻击。 |
37
perfectworks OP @also24 我跟你的想法差不多。我看了下 www.apple.com 也是有 TLS1/1.1,所以直觉上认为这玩意应该没有特别简单的能大规模用来修改 HTTPS 应答的漏洞。
|
38
iasuna 2020-03-31 02:10:30 +08:00 via iPhone 1
DNSSEC 了解下
|
39
yuzo555 2020-03-31 03:42:33 +08:00
我遇到过,好几年前了,也是广州还是深圳那边的用户,当时没保存截图。
我让他 F12 看截图,确确实实看到我们的 https 的 JS 文件被劫持了,这个 JS 文件被替换为了他的脚本,然后他这个脚本里面,还加载了同一个文件 + ?_=随机参数,用来加载正确的 JS 内容。 当时看到也是啧啧称奇,发群里问别人都说 HTTPS 不可能劫持。 感觉是 CA 做了手脚,要么是客户端浏览器,要么是用了 360 旗下的 CA 比如沃通、StartCom 之类的签发的假证书(当时这事闹得挺大的)。 |
40
yuzo555 2020-03-31 03:45:38 +08:00
想起来了,最后发现是 CDN 回源时用的 http 回源,当地 CDN 节点回源时被劫持的。
不知道卤煮的网站是否用了 CDN 。 |
41
perfectworks OP @yuzo555 这个思路不错👍
|
42
Xusually 2020-03-31 10:06:22 +08:00
@perfectworks 你这个配置还可以,应该不是直接的降级攻击了。那么检查静态资源 CDN 吧。#38 的问题我们也遇到过。
|
43
perfectworks OP |
44
songofsaya 2020-04-01 20:03:36 +08:00
太烦了,强行劫持 DNS,我都不知道怎么处理= =....
|
45
farmer01 2020-04-02 21:50:33 +08:00
dns 劫持和 https 有什么关系
|
46
perfectworks OP update,dns 回源协议改成 https 之后没有相关反馈了
|