虽然我同意@mdeora,但我试图用简单的术语解释(很长的路)幕后发生的事情,并希望它会有所帮助。
让我们先定义几个术语
客户端(“C”):使用 SSL/TLS 库的移动应用程序。此外,客户端可以配置为识别由内部认证机构 (CA) 签署的证书。
服务器(“S”):为请求提供服务的目标服务器
代理(“P”)或透明代理(“TP”):通过代表“S”发送证书,但由代理服务器创建的内部 CA 证书。例如 Burp Suite、Squid
DNS 服务器:将名称解析为 IP 地址的服务
客户端 DNS 服务器:在移动设备上配置的一个或多个 DNS 服务器 IP 地址,或者由于显式配置,或者在移动设备连接到网络(电信或 Wifi)时由网络连接提供
代理 DNS 服务器:在配置代理服务的同一台机器上配置的 DNS 服务器的一个或多个 IP 地址
案例 A. 当客户端和服务器之间既没有代理也没有透明代理时
- “C”通过查询客户端 DNS 服务器找到“S”的 IP 地址(例如“IP-S”)。
- "C" 使用 SSL/TLS 连接到 "IP-S" 并完成通信。整个通信都是加密的。
在这种情况下,Burp Suite / Wireshark 看不到纯文本流量。
案例 B. 当移动设备配置为使用代理服务器“P”时
- “C”通过查询客户端 DNS 服务器找到“P”的 IP 地址,例如“IP-P”。
- “C”通过 HTTP 或 HTTPS 协议连接到“IP-P”。
- 如果“C”通过HTTP协议连接到“P”,“P”拦截请求,检查URL,并获得一个域名。
- 如果“C”通过 HTTPS 协议连接到“P”,“P”将通过 SNI 将目标服务器名称理解为 SSL/TLS 握手的一部分——SSL/TLS 的扩展。(https://en.wikipedia.org/wiki/Server_Name_Indication)
- “P”将使用代理 DNS 服务器来获取“S”的 IP(例如“IP-S”)。“P”将连接到“IP-S”。
- 在正常情况下,“P”(或“TP”)会将请求从“C”逐字节转发到“S”,并将响应从“S”转发到“C”。“C”总是会得到一个真正的“S”证书,而“P”/“TP”除了“C”正在与“S”通信这一事实之外,什么都不知道。
- 但是,在拦截器(例如 BurpSuite)的情况下,“P”(或“TP”)将呈现由内部 CA 签名的证书,冒充“S”。如果“C”配置为识别由内部 CA 签名的证书,“C”中的 SSL 库将被迫假设它确实在与“S”对话。
如果没有 SSL pinning,“C”将与“P”(或“TP”)交互,就好像它是“S”一样。“P”将解密流量,并与“S”建立连接,重新加密流量并将其发送给“S”。同样,“P”将收到“S”的响应,并将其发送回“C”。“C”和“S”都不会意识到“P”已经拦截(并且可能已经改变了)流量。
使用 SSL pinning(https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Pinning_Cheat_Sheet.md),如果发现“P”/“TP”提供的证书不匹配,“C”将不会继续真正的“S”证书。
案例 C. 当移动设备使用存在透明代理 (“TP”) 的网络时
在这里,“C”尝试连接到“S”,就像案例 A 中一样,但是网络中的“TP”就像“P”一样拦截流量,其余的则按照案例 B(4) 继续。
总而言之,当您使用 SSL Pinning 时,只有当“C”认为它通过安全通道与真正的“S”而不是代理进行通信时,它才会与“S”通信。