这是一个创建于 2026 天前的主题，其中的信息可能已经有所发展或是发生改变。
最近我们做的网站在珠江宽频地区被劫持严重，用户改 DNS 后可以解决
但比较奇怪的是我们是用了 HTTPS 的，不太清楚他们到底怎么劫持
请问有珠江宽频的用户可以提供下他们的 DNS 么，我们想测试下防劫持的方案
但比较奇怪的是我们是用了 HTTPS 的，不太清楚他们到底怎么劫持
请问有珠江宽频的用户可以提供下他们的 DNS 么，我们想测试下防劫持的方案
 | 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 之后没有相关反馈了 |
Select Language