IOS no https traffic possible

8 posts, 0 answers
  1. Robin
    Robin avatar
    1 posts
    Member since:
    May 2015

    Posted 06 May 2015 Link to this post

    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

  2. Eric Lawrence
    Admin
    Eric Lawrence avatar
    833 posts

    Posted 06 May 2015 Link to this post

    Hello, Robin--

    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
     
     
  3. Zachary
    Zachary avatar
    4 posts
    Member since:
    May 2015

    Posted 08 May 2015 in reply to Eric Lawrence Link to this post

    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.

  4. Eric Lawrence
    Admin
    Eric Lawrence avatar
    833 posts

    Posted 08 May 2015 Link to this post

    Hi, Zachary--

    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
     
  5. Zachary
    Zachary avatar
    4 posts
    Member since:
    May 2015

    Posted 08 May 2015 in reply to Eric Lawrence Link to this post

    Thanks for the quick response.  I will have another look tonight.  If memory serves me correctly, the default value of the protocol string was "SSL3; TLS1.0".  If the recommended setting includes TLS1.1 and TLS1.2 could that be made the default?  I don't know if that was the cause of some of the early errors I was seeing, but I know that out of the box, things weren't working until I started "fiddling" (excuse the pun) with that setting.
  6. Zachary
    Zachary avatar
    4 posts
    Member since:
    May 2015

    Posted 08 May 2015 in reply to Zachary Link to this post

    Also, since it doesn't appear that I can edit the original post, I'm using Windows 7.  What kind of differences should I expect between 7, 8, 8.1 (and 10 if you know, since I plan on upgrading)
  7. Eric Lawrence
    Admin
    Eric Lawrence avatar
    833 posts

    Posted 11 May 2015 Link to this post

    In general, new Windows versions often carry new HTTPS ciphers and/or change the order of the ciphers offered to the server, which can result in the server selecting a different cipher than it would if contacted by a different version of Windows.

    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
     
  8. Cho
    Cho avatar
    1 posts
    Member since:
    Jan 2015

    Posted 28 Nov in reply to Eric Lawrence Link to this post

    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.

Back to Top