TSKPinningValidator is a class for manually verifying a server’s identity against the global SSL pinning policy.
+
+
In specific scenarios, TrustKit cannot intercept outgoing SSL connections and automatically validate the server’s identity against the pinning policy:
+
+
+
All connections within an App that disables TrustKit’s network delegate swizzling by setting the kTSKSwizzleNetworkDelegates configuration key to NO.
+
Connections that do not rely on the NSURLConnection or NSURLSession APIs:
+
+
+
WKWebView connections.
+
Connections leveraging low-level network APIs (such as NSStream).
+
Connections initiated using a third-party SSL library such as OpenSSL.
+
+
+
+
For these connections, pin validation must be manually triggered using one of the two available methods:
+
+
+
evaluateTrust:forHostname: which evaluates the server’s certificate chain against the global SSL pinning policy.
+
handleChallenge:completionHandler: a helper method to be used for implementing pinning validation in challenge handler methods within NSURLSession and WKWebView delegates.
TrustKit is a class for programmatically configuring the global SSL pinning policy within an App.
+
+
The policy can be set either by adding it to the App’s Info.plist under the TSKConfiguration key, or by programmatically supplying it using the TrustKit class described here. Throughout the App’s lifecycle, TrustKit can only be initialized once so only one of the two techniques should be used.
+
+
A TrustKit pinning policy is a dictionary which contains some global, App-wide settings as well as domain-specific configuration keys. The following table shows the keys and their types, and uses indentation to indicate structure:
The various configuration keys that can be specified in the policy are described in the Constants section of the documentation.
+
+
Lastly, once TrustKit has been initialized, kTSKValidationCompletedNotification notifications will be posted every time TrustKit validates the certificate chain of a server; these notifications provide some information about the validation that was done and can be used for example for performance measurement.
TSKPinningValidator is a class for manually verifying a server’s identity against the global SSL pinning policy.
+
+
In specific scenarios, TrustKit cannot intercept outgoing SSL connections and automatically validate the server’s identity against the pinning policy:
+
+
+
All connections within an App that disables TrustKit’s network delegate swizzling by setting the kTSKSwizzleNetworkDelegates configuration key to NO.
+
Connections that do not rely on the NSURLConnection or NSURLSession APIs:
+
+
+
WKWebView connections.
+
Connections leveraging low-level network APIs (such as NSStream).
+
Connections initiated using a third-party SSL library such as OpenSSL.
+
+
+
+
For these connections, pin validation must be manually triggered using one of the two available methods:
+
+
+
evaluateTrust:forHostname: which evaluates the server’s certificate chain against the global SSL pinning policy.
+
handleChallenge:completionHandler: a helper method to be used for implementing pinning validation in challenge handler methods within NSURLSession and WKWebView delegates.
Evaluate the supplied server trust against the global SSL pinning policy previously configured. If the validation fails, a pin failure report will be sent.
+
+
When using the NSURLSession or WKWebView network APIs, the handleChallenge:completionHandler: method should be called instead, as it is simpler to use.
If no SSL pinning policy was configured for the supplied serverHostname, this method has no effect and will return TSKTrustDecisionDomainNotPinned without validating the supplied serverTrust at all. This means that the server’s serverTrust object must be verified against the device’s trust store using SecTrustEvaluate(). Failing to do so will disable SSL certificate validation.
+
+
+
+
@exception NSException Thrown when TrustKit has not been initialized with a pinning policy.
The trust object representing the server’s certificate chain. The trust’s evaluation policy is always overridden using SecTrustSetPolicies() to ensure all the proper SSL checks (expiration, hostname validation, etc.) are enabled.
+
+
+
+
+
+
+
+ serverHostname
+
+
+
+
+
The hostname of the server whose identity is being validated.
+
+
+
+
+
+
+
+
+
Return Value
+
A TSKTrustDecision which describes whether the SSL connection should be allowed or blocked, based on the global pinning policy.
Helper method for handling authentication challenges received within a NSURLSessionDelegate, NSURLSessionTaskDelegate or WKNavigationDelegate.
+
+
This method will evaluate the server trust within the authentication challenge against the global SSL pinning policy previously configured, and then call the completionHandler with the corresponding disposition and credential. For example, this method can be leveraged in a WKNavigationDelegate challenge handler method:
The authentication challenge, supplied by the URL loading system to the delegate’s challenge handler method.
+
+
+
+
+
+
+
+ completionHandler
+
+
+
+
+
A block to invoke to respond to the challenge, supplied by the URL loading system to the delegate’s challenge handler method.
+
+
+
+
+
+
+
+
+
Return Value
+
YES if the challenge was handled and the completionHandler was successfuly invoked. NO if the challenge could not be handled because it was not for server certificate validation (ie. the challenge’s authenticationMethod was not NSURLAuthenticationMethodServerTrust).
TrustKit is a class for programmatically configuring the global SSL pinning policy within an App.
+
+
The policy can be set either by adding it to the App’s Info.plist under the TSKConfiguration key, or by programmatically supplying it using the TrustKit class described here. Throughout the App’s lifecycle, TrustKit can only be initialized once so only one of the two techniques should be used.
+
+
A TrustKit pinning policy is a dictionary which contains some global, App-wide settings as well as domain-specific configuration keys. The following table shows the keys and their types, and uses indentation to indicate structure:
The various configuration keys that can be specified in the policy are described in the Constants section of the documentation.
+
+
Lastly, once TrustKit has been initialized, kTSKValidationCompletedNotification notifications will be posted every time TrustKit validates the certificate chain of a server; these notifications provide some information about the validation that was done and can be used for example for performance measurement.
Initialize the global SSL pinning policy with the supplied configuration.
+
+
This method should be called as early as possible in the App’s lifecycle to ensure that the App’s very first SSL connections are validated by TrustKit. Once TrustKit has been initialized, notifications will be posted for any SSL pinning validation performed.
This method sets the global logger, used when TrustKit needs to display a message to the developer.
+
+
If a global logger is not set, the default logger will be used, which will print TrustKit log messages (using NSLog()) when the App is built in Debug mode. If the App was built for Release, the default logger will not print any messages at all.
A boolean. If set to YES, TrustKit will perform method swizzling on the App’s NSURLConnection and NSURLSession delegates in order to automatically add SSL pinning validation to the App’s connections.
+
+
Swizzling allows enabling pinning within an App without having to find and modify each and every instance of NSURLConnection or NSURLSession delegates.
+However, it should only be enabled for simple Apps, as it may not work properly in several scenarios including:
+
+
+
Apps with complex connection delegates, for example to handle client authentication via certificates or basic authentication.
+
Apps where method swizzling of the connection delegates is already performed by another module or library (such as Analytics SDKs).
+
Apps that do no use NSURLSession or NSURLConnection for their connections.
+
+
+
In such scenarios or if the developer wants a tigher control on the App’s networking behavior, kTSKSwizzleNetworkDelegates should be set to NO; the developer should then manually add pinning validation to the App’s authentication handlers.
A dictionary with domains (such as www.domain.com) as keys and dictionaries as values.
+
+
Each entry should contain domain-specific settings for performing pinning validation when connecting to the domain, including for example the domain’s public key hashes. A list of all domain-specific keys is available in the Domain-specific Keys sections.
A boolean. If set to YES, pinning validation will be skipped if the server’s certificate chain terminates at a user-defined trust anchor (such as a root CA that isn’t part of OS X’s default trust store) and no pin failure reports will be sent; default value is YES.
+
+
This is useful for allowing SSL connections through corporate proxies or firewalls. See How does key pinning interact with local proxies and filters? within the Chromium security FAQ at https://www.chromium.org/Home/chromium-security/security-faq for more information.
An array of TSKSupportedAlgorithm constants to specify the public key algorithms for the keys to be pinned.
+
+
TrustKit requires this information in order to compute SSL pins when validating a server’s certificate chain, because the Security framework does not provide APIs to extract the key’s algorithm from an SSL certificate. To minimize the performance impact of Trustkit, only one algorithm should be enabled.
An array of URLs to which pin validation failures should be reported.
+
+
To minimize the performance impact of sending reports on each validation failure, the reports are uploaded using the background transfer service and are also rate-limited to one per day and per type of failure. For HTTPS report URLs, the HTTPS connections will ignore the SSL pinning policy and use the default certificate validation mechanisms, in order to maximize the chance of the reports reaching the server. The format of the reports is similar to the one described in RFC 7469 for the HPKP specification:
A boolean. If set to YES, the default report URL for sending pin failure reports will be disabled; default value is NO.
+
+
By default, pin failure reports are sent to a report server hosted by Data Theorem, for detecting potential CA compromises and man-in-the-middle attacks, as well as providing a free dashboard for developers; email info@datatheorem.com if you’d like a dashboard for your App. Only pin failure reports are sent, which contain the App’s bundle ID, the IDFV, and the server’s hostname and certificate chain that failed validation.
The name of the notification to be posted for every request that is going through TrustKit’s pinning validation mechanism.
+
+
Once TrustKit has been initialized, notifications will be posted with this name every time TrustKit validates the certificate chain for a server configured in the SSL pinning policy; if the server’s hostname does not have an entry in the pinning policy, no notifications get posted as no pinning validation was performed.
+
+
These notifications can be used for performance measurement or to act upon any pinning validation performed by TrustKit (for example to customize the reporting mechanism). The notifications provide details about TrustKit’s inner-workings which most Apps should not need to process. Hence, these notifications can be ignored unless the App requires some advanced customization in regards to pinning validation.
The TSKPinningValidationResult returned when validating the server’s certificate chain, which represents the result of evaluating the certificate chain against the configured SSL pins for this server.
The TSKTrustDecision returned when validating the certificate’s chain, which describes whether the connection should be blocked or allowed, based on the TSKPinningValidationResult returned when evaluating the server’s certificate chain and the SSL pining policy configured for this server.
+
+
For example, the pinning validation could have failed (returning TSKPinningValidationFailed) but the policy might be set to ignore pinning validation failures for this server, thereby returning TSKTrustDecisionShouldAllowConnection.
The entry within the SSL pinning configuration that was used as the pinning policy for the server being validated. It will be the same as the kTSKValidationServerHostnameNotificationKey entry unless the server is a subdomain of a domain configured in the pinning policy with kTSKIncludeSubdomains enabled. The corresponding pinning configuration that was used for validation can be retrieved using:
Based on the server’s certificate chain and the global pinning policy for this domain, the SSL connection should be allowed.
+This return value does not necessarily mean that the pinning validation succeded (for example if kTSKEnforcePinning was set to NO for this domain). If a pinning validation failure occured and if a report URI was configured, a pin failure report was sent.
Based on the server’s certificate chain and the global pinning policy for this domain, the SSL connection should be blocked.
+A pinning validation failure occured and if a report URI was configured, a pin failure report was sent.
No pinning policy was configured for this domain and TrustKit did not validate the server’s identity.
+Because this will happen in an authentication handler, it means that the server’s serverTrust object needs to be verified against the device’s trust store using SecTrustEvaluate(). Failing to do so will disable SSL certificate validation.
A key to be used to retrieve data about the pinning validation that occured, from the userInfo dictionary attached to a kTSKValidationCompletedNotification notification.
TSKPinningValidator is a class for manually verifying a server’s identity against the global SSL pinning policy.
+
+
In specific scenarios, TrustKit cannot intercept outgoing SSL connections and automatically validate the server’s identity against the pinning policy:
+
+
+
All connections within an App that disables TrustKit’s network delegate swizzling by setting the kTSKSwizzleNetworkDelegates configuration key to NO.
+
Connections that do not rely on the NSURLConnection or NSURLSession APIs:
+
+
+
WKWebView connections.
+
Connections leveraging low-level network APIs (such as NSStream).
+
Connections initiated using a third-party SSL library such as OpenSSL.
+
+
+
+
For these connections, pin validation must be manually triggered using one of the two available methods:
+
+
+
evaluateTrust:forHostname: which evaluates the server’s certificate chain against the global SSL pinning policy.
+
handleChallenge:completionHandler: a helper method to be used for implementing pinning validation in challenge handler methods within NSURLSession and WKWebView delegates.
TrustKit is a class for programmatically configuring the global SSL pinning policy within an App.
+
+
The policy can be set either by adding it to the App’s Info.plist under the TSKConfiguration key, or by programmatically supplying it using the TrustKit class described here. Throughout the App’s lifecycle, TrustKit can only be initialized once so only one of the two techniques should be used.
+
+
A TrustKit pinning policy is a dictionary which contains some global, App-wide settings as well as domain-specific configuration keys. The following table shows the keys and their types, and uses indentation to indicate structure:
The various configuration keys that can be specified in the policy are described in the Constants section of the documentation.
+
+
Lastly, once TrustKit has been initialized, kTSKValidationCompletedNotification notifications will be posted every time TrustKit validates the certificate chain of a server; these notifications provide some information about the validation that was done and can be used for example for performance measurement.
TSKPinningValidator is a class for manually verifying a server’s identity against the global SSL pinning policy.
+
+
In specific scenarios, TrustKit cannot intercept outgoing SSL connections and automatically validate the server’s identity against the pinning policy:
+
+
+
All connections within an App that disables TrustKit’s network delegate swizzling by setting the kTSKSwizzleNetworkDelegates configuration key to NO.
+
Connections that do not rely on the NSURLConnection or NSURLSession APIs:
+
+
+
WKWebView connections.
+
Connections leveraging low-level network APIs (such as NSStream).
+
Connections initiated using a third-party SSL library such as OpenSSL.
+
+
+
+
For these connections, pin validation must be manually triggered using one of the two available methods:
+
+
+
evaluateTrust:forHostname: which evaluates the server’s certificate chain against the global SSL pinning policy.
+
handleChallenge:completionHandler: a helper method to be used for implementing pinning validation in challenge handler methods within NSURLSession and WKWebView delegates.
Evaluate the supplied server trust against the global SSL pinning policy previously configured. If the validation fails, a pin failure report will be sent.
+
+
When using the NSURLSession or WKWebView network APIs, the handleChallenge:completionHandler: method should be called instead, as it is simpler to use.
If no SSL pinning policy was configured for the supplied serverHostname, this method has no effect and will return TSKTrustDecisionDomainNotPinned without validating the supplied serverTrust at all. This means that the server’s serverTrust object must be verified against the device’s trust store using SecTrustEvaluate(). Failing to do so will disable SSL certificate validation.
+
+
+
+
@exception NSException Thrown when TrustKit has not been initialized with a pinning policy.
The trust object representing the server’s certificate chain. The trust’s evaluation policy is always overridden using SecTrustSetPolicies() to ensure all the proper SSL checks (expiration, hostname validation, etc.) are enabled.
+
+
+
+
+
+
+
+ serverHostname
+
+
+
+
+
The hostname of the server whose identity is being validated.
+
+
+
+
+
+
+
+
+
Return Value
+
A TSKTrustDecision which describes whether the SSL connection should be allowed or blocked, based on the global pinning policy.
Helper method for handling authentication challenges received within a NSURLSessionDelegate, NSURLSessionTaskDelegate or WKNavigationDelegate.
+
+
This method will evaluate the server trust within the authentication challenge against the global SSL pinning policy previously configured, and then call the completionHandler with the corresponding disposition and credential. For example, this method can be leveraged in a WKNavigationDelegate challenge handler method:
The authentication challenge, supplied by the URL loading system to the delegate’s challenge handler method.
+
+
+
+
+
+
+
+ completionHandler
+
+
+
+
+
A block to invoke to respond to the challenge, supplied by the URL loading system to the delegate’s challenge handler method.
+
+
+
+
+
+
+
+
+
Return Value
+
YES if the challenge was handled and the completionHandler was successfuly invoked. NO if the challenge could not be handled because it was not for server certificate validation (ie. the challenge’s authenticationMethod was not NSURLAuthenticationMethodServerTrust).
TrustKit is a class for programmatically configuring the global SSL pinning policy within an App.
+
+
The policy can be set either by adding it to the App’s Info.plist under the TSKConfiguration key, or by programmatically supplying it using the TrustKit class described here. Throughout the App’s lifecycle, TrustKit can only be initialized once so only one of the two techniques should be used.
+
+
A TrustKit pinning policy is a dictionary which contains some global, App-wide settings as well as domain-specific configuration keys. The following table shows the keys and their types, and uses indentation to indicate structure:
The various configuration keys that can be specified in the policy are described in the Constants section of the documentation.
+
+
Lastly, once TrustKit has been initialized, kTSKValidationCompletedNotification notifications will be posted every time TrustKit validates the certificate chain of a server; these notifications provide some information about the validation that was done and can be used for example for performance measurement.
Initialize the global SSL pinning policy with the supplied configuration.
+
+
This method should be called as early as possible in the App’s lifecycle to ensure that the App’s very first SSL connections are validated by TrustKit. Once TrustKit has been initialized, notifications will be posted for any SSL pinning validation performed.
This method sets the global logger, used when TrustKit needs to display a message to the developer.
+
+
If a global logger is not set, the default logger will be used, which will print TrustKit log messages (using NSLog()) when the App is built in Debug mode. If the App was built for Release, the default logger will not print any messages at all.
A boolean. If set to YES, TrustKit will perform method swizzling on the App’s NSURLConnection and NSURLSession delegates in order to automatically add SSL pinning validation to the App’s connections.
+
+
Swizzling allows enabling pinning within an App without having to find and modify each and every instance of NSURLConnection or NSURLSession delegates.
+However, it should only be enabled for simple Apps, as it may not work properly in several scenarios including:
+
+
+
Apps with complex connection delegates, for example to handle client authentication via certificates or basic authentication.
+
Apps where method swizzling of the connection delegates is already performed by another module or library (such as Analytics SDKs).
+
Apps that do no use NSURLSession or NSURLConnection for their connections.
+
+
+
In such scenarios or if the developer wants a tigher control on the App’s networking behavior, kTSKSwizzleNetworkDelegates should be set to NO; the developer should then manually add pinning validation to the App’s authentication handlers.
A dictionary with domains (such as www.domain.com) as keys and dictionaries as values.
+
+
Each entry should contain domain-specific settings for performing pinning validation when connecting to the domain, including for example the domain’s public key hashes. A list of all domain-specific keys is available in the Domain-specific Keys sections.
A boolean. If set to YES, pinning validation will be skipped if the server’s certificate chain terminates at a user-defined trust anchor (such as a root CA that isn’t part of OS X’s default trust store) and no pin failure reports will be sent; default value is YES.
+
+
This is useful for allowing SSL connections through corporate proxies or firewalls. See How does key pinning interact with local proxies and filters? within the Chromium security FAQ at https://www.chromium.org/Home/chromium-security/security-faq for more information.
An array of TSKSupportedAlgorithm constants to specify the public key algorithms for the keys to be pinned.
+
+
TrustKit requires this information in order to compute SSL pins when validating a server’s certificate chain, because the Security framework does not provide APIs to extract the key’s algorithm from an SSL certificate. To minimize the performance impact of Trustkit, only one algorithm should be enabled.
An array of URLs to which pin validation failures should be reported.
+
+
To minimize the performance impact of sending reports on each validation failure, the reports are uploaded using the background transfer service and are also rate-limited to one per day and per type of failure. For HTTPS report URLs, the HTTPS connections will ignore the SSL pinning policy and use the default certificate validation mechanisms, in order to maximize the chance of the reports reaching the server. The format of the reports is similar to the one described in RFC 7469 for the HPKP specification:
A boolean. If set to YES, the default report URL for sending pin failure reports will be disabled; default value is NO.
+
+
By default, pin failure reports are sent to a report server hosted by Data Theorem, for detecting potential CA compromises and man-in-the-middle attacks, as well as providing a free dashboard for developers; email info@datatheorem.com if you’d like a dashboard for your App. Only pin failure reports are sent, which contain the App’s bundle ID, the IDFV, and the server’s hostname and certificate chain that failed validation.
The name of the notification to be posted for every request that is going through TrustKit’s pinning validation mechanism.
+
+
Once TrustKit has been initialized, notifications will be posted with this name every time TrustKit validates the certificate chain for a server configured in the SSL pinning policy; if the server’s hostname does not have an entry in the pinning policy, no notifications get posted as no pinning validation was performed.
+
+
These notifications can be used for performance measurement or to act upon any pinning validation performed by TrustKit (for example to customize the reporting mechanism). The notifications provide details about TrustKit’s inner-workings which most Apps should not need to process. Hence, these notifications can be ignored unless the App requires some advanced customization in regards to pinning validation.
The TSKPinningValidationResult returned when validating the server’s certificate chain, which represents the result of evaluating the certificate chain against the configured SSL pins for this server.
The TSKTrustDecision returned when validating the certificate’s chain, which describes whether the connection should be blocked or allowed, based on the TSKPinningValidationResult returned when evaluating the server’s certificate chain and the SSL pining policy configured for this server.
+
+
For example, the pinning validation could have failed (returning TSKPinningValidationFailed) but the policy might be set to ignore pinning validation failures for this server, thereby returning TSKTrustDecisionShouldAllowConnection.
The entry within the SSL pinning configuration that was used as the pinning policy for the server being validated. It will be the same as the kTSKValidationServerHostnameNotificationKey entry unless the server is a subdomain of a domain configured in the pinning policy with kTSKIncludeSubdomains enabled. The corresponding pinning configuration that was used for validation can be retrieved using:
Based on the server’s certificate chain and the global pinning policy for this domain, the SSL connection should be allowed.
+This return value does not necessarily mean that the pinning validation succeded (for example if kTSKEnforcePinning was set to NO for this domain). If a pinning validation failure occured and if a report URI was configured, a pin failure report was sent.
Based on the server’s certificate chain and the global pinning policy for this domain, the SSL connection should be blocked.
+A pinning validation failure occured and if a report URI was configured, a pin failure report was sent.
No pinning policy was configured for this domain and TrustKit did not validate the server’s identity.
+Because this will happen in an authentication handler, it means that the server’s serverTrust object needs to be verified against the device’s trust store using SecTrustEvaluate(). Failing to do so will disable SSL certificate validation.
A key to be used to retrieve data about the pinning validation that occured, from the userInfo dictionary attached to a kTSKValidationCompletedNotification notification.
TrustKit is an open source framework that makes it easy to deploy SSL public key
+pinning in any iOS, macOS, tvOS or watchOS App.
+
+
This is the API documentation for TrustKit. For an overview of the framework and
+a more general guide to using it, see the project’s page at
+https://datatheorem.github.io/TrustKit .
+
+
TrustKit requires iOS 7.0, macOS 10.9, tvOS 10.0 or watchOS 3.0 as the minimum
+deployment target.
+
+
Two classes are available enabling SSL pinning in an App:
+
+
+
TrustKit, for programmatically configuring the global SSL pinning policy within an
+App.
+
TSKPinningValidator, for manually validating a certificate chain against the App’s
+configured pinning policy.
TrustKit is an open source framework that makes it easy to deploy SSL public key
+pinning in any iOS, macOS, tvOS or watchOS App.
+
+
This is the API documentation for TrustKit. For an overview of the framework and
+a more general guide to using it, see the project’s page at
+https://datatheorem.github.io/TrustKit .
+
+
TrustKit requires iOS 7.0, macOS 10.9, tvOS 10.0 or watchOS 3.0 as the minimum
+deployment target.
+
+
Two classes are available enabling SSL pinning in an App:
+
+
+
TrustKit, for programmatically configuring the global SSL pinning policy within an
+App.
+
TSKPinningValidator, for manually validating a certificate chain against the App’s
+configured pinning policy.