Adapting ATS from server to iOS client

iOS 9 has been released, and everyone has to experience the ATS (App Transport Security) feature in the network. This blog post will talk about the adaptation of ATS from the server to the iOS client based on my experience in recent days.

1. Briefly talk about ATS (App Transport Security)

ATS (App Transport Security) is a feature designed to improve the security of data transmission between apps and servers. This feature has been available since iOS 9 and OS X 10.11. By default, it needs to meet the following conditions:

The server TLS version is at least 1.2

Connection encryption only allows a few advanced encryptions

The certificate must be signed using a SHA256 or better hash algorithm, and either an RSA key of 2048 bits or longer, or an ECC key of 256 bits or longer.

If you want to know which advanced encryption is allowed, please see the official document App Transport Security Technote for details.

2. Build an HTTPS server

There are two ways to build an HTTPS server. One is to create a certificate request, then go to an authority for authentication, and then configure it to the server; the other is to build a certificate yourself and then configure it to the server. The HTTPS server built in the first way is of course the best. If you build a website, it will be trusted directly, and when it is used as a server for a mobile app, there is no need to make too many adaptations for ATS. Although it costs money to authenticate with an authoritative organization, there are also free third-party certification agencies nowadays; the HTTPS server built in the second way is completely unfeasible for websites. When users open it, a warning pops up directly, saying that this is an untrusted website, asking users whether to continue. The experience is very poor, and users feel that the website is unsafe. For mobile terminals, this was no problem before iOS9 came out, but after iOS9 came out, the second way could not pass the ATS feature, and NSAllowsArbitraryLoads needed to be set to YES. Therefore, I recommend using the first way to build an HTTPS server.

Next, let’s talk about how to operate these two methods.

*** Type: Use a CA-certified certificate to build an HTTPS server

1. Create a certificate request and submit it to the CA for certification

 #Private key
 openssl genrsa -des3 -out private .key 2048  
 #Generate the server's private key and remove the key password
 openssl rsa -in private .key -out server.key
 #Generate a certificate request
 openssl req -new -key private .key -out server.csr

Submit the generated server.csr to the CA organization. After the CA organization signs it, it will generate a signed root certificate and server certificate and send them to you. At this time, the certificate is the certificate after CA certification. Here we rename the root certificate and server certificate to ca.crt and serve.crt respectively.

2. Configure Apache server

Upload ca.crt, server.key, and server.crt to the Alibaba Cloud server, use SSH to log in to the directory of these three files, and execute the following commands

mkdir ssl
cp server.crt /alidata/server/httpd/conf/ssl/server.crt
cp server.key /alidata/server/httpd/conf/ssl/server.key
cp demoCA/cacert.pem /alidata/server/httpd/conf/ssl/ca.crt
cp -r ssl /alidata/server/httpd/conf/

Edit the /alidata/server/httpd/conf/extra/httpd-ssl.conf file, find SSLCertificateFile, SSLCertificateKeyFile, SSLCACertificatePath, and SSLCACertificateFile and modify them:

 # Specify the server certificate location
 SSLCertificateFile "/alidata/server/httpd/conf/ssl/server.crt"  
 # Specify the server certificate key location
 SSLCertificateKeyFile "/alidata/server/httpd/conf/ssl/server.key"  
 # Certificate Directory
 SSLCACertificatePath "/alidata/server/httpd/conf/ssl"  
 # Root certificate location
 SSLCACertificateFile "/alidata/server/httpd/conf/ssl/ca.crt"   
 
 Modify the vhost configuration vim /alidata/server/httpd/conf/vhosts/phpwind.conf

 SSLCertificateFile /alidata/server/httpd/conf/ssl/server.crt
 SSLCertificateKeyFile /alidata/server/httpd/conf/ssl/server.key
 SSLCACertificatePath /alidata/server/httpd/conf/ssl
 SSLCACertificateFile /alidata/server/httpd/conf/ssl/ca.crt
 ServerName www.casetree.cn
 DocumentRoot /alidata/www

***, restart the Apache server, enter the URL in the browser to check whether the configuration is successful. I am using it for personal use and applied for a free certificate. The website I applied for the certificate is WoSign.

Construction results: https://www.casetree.cn

The second method is to build your own certificate to configure the HTTPS server

Please refer to my previous article to configure HTTPS server with self-built certificate

3. Use nscurl to detect the server

After building the HTTPS server, you can use the nscurl command to check whether the established HTTPS server can pass the ATS feature.

 nscurl --ats-diagnostics --verbose https: //casetree.cn  

If the HTTPS server can pass the ATS feature, all the test cases above are PASS; if the result of a certain item is FAIL, find the ATS Dictionary to check, and you will know which ATS condition the HTTPS server does not meet. Here I encountered a problem before, that is, when I built my own certificate, when I tested it through this command, I found that the Result was all FAIL, and a very strange phenomenon also appeared in the iOS code test, that is, the same code, requesting data is completely normal on iOS8.4, but on iOS9, the connection fails directly. In the end, it was discovered that it was because the self-built certificate was not trusted and could not pass ATS unless NSAllowsArbitraryLoads was set to YES.

4. iOS Client

In the second step above, the HTTPS server meets the default conditions of ATS, and the SSL certificate is certified by an authoritative CA organization. When we use Xcode7 to develop, we don't need to do anything about the network adaptation, and we can communicate with the server normally. However, when we have higher requirements for security or we build our own certificates, we need to import the certificate locally for verification.

So, how do you import a certificate locally for verification?

Let me mention here that since the iOS client supports certificates in DER format, we need to create a client certificate. To create a client certificate, just export the server's CA root certificate into DER format.

 openssl x509 -inform PEM -outform DER -in ca.crt -out ca.cer

After importing the certificate, let's talk about using NSURLSession and AFNetworking for local verification.

First, let's talk about using NSURLSession verification

The verification steps are as follows:

Import the CA root certificate into the project, that is, the ca.cer we created

Get the trust object, read the imported certificate data through the SecCertificateCreateWithData method to generate a certificate object, and then set this certificate as the trusted root certificate (trusted anchor) of the trust object through SecTrustSetAnchorCertificates

Verify the trust object through the SecTrustEvaluate method

The following is the main OC implementation code. I have also put the Demo project on github. There are two languages ​​​​in OC and Swift. To download the Demo, please click HTTPSConnectDemo.

 - ( void )viewDidLoad {
 [ super viewDidLoad];
 //Import the client certificate  
 NSString *cerPath = [[NSBundle mainBundle] pathForResource:@ "ca" ofType:@ "cer" ];
 NSData *data = [NSData dataWithContentsOfFile:cerPath];
 SecCertificateRef certificate = SecCertificateCreateWithData(NULL, (__bridge CFDataRef) data);
 self.trustedCerArr = @[(__bridge_transfer id)certificate];
 //Send request  
 NSURL *testURL = [NSURL URLWithString:@ "https://casetree.cn/web/test/demo.php" ];
 NSURLSession *session = [NSURLSession sessionWithConfiguration:[NSURLSessionConfiguration defaultSessionConfiguration] delegate:self delegateQueue:[NSOperationQueue mainQueue]];
 NSURLSessionDataTask *task = [session dataTaskWithRequest:[NSURLRequest requestWithURL:testURL]];
 [task resume];
 // Do any additional setup after loading the view, typically from a nib.  
 } 
 
 #pragma mark - NSURLSessionDelegate
 - ( void )URLSession:(NSURLSession *)session didReceiveChallenge:(NSURLAuthenticationChallenge *)challenge
 completionHandler:( void (^)(NSURLSessionAuthChallengeDisposition disposition, NSURLCredential * __nullable credential))completionHandler{ 
 
 OSStatus err;
 NSURLSessionAuthChallengeDisposition disposition = NSURLSessionAuthChallengePerformDefaultHandling;
 SecTrustResultType trustResult = kSecTrustResultInvalid;
 NSURLCredential *credential = nil; 
 
 //Get the server's trust object  
 SecTrustRef serverTrust = challenge.protectionSpace.serverTrust;
 //Set the read certificate as the root certificate of serverTrust  
 err = SecTrustSetAnchorCertificates(serverTrust, (__bridge CFArrayRef)self.trustedCerArr); 
 
 if (err == noErr){
 //Use the locally imported certificate to verify whether the server's certificate is credible. If SecTrustSetAnchorCertificatesOnly is set to NO, it only needs to be authenticated by either the local or system certificate chain.  
 err = SecTrustEvaluate(serverTrust, &trustResult);
 } 
 
 if (err == errSecSuccess && (trustResult == kSecTrustResultProceed || trustResult == kSecTrustResultUnspecified)){
 //If the authentication is successful, a credential is created and returned to the server  
 disposition = NSURLSessionAuthChallengeUseCredential;
 credential = [NSURLCredential credentialForTrust:serverTrust];
 }
 else {
 disposition = NSURLSessionAuthChallengeCancelAuthenticationChallenge;
 } 
 
 //Callback credentials, passed to the server  
 if (completionHandler){
 completionHandler(disposition, credential);
 }
 }

Notice:

1. The SecTrustSetAnchorCertificates method will set a flag to block the trust object from trusting other root certificates. If you also want to trust the system default root certificate, please call the SecTrustSetAnchorCertificatesOnly method and clear this flag (set to NO). 2. There are more verification methods than this one. For more verification methods, please refer to HTTPS Server Trust Evaluation

Next, let’s talk about how AFNetworking is authenticated and how we use AFNetworking.

AFNetworking's certificate verification is done by AFSecurityPolicy, so here we mainly learn about AFSecurityPolicy. Note: I use AFNetworking 2.6.0 here, which is different from 2.5.0.

When it comes to AFSecurityPolicy, we must mention its three important properties, as follows:

 @property (readonly, nonatomic, assign) AFSSLPinningMode SSLPinningMode;
 @property (nonatomic, assign) BOOL allowInvalidCertificates;
 @property (nonatomic, assign) BOOL validatesDomainName;

SSLPingMode is the most important attribute, which indicates how AFSecurityPolicy is verified. It is an enumeration type with three values: AFSSLPinningModeNone, AFSSLPinningModePublicKey, and AFSSLPinningModeCertificate. Among them, AFSSLPinningModeNone means that AFSecurityPolicy does not perform stricter verification. As long as the certificate is trusted by the system, it can pass the verification. However, it is affected by allowInvalidCertificates and validatesDomainName; AFSSLPinningModePublicKey verifies by comparing the public key (PublicKey) part of the certificate, obtains the local certificate and the server certificate through the SecTrustCopyPublicKey method, and then compares them. If one of them is the same, it passes the verification. This method is mainly suitable for HTTPS servers built with self-built certificates and verifications that require higher security requirements; AFSSLPinningModeCertificate directly sets the local certificate as the trusted root certificate, and then makes a judgment, and compares whether the contents of the local certificate and the server certificate are the same, for secondary judgment. This method is suitable for verifications with higher security requirements.

The allowInvalidCertificates attribute indicates whether untrusted certificates are allowed to pass verification. The default value is NO.

The validatesDomainName attribute indicates whether to validate the host name. The default value is YES.

Next, let's talk about the verification process. The verification process is mainly placed in the - (BOOL)evaluateServerTrust:(SecTrustRef)serverTrust forDomain:(NSString *)domain method of AFSecurityPolicy.

c

 - (BOOL)evaluateServerTrust:(SecTrustRef)serverTrust
 forDomain:(NSString *)domain
 {
 //When using a self-built certificate to verify a domain name, you need to use AFSSLPinningModePublicKey or AFSSLPinningModeCertificate  
 if (domain && self.allowInvalidCertificates && self.validatesDomainName && (self.SSLPinningMode == AFSSLPinningModeNone || [self.pinnedCertificates count] == ​​0 )) {
 NSLog(@ "In order to validate a domain name for self signed certificates, you MUST use pinning." );
 return NO;
 } 
 
 NSMutableArray *policies = [NSMutableArray array];
 //When you need to verify the domain name, you need to add a strategy to verify the domain name  
 if (self.validatesDomainName) {
 [policies addObject:(__bridge_transfer id)SecPolicyCreateSSL( true , (__bridge CFStringRef)domain)];
 } else {
 [policies addObject:(__bridge_transfer id)SecPolicyCreateBasicX509()];
 } 
 
 //Set the verification strategy, which can be multiple  
 SecTrustSetPolicies(serverTrust, (__bridge CFArrayRef)policies);
 //When SSLPinningMode is AFSSLPinningModeNone, allowInvalidCertificates is YES, which means that any server certificate can be verified; if it is NO, it is necessary to determine whether this server certificate is a certificate trusted by the system  
 if (self.SSLPinningMode == AFSSLPinningModeNone) {
 if (self.allowInvalidCertificates || AFServerTrustIsValid(serverTrust)){
 return YES;
 } else {
 return NO;
 }
 } else   if (!AFServerTrustIsValid(serverTrust) && !self.allowInvalidCertificates) {
 return NO;
 } 
 
 //Get the content of the server certificate  
 NSArray *serverCertificates = AFCertificateTrustChainForServerTrust(serverTrust);
 switch (self.SSLPinningMode) {
 case AFSSLPinningModeNone:
 default :
 return NO;
 case AFSSLPinningModeCertificate: {
 //AFSSLPinningModeCertificate directly sets the local certificate as the trusted root certificate, and then makes a judgment and compares whether the content of the local certificate is the same as the server certificate. If one of them is the same, it returns YES   
 
 NSMutableArray *pinnedCertificates = [NSMutableArray array];
 for (NSData *certificateData in self.pinnedCertificates) {
 [pinnedCertificates addObject:(__bridge_transfer id)SecCertificateCreateWithData(NULL, (__bridge CFDataRef)certificateData)];
 }
 //Set the local certificate as the root certificate  
 SecTrustSetAnchorCertificates(serverTrust, (__bridge CFArrayRef)pinnedCertificates); 
 
 //Use the local certificate to determine whether the server certificate is credible. If it is not credible, the verification fails.  
 if (!AFServerTrustIsValid(serverTrust)) {
 return NO;
 } 
 
 // Check whether the contents of the local certificate and the server certificate are the same  
 NSUInteger trustedCertificateCount = 0 ;
 for (NSData *trustChainCertificate in serverCertificates) {
 if ([self.pinnedCertificates containsObject:trustChainCertificate]) {
 trustedCertificateCount++;
 }
 }
 return trustedCertificateCount > 0 ;
 }
 case AFSSLPinningModePublicKey: {
 //AFSSLPinningModePublicKey verifies by comparing the public key (PublicKey) part of the certificate. The local certificate and server certificate are obtained through the SecTrustCopyPublicKey method, and then compared. If one is the same, it is verified.  
 NSUInteger trustedPublicKeyCount = 0 ;
 NSArray *publicKeys = AFPublicKeyTrustChainForServerTrust(serverTrust);
 //Judge whether the public key of the server certificate is the same as the local certificate public key. If they are the same, the client authentication is successful.  
 for (id trustChainPublicKey in publicKeys) {
 for (id pinnedPublicKey in self.pinnedPublicKeys) {
 if (AFSecKeyIsEqualToKey((__bridge SecKeyRef)trustChainPublicKey, (__bridge SecKeyRef)pinnedPublicKey)) {
 trustedPublicKeyCount += 1 ;
 }
 }
 }
 return trustedPublicKeyCount > 0 ;
 }
 }
 return NO;
 }

Having said the verification process, let's take a look at how to use AFNetworking. The code is as follows:

 _httpClient = [[BGAFHTTPClient alloc] initWithBaseURL:[NSURL URLWithString:baseURL]];
 AFSecurityPolicy *policy = [AFSecurityPolicy policyWithPinningMode:AFSSLPinningModeCertificate];
 //Whether to allow certificates that CA does not trust to pass  
 policy.allowInvalidCertificates = YES;
 // Whether to verify the host name  
 policy.validatesDomainName = YES;
 _httpClient.securityPolicy = policy;

I have not created a demo here. If you want to see it, you can take a look at a framework I wrote, BGNetwork. The demo in it is adapted to ATS. The use of AFNetworking is placed in the - (instancetype)initWithBaseURL:(NSString *)baseURL delegate:(id)delegate initialization method in the BGNetworkConnector class.

5. Adapting ATS

The previous content describes the situation that meets the ATS characteristics, but if the server is built with a self-built certificate, or the TLS version is 1.0, and the server cannot be easily changed, how can our client adapt? Don't worry, we can set it in the Info.plist file in the project, mainly refer to the following figure:

If the certificate is self-built and not certified by an authority, you need to set NSAllowsArbitraryLoads to YES for it to pass. If NSAllowsArbitraryLoads is YES, previous HTTP requests can also pass.

If it is a certified certificate, you can use commands such as nscurl --ats-diagnostics --verbose https://casetree.cn to view the ATS Dictionary supported by the server and then make corresponding settings.

For the adaptation part, you can also refer to Demo1_iOS9 Network Adaptation_ATS: Use the more secure HTTPS