Fiddler无法抓取某些APP的HTTPS请求,无解!!!
遇到有些APP的HTTPS请求无法抓取!错误提示: !SecureClientPipeDirect failed: System.Security.Authentication.AuthenticationException A call to SSPI failed, see inner exception. < An unknown error occurred while processing the certificate for pipe (CN=*.umeng.com, O=DO_NOT_TRUST, OU=Created by http://www.fiddler2.com).
google了下,貌似有些APP的证书不能随便构造,
这个回答提到了一种叫Certificate Pinning(证书锁定)的机制 https://stackoverflow.com/questions/33382870/how-to-capture-httpstls-1-0-communications-from-android-app-with-fiddler4
官方说:
From the Fiddler book:
Certificate Pinning
A very small number of HTTPS client applications support a feature known as “Certificate Pinning” whereby the client application is hardcoded to accept only one specific certificate. Even if the connection uses a certificate that chains to a root that is otherwise fully-trusted by the operating system, such applications will refuse to accept an unexpected certificate.
To date, some Twitter and Dropbox apps include this feature, and Windows 8 Metro apps may opt-in to requiring specific certificates rather than relying upon the system’s Trusted Root store. Firefox’s automatic browser update feature will silently fail when Fiddler is decrypting its traffic. The Microsoft Security toolkit named EMET can enable pinning in any application for certain “high-value” sites (including Windows Live). The Chrome browser supports pinning, but it exempts locally-trusted roots like Fiddler’s.
When a Certificate-Pinned application performs a HTTPS handshake through a CONNECT tunnel to Fiddler, it will examine the response’s certificate and refuse to send any further requests when it discovers the Fiddler-generated certificate. Unfortunately, there is no general-purpose workaround to resolve this; the best you can do is to exempt that application’s traffic from decryption using the HTTPS tab or by setting the x-no-decrypt Session flag on the CONNECT tunnel. The flag will prevent Fiddler from decrypting the traffic in the tunnel and it will flow through Fiddler uninterrupted.
A very small number of HTTPS client applications support a feature known as “Certificate Pinning” whereby the client application is hardcoded to accept only one specific certificate. Even if the connection uses a certificate that chains to a root that is otherwise fully-trusted by the operating system, such applications will refuse to accept an unexpected certificate. To date, some Twitter and Dropbox apps include this feature, and Windows 8 Metro apps may opt-in to requiring specific certificates rather than relying upon the system’s Trusted Root store. Firefox’s automatic browser update feature will silently fail when Fiddler is decrypting its traffic. The Microsoft Security toolkit named EMET can enable pinning in any application for certain “high-value” sites (including Windows Live). The Chrome browser supports pinning, but it exempts locally-trusted roots like Fiddler’s. When a Certificate-Pinned application performs a HTTPS handshake through a CONNECT tunnel to Fiddler, it will examine the response’s certificate and refuse to send any further requests when it discovers the Fiddler-generated certificate.
Unfortunately, there is no general-purpose workaround to resolve this; the best you can do is to exempt that application’s traffic from decryption using the HTTPS tab or by setting the x-no-decrypt Session flag on the CONNECT tunnel. The flag will prevent Fiddler from decrypting the traffic in the tunnel and it will flow through Fiddler uninterrupted.
If you're very serious about circumventing pinning, you can jailbreak the device and use any of a number of 3rd party toolkits to disable the pinning code.
机器翻译:
少数HTTPS客户端应用程序支持一种称为“证书固定”的特性,通过这种特性,客户端应用程序被硬编码为只接受一个特定的证书。即使连接使用证书链接到操作系统完全信任的根,此类应用程序也将拒绝接受意外的证书。
到目前为止,一些Twitter和Dropbox的应用程序都有这个功能,Windows 8 Metro应用程序可能会选择要求特定的证书,而不是依赖于系统的可信根存储。当Fiddler解密其通信流时,Firefox的自动浏览器更新功能将会悄无声息地失败。名为EMET的Microsoft安全工具包可以在任何应用程序中为某些“高价值”站点(包括Windows Live)启用固定。Chrome浏览器支持“钉住”,但它免除了像Fiddler这样的本地可信根。
当证书固定的应用程序通过连接隧道到Fiddler执行HTTPS握手时,它将检查响应的证书,并在发现Fiddler生成的证书时拒绝发送任何进一步的请求。不幸的是,没有通用的解决方案;您所能做的最好的事情就是使用HTTPS选项卡或通过在CONNECT通道上设置x-no-decrypt会话标志来免除应用程序的通信流的解密。旗子将阻止Fiddler解密隧道中的交通,它将不受干扰地通过Fiddler。
少数HTTPS客户端应用程序支持一种称为“证书固定”的特性,通过这种特性,客户端应用程序被硬编码为只接受一个特定的证书。即使连接使用证书链接到操作系统完全信任的根,此类应用程序也将拒绝接受意外的证书。到目前为止,一些Twitter和Dropbox的应用程序都有这个功能,Windows 8 Metro应用程序可能会选择要求特定的证书,而不是依赖于系统的可信根存储。当Fiddler解密其通信流时,Firefox的自动浏览器更新功能将会悄无声息地失败。名为EMET的Microsoft安全工具包可以在任何应用程序中为某些“高价值”站点(包括Windows Live)启用固定。Chrome浏览器支持“钉住”,但它免除了像Fiddler这样的本地可信根。当证书固定的应用程序通过连接隧道到Fiddler执行HTTPS握手时,它将检查响应的证书,并在发现Fiddler生成的证书时拒绝发送任何进一步的请求。
不幸的是,没有通用的解决方案;您所能做的最好的事情就是使用HTTPS选项卡或通过在CONNECT通道上设置x-no-decrypt会话标志来免除应用程序的通信流的解密。旗子将阻止Fiddler解密隧道中的交通,它将不受干扰地通过Fiddler。
如果你非常认真地想要绕过钉住,你可以越狱设备并使用第三方工具包中的任何一个来禁用钉住代码。
大概意思就是Fiddler对这种APP的证书认证机制无能为力,只能望洋兴叹!呜呼哀哉!
有能解决这个问题的朋友麻烦留言下!!谢谢!