Hi,
I have a problem capturing https traffic of my iPad remotly through a proxy on my PC.
I have fiddler installed on a Windows 7 machine. I have also installed the cert maker and generated a new
certificate which I have installed on the ipad.
When I open http websites i can see all the traffic. But when I try
to open https websites or apps using https the iPad cannot open the site
or use the app because of network issues. What is wrong? I followed
this instruction on multiple ios devices and recording pcs, but no https
traffic :(
http://docs.telerik.com/fiddler/configure-fiddler/tasks/ConfigureForiOS
7 Answers, 1 is accepted
I'm afraid you'll need to be more specific about what you mean when you say that it fails "because of network issues". What (exactly) do you observe?
When you examine the properties of the certificate you installed on the IPAD, what do they contain?
How specifically do you "open https websites"? Which browser are you using?
Which version of iOS are you using?
Thanks,
Eric Lawrence
Telerik
Rank 1
Hello,
I am having the same issue. Let me try to see if I can be more specific. For starters, I am using iOS 8.3 and Fiddler 4.5.1.0. As with Robin, I have installed the certificate. When I inspect the certificate in my iOS profiles, all of the fields look normal. Organizational Unit = http://www.fiddler2.com, for example. If you're interested in the value of a specific field of the certificate let me know and I will post it.
There are two primary sources of issues that I'm dealing with:
1) Chrome doesn't work at all. It doesn't matter how you set your "Enabled protocols" under Fiddler Options -> HTTPS, chrome simply doesn't work over HTTPS. Chrome 42.0.2311.47 Assuming you have your enabled protocols set to the magic value (mentioned below in #2) chrome will at least not hang when loading HTTPS pages, but it will instead refuse to load any HTTPS sites, saying "Your connection is not private" and gives me "NET::ERR_CERT_AUTHORITY_INVALID"
2) Nothing works if your enabled protocols include ssl2. I played around with these values and the best combination I came up with was "ssl3;tls1.2" If you include ssl2 in the list everything breaks. All browsers, even apple can't contact its own servers. Here's some examples of errors I've seen.
HTTPS handshake to github.com failed. System.ComponentModel.Win32Exception The client and server cannot communicate, because they do not possess a common algorithm
Warning: ClientHello record was 508 bytes long. Some servers have problems with ClientHello's greater than 255 bytes. https://github.com/ssllabs/research/wiki/Long-Handshake-Intolerance
!SecureClientPipeDirect failed: System.IO.IOException Authentication failed because the remote party has closed the transport stream. on pipe to (CN=init.itunes.apple.com, O=DO_NOT_TRUST_BC, OU=Created by http://www.fiddler2.com)
I admit I don't know much when it comes to this area, but why is the specification of the algorithm necessary? Shouldn't Fiddler be able to just figure it out? I recently switched over to Fiddler from mitmproxy (http://mitmproxy.org/) and with mitmproxy everything was working. All websites, HTTPS / HTTP, etc. So it seems like there should be something Fiddler can do here, although I have no idea what.
SSL2 shouldn't ever be enabled, and it isn't enabled in Fiddler unless you go out of the way to shoot yourself in the foot.
If you've properly configured your iOS device to trust Fiddler's root certificate, then HTTPS interception will work properly in clients except where certificate pinning is in use. While Certificate Pinning in Chrome won't matter on the Desktop, on iOS they ignore the Trusted Certificates store and as a consequence Fiddler interception will not work. But most sites and apps do not use pinning. If a site or app uses pinning, there's no workaround short of jailbreaking the device. This isn't a limitation unique to Fiddler-- every HTTPS-decrypting proxy has exactly the same limitation.
This message: HTTPS handshake to github.com failed. System.ComponentModel.Win32Exception The client and server cannot communicate, because they do not possess a common algorithm
...indicates that your Fiddler instance is not offering the server a TLS version that it is willing to accept. You should generally use SSL3; TLS1.0; TLS1.1; TLS1.2.
This message: Warning: ClientHello record was 508 bytes long. Some servers have problems with ClientHello's greater than 255 bytes. https://github.com/ssllabs/research/wiki/Long-Handshake-Intolerance
... is harmless.
This message: !SecureClientPipeDirect failed: System.IO.IOException Authentication failed because the remote party has closed the transport stream. on pipe to (CN=init.itunes.apple.com, O=DO_NOT_TRUST_BC, OU=Created by http://www.fiddler2.com)
... indicates that the client refused to send a request because it didn't like the certificate it received. This appears to be a request from iTunes and we do know that iTunes uses Certificate Pinning when talking to the Apple store on the web.
You didn't say which version of Windows you're using, but that does impact what ciphers are available.
Regards,
Eric Lawrence
Telerik
Rank 1
Rank 1
Enabling TLS1.1 and 1.2 by default will probably happen in the (relatively) near future. The problem is that, historically, even offering these protocol versions to servers could cause them to fail as I wrote here: http://blogs.msdn.com/b/ieinternals/archive/2011/03/25/misbehaving-https-servers-impair-tls-1.1-and-tls-1.2.aspx
These days, we're starting to see a very small number of servers that fail if these newer versions aren't enabled, so it's a tradeoff we continue to evaluate.
Regards,
Eric Lawrence
Telerik
Rank 1
The problem is "ssl2". It shouldn't be. But it was.
I had every stupid algorithm in that friggin list. So the servers should be able to choose whatever they want. But for some reason, Fiddler was returning 502 on every HTTPS call generated from the "Composer" and it wasn't capturing external connections.
Everything started to work after removing this ssl2.