珠江宽频的 DNS 劫持方案很棒啊

[perfectworks]

最近我们做的网站在珠江宽频地区被劫持严重，用户改 DNS 后可以解决
但比较奇怪的是我们是用了 HTTPS 的，不太清楚他们到底怎么劫持
请问有珠江宽频的用户可以提供下他们的 DNS 么，我们想测试下防劫持的方案

[perfectworks]

@V69EX 不会，确定过

[perfectworks]

@hiplon 你说的没错，但这样劫持会挂在 TLS 的证书验证上，就是页面变红出现不合法证书提示

[perfectworks]

@no1xsyzy 是，所以我在寻求珠江宽频的 DNS 服务器来验证 DNS 劫持的想法

[perfectworks]

@also24 虽然我们的 Nginx 没有禁止 80 端口的 HTTP，但我们确认下发的地址是 HTTPS 的，同时内容中也不包括任何 HTTP 请求（源码确认的，另外 HTTPS 页面包含 HTTP 请求会被浏览器挂掉的吧）。
HSTS 第一次知道，正在了解

[also24]

@perfectworks #24
另外 HTTPS 页面包含 HTTP 请求未必会被浏览器挂掉，可能只是不再显示安全标记。
HSTS 你可以理解为强制 HTTPS，常用 Chrome 的话，你可以注意到，某些网站证书出错的时候是不允许忽略的，就是因为启用了 HSTS，某种角度来说，这个其实也依赖于浏览器的具体实现。

由于你提供的关于劫持的信息有限，暂时无法给出更多的猜测。

[perfectworks]

@WingkitNg 感谢。但看起来在北京访问不了……

[perfectworks]

@also24 被劫持的是 iOS/Android 下的 WebView 。iOS 开启了 NSAllowsArbitraryLoads，所以感觉有可能是开了这个参数后会忽略证书不合法的报警？除了这个也想不到问题了，CNNIC 证书泄漏自签名的可能性实在是天方夜谭。

[also24]

@perfectworks #27
按道理来说 ATS 只是限制访问非 https 页面，禁用 ATS 应该不至于禁用掉证书校验。

能否补充说明一下劫持后的表现，是跳转去了其它站点，还是修改了你的站点的返回内容？

[perfectworks]

@also24 目前只有用户截图，所以看不太出来
现在是卡在了复现问题这一步，找用户确认结果的流程会比较长，所以先看看技术上有什么可行性再去验证
我感觉无论是跳转走，还是修改内容，在 HTTPS 下都应该不可能。甚至我觉着是有可能用户装了私有证书，但找用户确认过之后也不是这个问题

[also24]

@perfectworks #29
如果你支持了一些比较旧的加密算法，原理上来说是可能实施降级攻击的。

另一方面，自定义 Webview 的过程中，也要注意是否正确处理了 onReceivedSslError （ Android ） allowsAnyHTTPSCertificateForHost （ iOS ）之类的回调或配置。

[perfectworks]

@also24 禁止低版本加密算法这个，有什么解决方案么？是需要配置 WebView ？

[also24]

@perfectworks #31
是在服务端配置，不要支持 SSLv3 之类的危险版本算法，具体你可以搜索 『 https 降级攻击 』

[perfectworks]

@also24 thx，打开了新世界的大门

[Xusually]

@perfectworks 当你更新了 nginx 的配置，拒绝了降级请求（例如老旧的 SSLv3 ）之后，打开你的 nginx 日志，新的世界欢迎你，满屏不停的在刷类似这种：SSL routines:SSL23_GET_CLIENT_HELLO:unsupported protocol
互联网充满着恶意。

[perfectworks]

@also24 @Xusually 看了 cipher list，目前只有 tls1.0/1.1/1.2 。testssl 也跑了下，输出放在 https://gist.github.com/perfectworks/2926bec64ba040c3bad78e54a9e3e3da 了
不确定 TLS1/1.1 会不会是问题，能帮忙看看么

[also24]

@perfectworks #35
我不是专门搞安全方面的，所以不敢肯定，只能大致猜测。

看到 ssllabs.com 也针对 TLS1/1.1 站点调低了评级，猜测还是有问题存在。
大致翻找了一下，TLS1 是会受到 『 BEAST 攻击』的影响的，确实存在安全隐患。

但是我查看了一下这种攻击方式的条件，感觉并不适合用来做单纯的页面劫持，直觉上你遇到的问题应该不是这种类型的攻击。

[perfectworks]

@also24 我跟你的想法差不多。我看了下 www.apple.com 也是有 TLS1/1.1，所以直觉上认为这玩意应该没有特别简单的能大规模用来修改 HTTPS 应答的漏洞。

[iasuna]

DNSSEC 了解下

[yuzo555]

我遇到过，好几年前了，也是广州还是深圳那边的用户，当时没保存截图。
我让他 F12 看截图，确确实实看到我们的 https 的 JS 文件被劫持了，这个 JS 文件被替换为了他的脚本，然后他这个脚本里面，还加载了同一个文件 + ?_=随机参数，用来加载正确的 JS 内容。
当时看到也是啧啧称奇，发群里问别人都说 HTTPS 不可能劫持。

感觉是 CA 做了手脚，要么是客户端浏览器，要么是用了 360 旗下的 CA 比如沃通、StartCom 之类的签发的假证书（当时这事闹得挺大的）。

[yuzo555]

想起来了，最后发现是 CDN 回源时用的 http 回源，当地 CDN 节点回源时被劫持的。
不知道卤煮的网站是否用了 CDN 。