HTTPS 中间人攻击 (下): 离职倾向分析是怎么实现的

强烈建议先阅读上篇文章补充上下文。

上篇我们讲到了常规审计功能,员工访问招聘网站多少次,访问多久时间,这些只需要知道访问域名(DNS 明文、SNI 明文泄露)+ TCP 连接时间就能做到,不需要对 HTTP 内容解析。那么在不借助代理,纯靠端到端加密能否能解决这个问题?

DNS 安全性

DNS 协议在设计之初并没有考虑到安全性问题,整个DNS协议在互联网上都是没有任何校验的明文传输的。 这意味着任何中间人都能直接篡改或抢答它的返回值。

DNS over HTTPS : 隐藏 DNS 查询动作,解决抢答和加密传输

DoH 可以简单理解为使用一个普通的 HTTPS 请求来解析 DNS ,执行下面命令体验

js 复制代码
curl --http2 -H "accept: application/dns-json" "https://1.1.1.1/dns-query?name=cloudflare.com"

上篇可知 HTTPS 的端到端加密可以信赖, 则 DoH 只是一次普通的 HTTPS 请求,隐藏了常规的 DNS 操作 + 隐藏了查询的目标域名 + 避免了返回值被替换。 可知 DoH 是一种解决手段,可以堵上 DNS 查询暴露请求目标域名的漏洞。需要在客户端 ,如 Win10 系统或 Chrome 配置开启,了解更多

提示一下如不了解,不建议直接开启这个功能,因为 DNS 和 CDN 网络链路优化强关联,了解更多,DoH 的最佳实践比较复杂,往往还是需要借助代理,但在代理的场景下其实有兼容性更好的 DNS 处理方式,比如 fake-ip。

DNSSEC:解决改写问题,层级 DNS 携带公钥、签名记录

与 DoH 同级,相比 DNS over HTTPS, DNSSEC 并没有加密 DNS 查询过程,了解它的意义在于:

  • 主要是服务端配置,客户端无需额外的配置,和 DoH 不同
  • 象征了 DNS 功能的升级。DNS 记录除了常规的 A、AAAA、CNAME 等记录,也有专属记录如 DNSKEY(公钥),DS(DNSKEY 的 hash 摘要),RRSIG(数字签名)这种记录来实现类似上篇 CA 证书链认证 的过程, 了解更多 DNS 记录类型

以一个配置在 CloudFlare 的域名配置 DNSSEC 为例验证上述记录:

图片右键新窗口打开可清晰查看

参考 DNSSEC 实战

个人域名 test.cc 的 DNS 解析过程 root . => .cc => test.cc 都存在 DNSKEY (公钥)记录,并有 RRSIG (签名)顺序验签,和上文 CA 证书链类似,只是这里信任链起点根证书是 DNS 根服务器(非本地),全球单点,所以它的签发比较复杂,了解 DNSSEC 根签名仪式。

第二层:审计访问目标站点,进行阻断监听或特征行为捕捉

上文的 DoH 功能需要客户端手动开启,比如在Chrome 里是 "使用安全 DNS"。

DNS 是链路安全上比较大的隐患,反方向来说它也是网络审计系统的重要依赖 ,所以公司电脑如果配置了浏览器管控,则会禁用 安全 DNS 功能 ,可以打开公司电脑看看。

虽然 SNI 也会明文暴露访问域名,但如上篇提到 TLS 握手最后会发 Session ticket ,往往一天左右才过期:

没过期时客户端可以直接用 Ticket 恢复 TLS 会话,之前交换的 session key 中间人不知道,所以sessionId 明文没关系。但在这种情况下就不能精细化审计,比如图片里连接网站的次数:

TLS 恢复会话时中间人不知道访问的网站,所以根据 DNS 查询能更好判断访问次数。当然如果知道 IP ,通过 TCP 连接次数也能知道,只是 IP 会变,不如 DNS 查询准确。由此审计功能的能力边界也极其依赖对设备的直接限制,所以只常见于企业使用。

应对方式:没什么好办法,被企业管理的设备往往无法修改关键设置,很多时候息屏时间都无法修改,并且即使端到端安全了,系统内仍然可能靠端内的应用来监听工作时长,截屏的软件来实施监控。能做的只有尽量不用这种设备以及连接办公网络。

但一定想在这样的设备做自己的事也是有办法的,见 VS Code 打造个人超级工作站,我们已知常规端到端加密至少内容加密是可靠的,那打开 VScode 远程连接一个机器(端),在那个端做自己想做的事就行了。这实际上是一种代理,真实的网络请求都在另一个端上完成。

TLS 安全性

TLS 随版本迭代才不断完善,因而 TLS 降级是常见的中间人攻击手段。

什么是 SNI

上篇文章提到过,TLS 握手第一步 Client hello 为明文,包括支持 TLS 的版本(中间人篡改后就是降级攻击),SNI Extension 直接暴露了 server_name , 因为一个 IP 可以部署多个服务域名,需要告知以返回正确的 CA 证书。

这里还有一种例外情况,如果一个 IP 只部署了一个域名就不用传 SNI 字段,所以 DNS 污染对中间人仍然必要。

ESNI / ECH :堵死 server_name 暴露的最后方式

how encrypted SNI works

ESNI = encrypted SNI , ECH = encrypted Client Hello ,都是加密 Client Hello ,减少明文信息。

TLS 1.3 对 CA 传输加密

值得一提的是 CA 明文暴露给中间人也是不安全的,因为 CA 往往也对应一个明确的域名,所以 TLS 1.3 是加密传输 CA 的, ESNI 也需要 TLS 1.3 ,不然加密了 SNI 但没加密 CA 就是掩耳盗铃了。

上篇介绍的 TLS 握手过程实际是 TLS 1.2 版本 的,步骤在客户端 CA 验签完成后,确认服务端公钥未被替换后,非对称加密传输 Premaster key,两端此时同有 Client random + Server random + Premaster key => 生成 session key 。

这是因为除了 Diffe-Hellman ( DH )算法外还支持多种密钥交换算法。实际上 DH 算法不需要非对称加密 ,也能成功保密交换密钥, 了解更多。 TLS 1.3 禁用了 TLS 版本降级,并且固定了密钥交换算法只能是 DH 算法。所以两端通过 DH 算法 key share 后直接开始进行对称加密,从而将 CA 的传输过程也进行了加密。

Client hello 如何加密

在 TLS 握手第一步,服务端还未向客户端发送任何信息,此时加密公钥哪来?TLS 握手前唯一发生的事是 DNS 查询,所以是从 DNS 里查公钥。可以查看上文 DNSSEC 部分,通过 DNS 记录传递公钥,也是 ESNI/ECH 的必要依赖,更多细节可查看下面文档。

how encrypted SNI works

how ECH works

真正的端到端加密

上面的 DoH 和 ECH 的共同点在于对客户端服务端都有要求,兼容性较差,实际上代理服务器有更好更简单的处理方式:使用中转来 DNS 查询,且这个中转服务器隐藏了请求对象真实域名,还顺带解决了 IP 黑名单。但代理说到底是一个新的端,如果一定要引入新的端来解决,无法分析端到端加密的可靠性。

完全无代理的方式更能体现端到端加密的发展阶段,所以这里结合上文已经了解的点,总结下业界前沿的端到端加密如何解决中间人攻击切入点:

  • DNS 明文:DoH ,DNSSEC 等方式加密
  • IP 黑名单: IPv6 可有条件解决,关于 IPv6 可以自行了解
  • SNI 明文:ESNI、ECH, 随着 TLS 版本提升,明文信息越来越少

以上方式全上齐,中间人无法获取任何有用信息(访问域名),无法做任何审计了。做到这一层,起码任何网关类型的监控,比如离职倾向分析这种业务当然无法实施了,中间人面对的只有茫茫多的加密数据包。可以说,做到了真正的端到端加密

第三层:深度包检测,根据流量特征阻断

到了这一层,则终于引入中间人攻击发展阶段的最前沿 :中间人面对两眼一抹黑的数据包,能做什么有意义的操作?没错,只有无条件阻断。准确来说是根据加密数据包的统计学特征 ,结合机器学习等算力投入来只执行阻断这一项工作。

在这种情况下,中间人不知道你访问了哪个网站,只知道从茫茫多的数据包中找到那些个有 ESNI/ECH 特征的数据包,并直接丢弃,相当于封禁了 TLS 1.3 的这个功能。

这也刚好反证了端到端加密的有效性:如果有任何可利用的漏洞暴露有效信息,中间人不会采取这种需要堆算力的审计方式,相当于单点对抗全网流量。

解决方式:手动混淆流量特征,比如每个包加入随机长度的字符串。实践上,DoH,ECH 都还用不上的情况下,实际上端到端加密的和中间人的博弈只发生在 客户端 连接到 代理服务器 的这个过程里。

总结

最后结合上下文,对中间人攻击按能力排序进行总结,并给出简单应对方式。

第一层:中间人手动安装 Root CA,并基于直接替换目标域名的 CA,完全解析 HTTP 内容,为所欲为,但一般只见于开发场景,且容易发现。手机装的 Root CA 往往真的只用于认证 WIFI,没有监听功能。

解决:注意当前网站 CA 是否被替换即可,并不用担心应用程序(如 WX)被完全监听。

第二层:中间人基于 TLS 低版本的各种漏洞,获取连接的各种元信息来审计,能力局限于访问目标,连接时间。一些企业设备支持审计少数应用特征行为(上传、登录),但能力强依赖对用户设备的限制(禁用安全DNS,禁用部分应用)

解决:一般不能修改被管理的设备,所以尽量避免使用公司网络和设备。实在要用设备,可以通过 VS Code remote dev 这种加密连接到新的端来保证安全。

第三层:中间人同时采取 DNS 污染和 SNI 漏洞等上述全部方式,在都不生效,任何连接的真实内容都被成功加密时,中间人完全根据加密流量报文的统计学特征来阻断。

解决:对中间人加密全部的有用信息(包括隐藏目标 IP,防止 DNS 污染,隐藏 server_name) 的同时,抹平混淆数据包流量特征 ,它象征着中间人攻防技术螺旋上升的最前沿,如果有兴趣可以参考这篇文章。

写文章本身也是一个学习的过程,也请读者能指出文章中的疏忽错漏之处。如果本文对你有所帮助,欢迎点赞收藏。

相关推荐
nnloveswc1 小时前
PTE-中间件安全
安全
冰水°1 小时前
3.1_文件上传漏洞
安全·网络安全·文件上传·条件竞争·.htaccess·文件上传绕过
ZJ_.2 小时前
Electron 沙盒模式与预加载脚本:保障桌面应用安全的关键机制
开发语言·前端·javascript·vue.js·安全·electron·node.js
星海幻影3 小时前
网络基础-超文本协议与内外网划分(超长版)
服务器·网络·安全
湖南罗泽南3 小时前
p2p网络介绍
网络·网络协议·p2p
有梦想的咕噜3 小时前
Secure Shell(SSH) 是一种网络协议
运维·网络协议·ssh
烬奇小云3 小时前
认识一下Unicorn
android·python·安全·系统安全
Sweet_vinegar5 小时前
Wireshark
网络·测试工具·安全·wireshark·ctf·buuctf
23zhgjx-NanKon7 小时前
华为eNSP:RSTP
网络·安全·网络安全·华为
javachen__11 小时前
从美国大选,看软件安全风险与挑战
网络·安全·web安全