https笔记

HTTPS就是将HTTP协议数据包放到SSL/TSL层加密后，在TCP/IP层组成IP数据报去传输，以此保证传输数据的安全。
证书分为两种，一种是花钱向CA（证书认证的机构）购买的证书，服务端如果使用的是这类证书的话，那一般客户端不需要做什么，用HTTPS进行请求就行了，苹果内置了那些受信任的根证书的。另一种是自己制作的证书，使用这类证书的话是不受信任的（当然也不用花钱买），因此需要我们在代码中将该证书设置为信任证书。
对于一般的小型网站尤其是博客，可以使用自签名证书来构建安全网络，所谓自签名证书，就是自己扮演 CA 机构，自己给自己的服务器颁发证书。

SSL协议的握手过程：（参考）

bg2014092004.png

SSL/TSl握手阶段的详细过程

• 首先，客户端（通常是浏览器）先向服务器发出加密通信的请求，这被叫做ClientHello请求。
  在这一步，客户端主要向服务器提供以下信息。
  （1） 支持的协议版本，比如TLS 1.0版。
  （2） 一个客户端生成的随机数，稍后用于生成"对话密钥"。
  （3） 支持的加密方法，比如RSA公钥加密。
  （4） 支持的压缩方法。
• 服务器收到客户端请求后，向客户端发出回应，这叫做SeverHello。服务器的回应包含以下内容。
  （1） 确认使用的加密通信协议版本，比如TLS 1.0版本。如果浏览器与服务器支持的版本不一致，服务器关闭加密通信。
  （2） 一个服务器生成的随机数，稍后用于生成"对话密钥"。
  （3） 确认使用的加密方法，比如RSA公钥加密。
  （4） 服务器证书。
• 客户端收到服务器回应以后，首先验证服务器证书。如果证书不是可信机构颁布、或者证书中的域名与实际域名不一致、或者证书已经过期，就会向访问者显示一个警告，由其选择是否还要继续通信。
  如果证书没有问题，客户端就会从证书中取出服务器的公钥。然后，向服务器发送下面三项信息：
  （1） 一个随机数。该随机数用服务器公钥加密，防止被窃听。
  （2） 编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送。
  （3） 客户端握手结束通知，表示客户端的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，用来供服务器校验。
  上面第一项的随机数，是整个握手阶段出现的第三个随机数，又称"pre-master key"。有了它以后，客户端和服务器就同时有了三个随机数，接着双方就用事先商定的加密方法，各自生成本次会话所用的同一把"会话密钥"。
• 服务器收到客户端的第三个随机数pre-master key之后，计算生成本次会话所用的"会话密钥"。然后，向客户端最后发送下面信息。
  （1）编码改变通知，表示随后的信息都将用双方商定的加密方法和密钥发送。
  （2）服务器握手结束通知，表示服务器的握手阶段已经结束。这一项同时也是前面发送的所有内容的hash值，用来供客户端校验。
  至此，整个握手阶段全部结束。接下来，客户端与服务器进入加密通信，就完全是使用普通的HTTP协议，只不过用"会话密钥"加密内容。

证书

证书的申请过程

• 证书申请者向颁发证书的可信第三方CA提交申请证书相关信息，包括：申请者域名、申请者生成的公钥(私钥自己保存)及证书请求文件.cer等
• CA通过线上、线下等多种手段验证证书申请者提供的信息合法和真实性。
• 当证书申请者提供的信息审核通过后，CA向证书申请者颁发证书，证书内容包括明文信息和签名信息。其中明文信息包括证书颁发机构、证书有效期、域名、申请者相关信息及申请者公钥等，签名信息是使用CA私钥进行加密的明文信息。当证书申请者获取到证书后，可以通过安装的CA证书中的公钥对签名信息进行解密并与明文信息进行对比来验证签名的完整性。

证书的验证过程

TSL/SSL的握手过程里client会拿到server返回的证书并且验证证书本身的合法性（验证签名完整性，验证证书有效期等）

• 验证证书颁发者的合法性（查找颁发者的证书并检查其合法性，这个过程是递归的）
• 证书验证的递归过程最终会成功终止，而成功终止的条件是：证书验证过程中遇到了锚点证书，锚点证书通常指：嵌入到操作系统中的根证书(权威证书颁发机构颁发的自签名证书)。

证书验证失败的原因

• 无法找到证书的颁发者
• 证书过期
• 验证过程中遇到了自签名证书，但该证书不是锚点证书。
• 无法找到锚点证书(即在证书链的顶端没有找到合法的根证书)
• 访问的server的dns地址和证书中的地址不同

iOS实现支持HTTPS

在OC中当使用NSURLConnection或NSURLSession建立URL并向服务器发送https请求获取资源时，服务器会使用HTTP状态码401进行响应(即访问拒绝)。此时NSURLConnection或NSURLSession会接收到服务器需要授权的响应，当客户端授权通过后，才能继续从服务器获取数据。如下图所示：

image.png

非自签名证书验证实现

当客户端发送https请求后，服务器会返回需要授权的相关信息，对于NSURLSession而言,，需要代理对象实现URLSession:task:didReceiveChallenge:completionHandler:方法。

- (void)URLSession:(NSURLSession *)session didReceiveChallenge:(NSURLAuthenticationChallenge *)challenge completionHandler:(void (^)(NSURLSessionAuthChallengeDisposition, NSURLCredential * _Nullable))completionHandler {
    
    NSURLSessionAuthChallengeDisposition disposition = NSURLSessionAuthChallengePerformDefaultHandling;
    NSURLCredential *credential = nil;
    
    SecTrustRef trust = challenge.protectionSpace.serverTrust;
    SecTrustResultType result;
    OSStatus status = SecTrustEvaluate(trust, &result);
    if (status == kSecTrustResultUnspecified || status == kSecTrustResultProceed) {
        credential = [NSURLCredential credentialForTrust:trust];
        if (credential) {
             disposition = NSURLSessionAuthChallengeUseCredential;
        }
    }
    completionHandler(disposition, credential);
}

• NSURLSessionAuthChallengePerformDefaultHandling处理请求，就好像代理没有提供一个代理方法来处理认证请求
• NSURLSessionAuthChallengeRejectProtectionSpace拒接认证请求。基于服务器响应的认证类型，URL加载类可能会多次调用代理方法。

SecTrustRef

表示需要验证的信任对象(Trust Object)，在此指的是challenge.protectionSpace.serverTrust。包含待验证的证书和支持的验证方法等。

SecTrustResultType

表示验证结果。其中 kSecTrustResultProceed表示serverTrust验证成功，且该验证得到了用户认可(例如在弹出的是否信任的alert框中选择always trust)。 kSecTrustResultUnspecified表示 serverTrust验证成功，此证书也被暗中信任了，但是用户并没有显示地决定信任该证书。 两者取其一就可以认为对serverTrust验证成功。

SecTrustEvaluate

函数内部递归地从叶节点证书到根证书验证。使用系统默认的验证方式验证Trust Object，根据上述证书链的验证可知，系统会根据Trust Object的验证策略，一级一级往上，验证证书链上每一级证书有效性。

对于非自签名的证书，即使服务器返回的证书是信任的CA颁发的，假如有更强的安全要求，可以继续对Trust Object进行更严格的验证。常用的方式是在本地导入证书，并将导入的证书设置成需要参与验证的锚点证书，再调用SecTrustEvaluate通过本地导入的证书来验证服务器证书是否是可信的。如果服务器证书是这个锚点证书对应CA或者子CA颁发的，或服务器证书本身就是这个锚点证书，则证书信任通过。如下代码：

NSString *cerPath = ...;//证书在本次的路径
NSData *cerData = [NSData dataWithContentsOfFile:cerPath];
SecCertificateRef certificate = SecCertificateCreateWithData(NULL, (__bridge CFDataRef)cerPath);
self.trustedCertificates = @[CFBridgingRelease(certificate)];

- (void)URLSession:(NSURLSession *)session didReceiveChallenge:(NSURLAuthenticationChallenge *)challenge completionHandler:(void (^)(NSURLSessionAuthChallengeDisposition, NSURLCredential * _Nullable))completionHandler {
    NSURLSessionAuthChallengeDisposition disposition = NSURLSessionAuthChallengePerformDefaultHandling;
    NSURLCredential *credential = nil;
    SecTrustRef trust = challenge.protectionSpace.serverTrust;
    SecTrustResultType result;
    
    //将之前导入的证书设置成下面验证的Trust Object的锚点证书
    SecTrustSetAnchorCertificates(trust, (__bridge CFArrayRef)self.trustedCertificates);
    //通过本地导入的证书来验证服务器返回的证书是否可信
    OSStatus status = SecTrustEvaluate(trust, &result);
    if (status == kSecTrustResultUnspecified || status == kSecTrustResultProceed) {
        credential = [NSURLCredential credentialForTrust:trust];
        if (credential) {
            disposition = NSURLSessionAuthChallengeUseCredential;
        }
    }
    
    completionHandler(disposition, credential);
}

自签名证书

对于自签名证书，这样Trust Object中的服务器证书是不可信任的CA颁发的，直接使用SecTrustEvaluate验证是不会成功的。
可以采取下述简单代码绕过HTTPS的验证：

[challenge.sender useCredential:[NSURLCredential credentialForTrust:challenge.protectionSpace.serverTrust] forAuthenticationChallenge:challenge];
 [challenge.sender continueWithoutCredentialForAuthenticationChallenge:challenge];

综上对非自建和自建证书验证过程的分析，可以总结如下：

• 获取需要验证的信任对象(Trust Object)。对于NSURLSession来说，
  是从delegate方法URLSession:task:didReceiveChallenge:completionHandler:回调回来的参数challenge中获取(challenge.protectionSpace.serverTrust) 。
  使用系统默认验证方式验证Trust Object。
• SecTrustEvaluate会根据Trust Object的验证策略，一级一级往上，验证证书链上每一级数字签名的有效性，从而评估证书的有效性。
• 如第二步验证通过了，一般的安全要求下，就可以直接验证通过，进入到下一步：使用Trust Object生成一份凭证([NSURLCredential credentialForTrust:serverTrust])，传入block中 completionHandler(disposition, credential)处理，建立连接。
• 假如有更强的安全要求，可以继续对Trust Object进行更严格的验证。常用的方式是在本地导入证书，验证Trust Object与导入的证书是否匹配。
• 假如验证失败，取消此次Challenge-Response Authentication验证流程，拒绝连接请求。
• 假如是自建证书的，则不使用第二步系统默认的验证方式，因为自建证书的根CA的数字签名未在操作系统的信任列表中。

在AFNetwoking的AFURLSessionManager.m这个文件里实现了代理方法URLSession:task:didReceiveChallenge:completionHandler:并且在代理方法里对服务器返回的证书做了验证。验证的方法是evaluateServerTrust:forDomain:(NSString *)domain。
AFNetwoking提供了一个类AFSecurityPolicy,它有一个属性：

typedef NS_ENUM(NSUInteger, AFSSLPinningMode) {
    AFSSLPinningModeNone,
    AFSSLPinningModePublicKey,
    AFSSLPinningModeCertificate,
};
@property (readonly, nonatomic, assign) AFSSLPinningMode SSLPinningMode;

这个枚举值决定了按哪种方式来验证服务器返回的证书。默认值是AFSSLPinningModeNone。

• AFSSLPinningModeNone：这会通过SecTrustEvaluate来验证服务器返回的证书，对于CA认证的证书可以选用这个值；
• AFSSLPinningModeCertificate：如果使用了CA认证的证书，并且在本地也导入了证书作为锚点证书来验证服务器返回的证书，可以用这个值。