iOS https证书双向认证的实现机制

  • Post author:
  • Post category:其他




原理

双向认证,顾名思义,客户端和服务器端都需要验证对方的身份,在建立Https连接的过程中,握手的流程比单向认证多了几步。

单向认证的过程,客户端从服务器端下载服务器端公钥证书进行验证,然后建立安全通信通道。

双向通信流程,客户端除了需要从服务器端下载服务器的公钥证书进行验证外,还需要把客户端的公钥证书上传到服务器端给服务器端进行验证,等双方都认证通过了,才开始建立安全通信通道进行数据传输。



单向认证流程

单向认证流程中,服务器端保存着公钥证书和私钥两个文件,整个握手过程如下:

在这里插入图片描述

  1. 客户端发起建立HTTPS连接请求,将SSL协议版本的信息发送给服务器端;
  2. 服务器端将本机的公钥证书(server.crt)发送给客户端;
  3. 客户端读取公钥证书(server.crt),取出了服务端公钥;
  4. 客户端生成一个随机数(密钥R),用刚才得到的服务器公钥去加密这个随机数形成密文,发送给服务端;
  5. 服务端用自己的私钥(server.key)去解密这个密文,得到了密钥R
  6. 服务端和客户端在后续通讯过程中就使用这个密钥R进行通信了。



双向认证流程

在这里插入图片描述

  1. 客户端发起建立HTTPS连接请求,将SSL协议版本的信息发送给服务端;
  2. 服务器端将本机的公钥证书(server.crt)发送给客户端;
  3. 客户端读取公钥证书(server.crt),取出了服务端公钥;
  4. 客户端将客户端公钥证书(client.crt)发送给服务器端;
  5. 服务器端解密客户端公钥证书,拿到客户端公钥;
  6. 客户端发送自己支持的加密方案给服务器端;
  7. 服务器端根据自己和客户端的能力,选择一个双方都能接受的加密方案,使用客户端的公钥加密后发送给客户端;
  8. 客户端使用自己的私钥解密加密方案,生成一个随机数R,使用服务器公钥加密后传给服务器端;
  9. 服务端用自己的私钥去解密这个密文,得到了密钥R
  10. 服务端和客户端在后续通讯过程中就使用这个密钥R进行通信了。



证书生成

从上一章内容中,我们可以总结出来,如果要把整个双向认证的流程跑通,最终需要五个证书文件:

服务器端公钥证书:server.crt

服务器端私钥文件:server.key

客户端公钥证书:client.crt

客户端私钥文件:client.key

客户端集成证书(包括公钥和私钥,用于浏览器访问场景):client.p12

生成这一些列证书之前,我们需要先生成一个CA根证书,然后由这个CA根证书颁发服务器公钥证书和客户端公钥证书。

在这里插入图片描述

我们可以全程使用openssl来生成一些列的自签名证书,自签名证书没有听过证书机构的认证,很多浏览器会认为不安全,但我们用来实验是足够的。需要在本机安装了openssl后才能继续本章的实验。



生成自签名根证书

(1)创建根证书私钥:
openssl genrsa -out root.key 1024

(2)创建根证书请求文件:
openssl req -new -out root.csr -key root.key
后续参数请自行填写,下面是一个例子:
Country Name (2 letter code) [XX]:cn
State or Province Name (full name) []:bj
Locality Name (eg, city) [Default City]:bj
Organization Name (eg, company) [Default Company Ltd]:alibaba
Organizational Unit Name (eg, section) []:test
Common Name (eg, your name or your servers hostname) []:www.yourdomain.com
Email Address []:a.alibaba.com
A challenge password []:
An optional company name []:

(3)创建根证书:
openssl x509 -req -in root.csr -out root.crt -signkey root.key -CAcreateserial -days 3650

在创建证书请求文件的时候需要注意三点,下面生成服务器请求文件和客户端请求文件均要注意这三点:

Common Name填写证书对应的服务域名;

所有字段的填写,根证书、服务器端证书、客户端证书需保持一致

最后的密码可以直接回车跳过。

经过上面三个命令行,我们最终可以得到一个签名有效期为10年的根证书root.crt,后面我们可以用这个根证书去颁发服务器证书和客户端证书。



生成自签名服务器端证书

(1)生成服务器端证书私钥:
openssl genrsa -out server.key 1024

(2) 生成服务器证书请求文件,过程和注意事项参考根证书,本节不详述:
openssl req -new -out server.csr -key server.key

(3) 生成服务器端公钥证书
openssl x509 -req -in server.csr -out server.crt -signkey server.key -CA root.crt -CAkey root.key -CAcreateserial -days 3650

经过上面的三个命令,我们得到:

server.key:服务器端的秘钥文件

server.crt:有效期十年的服务器端公钥证书,使用根证书和服务器端私钥文件一起生成



生成自签名客户端证书

(1)生成客户端证书秘钥:
openssl genrsa -out client.key 1024

(2) 生成客户端证书请求文件,过程和注意事项参考根证书,本节不详述:
openssl req -new -out client.csr -key client.key

(3) 生客户端证书
openssl x509 -req -in client.csr -out client.crt -signkey client.key -CA root.crt -CAkey root.key -CAcreateserial -days 3650

(3) 生客户端p12格式证书
openssl pkcs12 -export -clcerts -in client.crt -inkey client.key -out client.p12

经过上面的三个命令,我们得到:

client.key:客户端的私钥文件

client.crt:有效期十年的客户端证书,使用根证书和客户端私钥一起生成

client.p12:客户端p12格式,这个证书文件包含客户端的公钥和私钥,主要用来给浏览器访问使用



AFNetworking对于证书的校验机制


AFNetworking解耦后可以分为以下几个模块:

  1. NSURLSession:主要的一个基于NSURLSession的管理模块;
  2. Reachability:网络监测模块;
  3. Security:Https验证模块;
  4. Serialization:序列化模块,包含了请求和响应的序列化;
  5. UIKit:包含了一些UI的扩展,方便调用。

AFNetworking关于https证书校验的逻辑,主要在源代码AFSecurityPolicy中实现。

AFNetworking提供了三个不同的认证模式,分别是:

typedef NS_ENUM(NSUInteger, AFSSLPinningMode) {
    AFSSLPinningModeNone,
    AFSSLPinningModePublicKey,
    AFSSLPinningModeCertificate,
};

  • AFSSLPinningModeNone

代表无条件信任服务器的证书,这个模式表示不做SSL pinning,只跟浏览器一样在系统的信任机构列表里验证服务端返回的证书。若证书是信任机构签发的就会通过,若是自己服务器生成的证书,这里是不会通过的。

核心校验相关代码

NSMutableArray *policies = [NSMutableArray array];
    if (self.validatesDomainName) {
        [policies addObject:(__bridge_transfer id)SecPolicyCreateSSL(true, (__bridge CFStringRef)domain)];
    } else {
        [policies addObject:(__bridge_transfer id)SecPolicyCreateBasicX509()];
    }
    SecTrustSetPolicies(serverTrust, (__bridge CFArrayRef)policies);
    if (self.SSLPinningMode == AFSSLPinningModeNone) 
    {
        return self.allowInvalidCertificates || AFServerTrustIsValid(serverTrust)
    }

核心代码主要是:

SecTrustSetPolicies(serverTrust, (__bridge CFArrayRef)policies);//设置校验的参考依据

AFServerTrustIsValid(serverTrust); //系统API,基于上述的参考依据,得到证书的最终校验结果。


  • AFSSLPinningModePublicKey模式

代表会对服务器返回的证书中的PublicKey进行验证,客户端要有服务端的证书拷贝,验证时只验证证书里的公钥,不验证证书的有效期等信息。只要公钥是正确的,就能保证通信不会被窃听,因为中间人没有私钥,无法解开通过公钥加密的数据。

1.客户端本地内置证书白名单。获取访问域名证书链上的每一级证书的公钥 校验公钥是否正确。

核心代码:

 //只验证公钥
 NSUInteger trustedPublicKeyCount = 0;
  // 从serverTrust中取出服务器端传过来的所有可用的证书,并依次得到相应的公钥
 NSArray *publicKeys = AFPublicKeyTrustChainForServerTrust(serverTrust);
 //遍历服务端公钥
  for (id trustChainPublicKey in publicKeys) 
  {
   for (id pinnedPublicKey in self.pinnedPublicKeys) 
   {
    if (AFSecKeyIsEqualToKey((__bridge SecKeyRef)trustChainPublicKey, (__bridge SecKeyRef)pinnedPublicKey))
     {
     //判断如果相同 trustedPublicKeyCount+1
           trustedPublicKeyCount += 1;
      }
     }
 }
  return trustedPublicKeyCount > 0;
  • AFSSLPinningModeCertificate模式。

代表会对服务器返回的证书同本地证书全部进行校验,需要客户端保存有服务端的证书拷贝,这里验证分两步,第一步验证证书的域名/有效期等信息,第二步是对比服务端返回的证书跟客户端返回的是否一致。

1.获取https证书链上的每一级证书,将各个 证书都作为校验的参考依据。(简单说就是会校验整个证书链)

核心代码:

 //全部校验(nsbundle .cer)
  NSMutableArray *pinnedCertificates = [NSMutableArray array];
//把证书data,用系统api转成 SecCertificateRef 类型的数据,SecCertificateCreateWithData函数对原先的pinnedCertificates做一些处理,保证返回的证书都是DER编码的X.509证书
for (NSData *certificateData in self.pinnedCertificates) {
    [pinnedCertificates addObject:(__bridge_transfer id)SecCertificateCreateWithData(NULL, (__bridge CFDataRef)certificateData)];
}
// 将pinnedCertificates设置成需要参与验证的Anchor Certificate(锚点证书,通过SecTrustSetAnchorCertificates设置了参与校验锚点证书之后,假如验证的数字证书是这个锚点证书的子节点,即验证的数字证书是由锚点证书对应CA或子CA签发的,或是该证书本身,则信任该证书),具体就是调用SecTrustEvaluate来验证
            //serverTrust是服务器来的验证,有需要被验证的证书
            // 把本地证书设置为根证书,
 SecTrustSetAnchorCertificates(serverTrust, (__bridge CFArrayRef)pinnedCertificates);
//再去验证证书
  if (!AFServerTrustIsValid(serverTrust)) 
  {
   return NO;
  }
 //注意,这个方法和我们之前的锚点证书没关系了,是去从我们需要被验证的服务端证书,去拿证书链。
 // 服务器端的证书链,注意此处返回的证书链顺序是从叶节点到根节点
  // 所有服务器返回的证书信息
   NSArray *serverCertificates = AFCertificateTrustChainForServerTrust(serverTrust);
  for (NSData *trustChainCertificate in [serverCertificates reverseObjectEnumerator]) 
  {
  //如果我们的证书中,有一个和它证书链中的证书匹配的,就返回YES
  // 是否本地包含相同的data
  if ([self.pinnedCertificates containsObject:trustChainCertificate]) 
  {
  return YES;
   }
   }
   return NO;

SecTrustSetAnchorCertificates(serverTrust, (__bridge CFArrayRef)pinnedCertificates); //增加了新的校验维度,客户端本地证书白名单

2.要求客户端本地的内置证书白名单里至少包含一个证书链里的证书。

 NSArray *serverCertificates = AFCertificateTrustChainForServerTrust(serverTrust);            
  
            NSUInteger trustedCertificateCount = 0;
            for (NSData *trustChainCertificate in serverCertificates) {
                if ([self.pinnedCertificates containsObject:trustChainCertificate]) {
                    trustedCertificateCount++;
                }
            }
            return trustedCertificateCount > 0;

NSArray *serverCertificates = AFCertificateTrustChainForServerTrust(serverTrust); //得到访问域名的证书链上的各个证书信息

AFSSLPinningModeCertificate对应的则是证书锁定


AFSSLPinningModeCertificate缺点

客户端内置证书有有效期,证书有效期过后,需要强制升级客户端

发行APP比较麻烦,每次证书需要打包在APP中,服务器证书到期后则要重新内置证书后打包发行



版权声明:本文为Z1591090原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。