How to capture HTTPS(TLS 1.0) communications from Android App with Fiddler4?

Question

I have enabled HTTPS in Fiddler4 options, and it does can capture HTTPS communications from most Android Apps on my machine(With Android simulator, via WIFI proxy settings).

But for some Apps it always failed. eg Kayak . It always says "Oops! There was a problem connecting to the internet. Please try again later." .

I notice Kayak App uses TLS 1.0(See following screenshot, it's from Microsoft Network Monitor 3.4), i think maybe this has something to do with it.

I also tried to set the protocols into "tls1.0"(See following screenshot), but has no effect.

Appreciate your ideas.

Answer 1

Update Further investigation revealed that some Android applications will not accept wildcards inside certificates' SubjectCN field if that field is encoded as BMPString . The makecert generator uses BMPString , so you can either untick the Use wildcards box or switch to the CertEnroll generator inside Tools > Fiddler Options > HTTPS > Certificates Generated By.

The text below is still applicable for apps which implement pinning.

---

TLS1.0 is perhaps the best-supported HTTPS protocol in Fiddler. You haven't shown what's in Fiddler's Web Sessions list or Log tab in the event of the failure, but my guess is that the Web Sessions list probably shows just a CONNECT and the Log tab has something like:

!SecureClientPipeDirect failed: System.IO.IOException Authentication failed because the remote party has closed the transport stream. for pipe (CN=*.kayak.com, O=DO_NOT_TRUST, OU=Created by http://www.fiddler2.com)

Is that correct? If so, the most likely explanation is that the Android app in question has enabled certificate pinning .

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.