Swizzling delegate sometimes blocks callback about trustkit

[nabla-c0d3]

Thanks - I'll look into it. You are leveraging kTSKSwizzleNetworkDelegates, correct?

[nickdnk]

I am not sure what you mean. In didFinishLaunching, I am doing this, and only this, to take advantage of TrustKit:

Edit: So yea, kTSKSwizzleNetworkDelegates is YES.

NSDictionary *trustKitConfig =
    @{
      kTSKSwizzleNetworkDelegates: @YES,
      kTSKPinnedDomains : @{
              @"mydomain.com" : @{
                      kTSKPublicKeyAlgorithms : @[kTSKAlgorithmRsa2048],
                      kTSKPublicKeyHashes : @[
                              @"PIN of my public key 1"
                              @"PIN of my public key 2"
                              ],
                      kTSKIncludeSubdomains : @YES,
                      kTSKEnforcePinning : @YES,
                      kTSKDisableDefaultReportUri : @YES
                      }
              }};

    [TrustKit initializeWithConfiguration:trustKitConfig];

[nabla-c0d3]

Yes, kTSKSwizzleNetworkDelegates is set to @YES by default. It is the thing that makes TrustKit magically intercept the App's connections to do SSL pinning.

[nickdnk]

Okay. As I wrote in the topic that's also the solution I'm using. Honestly I don't know how else to do it :)

[nabla-c0d3]

The other solution is to manually call into TSKPinningValidator to validate the server certificate in your connection delegates; it's described at the end of the "Getting Started" guide. By the way you have kTSKDisableDefaultReportUri enabled but if you have interest, you're free to use our dashboard for reviewing the reports.

[nickdnk]

Ah, okay. But the swizzling is a lot easier than that, and I don't need to do anything custom.

Please let me know if you want me to debug anything on 1.3 (and in that case explicitly what).

Sent from my iPhone

On 31 May 2016, at 19:38, Alban Diquet <[email protected]mailto:[email protected]> wrote:

The other solution is to manually call into TSKPinningValidator to validate the server certificate in your connection delegates; it's described at the end of the "Getting Started" guide. By the way you have kTSKDisableDefaultReportUri enabled but if you have interest, you're free to use our dashboard for reviewing the reports.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com//issues/48#issuecomment-222763043, or mute the threadhttps://github.com/notifications/unsubscribe/AIBYsluTXKcOiKnbywIb5kV2rMBRsdEhks5qHHIZgaJpZM4IpGOE.

[nabla-c0d3]

I am not able to reproduce this so far. Which version of AFNetworking are you using?

[nickdnk]

I'm sorry, I didn't receive any email indicating you had posted here (or I missed it). I use the latest version; 3.1.0.
That's odd. Is there anything you'd like me to try for you? I did absolutely nothing but downgrade from 1.3 to 1.2.5 to get it to work, and I did try upgrading and downgrading again just to be sure.

Edit: To point you in the direction of the problem; it does not happen for the "cached" validations. I'm not sure how the system works, but it seems that it does not validate the PIN for every single request. I.e. on 1.3 I'd get 3-4 good requests and then it would hang on the 5th as described in the original post. I would try the connection operation again (pull to refresh for instance) and it would succeed and then give me another 3-5-6 good requests before it would hang again. That being said it seems to be a bit more random than this, so it could take a few tries to get it to hang.

It happens across all of the different views in my app, indicating that it's not just a stand-alone issue for a single view controller. Updating basically breaks my entire app.

[nabla-c0d3]

No worries. I think I know what the bug is; thanks for the help.

[nickdnk]

You're welcome. I'll add 1.3.1 to my project and test it out once it's available through Pods.

[nabla-c0d3]

1.3.1 is on Pods now. Let me know if you still see the same issue.
Thanks!