Hi, I'm trying to capture https traffic from instagram android app. Trusted certificate was installed, and I can see traffic from http (from instagram app) but not https (but I can see https traffic from some sites link google.com when I use android browser).
I am using windows 8x64 and Fiddler4. In Fiddler https requests appears as follows:
A SSLv3-compatible ClientHello handshake was found. Fiddler extracted the parameters below.
Version: 3.1 (TLS/1.0)
Random: 56 6D AC E8 26 31 CA CB 00 E2 AC 68 AD 8F 7E E4 80 72 25 78 26 BB EB 59 C5 16 C3 30 E0 C1 53 C9
"Time": 12/09/2093 14:18:14
SessionID: E4 3C 00 00 91 E9 3F 1E 25 FF 6B 00 87 3D 29 39 3D AB 22 6D 1A 6A B7 01 F5 83 D3 04 0B 14 0F 47
Extensions:
server_name i.instagram.com
ec_point_formats uncompressed [0x0], ansiX962_compressed_prime [0x1], ansiX962_compressed_char2 [0x2]
elliptic_curves sect571r1 [0xE], sect571k1 [0xD], secp521r1 [0x19], sect409k1 [0xB], sect409r1 [0xC], secp384r1 [0x18], sect283k1 [0x9], sect283r1 [0xA], secp256k1 [0x16], secp256r1 [0x17], sect239k1 [0x8], sect233k1 [0x6], sect233r1 [0x7], secp224k1 [0x14], secp224r1 [0x15], sect193r1 [0x4], sect193r2 [0x5], secp192k1 [0x12], secp192r1 [0x13], sect163k1 [0x1], sect163r1 [0x2], sect163r2 [0x3], secp160k1 [0xF], secp160r1 [0x10], secp160r2 [0x11]
SessionTicket empty
Ciphers:
[0004] SSL_RSA_WITH_RC4_128_MD5
[0005] SSL_RSA_WITH_RC4_128_SHA
[002F] TLS_RSA_AES_128_SHA
[0035] TLS_RSA_AES_256_SHA
[C002] TLS_ECDH_ECDSA_WITH_RC4_128_SHA
[C004] TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA
[C005] TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
[C00C] TLS_ECDH_RSA_WITH_RC4_128_SHA
[C00E] TLS_ECDH_RSA_WITH_AES_128_CBC_SHA
[C00F] TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
[C007] TLS_ECDHE_ECDSA_WITH_RC4_128_SHA
[C009] TLS1_CK_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
[C00A] TLS1_CK_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
[C011] TLS_ECDHE_RSA_WITH_RC4_128_SHA
[C013] TLS1_CK_ECDHE_RSA_WITH_AES_128_CBC_SHA
[C014] TLS1_CK_ECDHE_RSA_WITH_AES_256_CBC_SHA
[0033] TLS_DHE_RSA_WITH_AES_128_SHA
[0039] TLS_DHE_RSA_WITH_AES_256_SHA
[0032] TLS_DHE_DSS_WITH_AES_128_SHA
[0038] TLS_DHE_DSS_WITH_AES_256_SHA
[000A] SSL_RSA_WITH_3DES_EDE_SHA
[C003] TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA
[C00D] TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA
[C008] TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
[C012] TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
[0016] SSL_DHE_RSA_WITH_3DES_EDE_SHA
[0013] SSL_DHE_DSS_WITH_3DES_EDE_SHA
[0009] SSL_RSA_WITH_DES_SHA
[0015] SSL_DHE_RSA_WITH_DES_SHA
[0012] SSL_DHE_DSS_WITH_DES_SHA
[0003] SSL_RSA_EXPORT_WITH_RC4_40_MD5
[0008] SSL_RSA_EXPORT_WITH_DES40_SHA
[0014] SSL_DHE_RSA_EXPORT_WITH_DES40_SHA
[0011] SSL_DHE_DSS_EXPORT_WITH_DES40_SHA
[00FF] TLS_EMPTY_RENEGOTIATION_INFO_SCSV
Compression:
[00] NO_COMPRESSION
Response:
Encrypted HTTPS traffic flows through this CONNECT tunnel. HTTPS Decryption is enabled in Fiddler, so decrypted sessions running in this tunnel will be shown in the Web Sessions list.
Secure Protocol: Tls12
Cipher: Aes128 128bits
Hash Algorithm: Sha1 160bits
Key Exchange: ECDHE_RSA (0xae06) 256bits
== Server Certificate ==========
[Subject]
CN=*.instagram.com, O=Instagram LLC, L=Menlo Park, S=CA, C=US
[Issuer]
CN=DigiCert High Assurance CA-3, OU=www.digicert.com, O=DigiCert Inc, C=US
[Serial Number]
09D816F9BD53DA75B97D26B82B2B5359
[Not Before]
13/04/2015 21:00:00
[Not After]
31/12/2015 10:00:00
[Thumbprint]
18E23BD23F1F5E10FF974BD639F0B1731527AC18
Some idea?
Thanks
3 Answers, 1 is accepted
If you're seeing HTTPS traffic from Chrome but not from Instagram, the most likely explanation is that the Instagram app is rejecting the Fiddler root certificate due to a feature called Certificate Pinning.
A 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 are known 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.
In some cases, you can jailbreak the device (Android or iOS) and remove the certificate pinning checks, see e.g.:
https://github.com/iSECPartners/ios-ssl-kill-switch
http://blog.dewhurstsecurity.com/2015/11/10/mobile-security-certificate-pining.html
http://blog.attify.com/2015/08/24/intercepting-network-traffic-android/
Regards,
Eric Lawrence
Telerik
Rank 1
Regards,
Eric Lawrence
Telerik