·背景
公司APP项目忽略了服务端证书校验漏洞，导致攻击者可以通过伪造证书等手段进行攻击获取。因此需要进行证书校验来解决该漏洞带来的风险。
·一次完整的HTTP请求过程
域名解析 -> 发起TCP的三次握手(去看看)-> 建立TCP连接后发起HTTP请求 -> 服务器响应HTTP请求
下图通过抓包可以查看连接过程：
image
·域名解析（DNS劫持）
DNS域名解析过程：https://blog.csdn.net/u010555682/article/details/52127451
在解析域名过程中需要经过localDNS服务器，就在这个过程中有可能会被黑客攻击、甚至服务商在其中做手脚，甚至使用伪造的服务器导致DNS域名解析后的结果并不是我们想要的内容。这种情况就是DNS域名劫持。
下图为DNS劫持流程：
image
那么如何解决DNS劫持？
1、 不用运营商的DNS解析而使用自己可信的解析服务器。
2、提前在自己的APP中将解析好的域名以IP的形式发出去从而绕过运营商的DNS解析来达到避免DNS解析的问题。（IP直连）
·HTTPS连接
HTTP协议传输的数据都是未加密的，也就是明文传输，因此HTTP协议传输隐私信息非常的不安全。为了保证隐私数据能够加密传输，设计了SSL（Secure Sockets Layer）协议用于对HTTP协议传输的数据进行加密，从而诞生了HTTPS。
HTTPS建立连接过程示意图：（来源：https://www.cnblogs.com/softidea/p/6958394.html）
image
·HTTPS IP直连
为了避免上文中讲到的DNS被劫持的情况，我们将在请求的时候讲URL中的HOST中的域名替换为后台下发IP进行访问（即IP直连）。IP直连相对于域名访问的好处：
1、省去DNS解析这一步骤，减少耗时
2、避免DNS劫持；
3、当终端有多个IP接入选择时，有一定容灾能力；
但是，HTTPS IP直连也存在着问题：
1、证书HOST校验问题；
2、SNI问题；
·证书HOST校验问题
终端在SSL握手过程会校验当前请求URL的HOST是否在服务端证书的可选域名列表里。
比如想要请求https://a.html5.qq.com,使用IP直连接后实际请求的URL为：https://183.21.152.52:443此时服务端返回的证书可选域名列表如下：
image
由于请求的HOST域名被替换成IP，导致底层在进行证书验证的时候验证失败。
解决办法：将请求的HOST文件中的IP替换回请求的域名
image
下图通过抓包查看不将HOST中的IP换成域名和换成域名情况分别返回的证书：
image
image
·SNI问题
解决了上述问题后，理论上就可以进行IP直连。但是还会有存在：一个IP转发层部署了多个域名的证书（SNI情况）。而终端使用IP直连时，服务端SSL握手阶段会获取到域名调度后的IP，服务端无法找到匹配证书时，只能返回默认的证书或者不返回，没有可匹配的证书，导致校验失败。
解决方案-阿里云HTTPS SNI“IP直连”方案
SNI（单IP多HTTPS证书）场景下，ios上层网络库NSURLConnection/NSURLSession没有提供接口进行SNI字段配置，因此需要Socket层级的网络库（CFNetwork）来实现IP直连网络请求适配方案。
针对SNI场景的方案，Socket层级的网络库方案：
·基于CFNetwork , hook证书校验步骤
·基于原生支持设置SNI字段的更底层的库（如libcurl库）;
实现：
1、筛选需要被拦截的网络请求
/**
* 是否拦截处理指定的请求
*
* @param request 指定的请求
* @return 返回YES表示要拦截处理，返回NO表示不拦截处理
*/
+ (BOOL)canInitWithRequest:(NSURLRequest *)request {
/* 防止无限循环，因为一个请求在被拦截处理过程中，也会发起一个请求，这样又会走到这里，如果不进行处理，就会造成无限循环 */
if ([NSURLProtocol propertyForKey:protocolKey inRequest:request]) {
return NO;
}
NSString *url = request.URL.absoluteString;
// 如果url以https开头，则进行拦截处理，否则不处理
if ([url hasPrefix:@"https"]) {
return YES;
}
return NO;
}
2、对需要拦截的请求重新构造
+ (NSURLRequest *)canonicalRequestForRequest:(NSURLRequest *)request {
return [request httpdns_getPostRequestIncludeBody];
}
测试过程中遇到使用GET请求能够正常拉去数据，但是使用POST请求拉取失败的问题。 经过测试发现使用NSURLProtocol拦截NSURLSession请求会丢失body.解决办法是使用HTTPBodyStream获取body，再赋值到body中：
- (NSMutableURLRequest *)httpdns_getMutablePostRequestIncludeBody{
NSMutableURLRequest * req = [self mutableCopy];
if ([self.HTTPMethod isEqualToString:@"POST"]) {
if (!self.HTTPBody) {
uint8_t d[1024] = {0};
NSInputStream *stream = self.HTTPBodyStream;
NSMutableData *data = [[NSMutableData alloc] init];
[stream open];
//warning 不能用 [stream hasBytesAvailable]) 判断，处理图片文件的时候这里的[stream hasBytesAvailable]会始终返回YES，导致在while里面死循环。
BOOL endOfStream = NO;
while (!endOfStream) {//[stream hasBytesAvailable]
NSInteger len = [stream read:d maxLength:1024];
if (len == 0) {//文件读取到最后
endOfStream = YES;
}else if (len == -1){
endOfStream = YES;
}else if (stream.streamError == nil){
[data appendBytes:(void *)d length:len];
}
}
req.HTTPBody = [data copy];
NSString *str = [[NSString alloc] initWithData:data encoding:NSUTF8StringEncoding];
[stream close];
}
}
return req;
}
3、将用于拦截请求的NSURLProtocol的子类添加到
NSURLSessionConfiguration * sessionConfiguration = [NSURLSessionConfiguration defaultSessionConfiguration];
//add
NSArray *protocolArray = @[ [CFHttpMessageURLProtocol class] ];
sessionConfiguration.protocolClasses = protocolArray;
遇到问题：
转发请求内部使用了Core Foundation,就需要涉及到Foundation和Core Foundation之间的转化。系统在ARC状态下编译器不能自动管理CF的内存，必须手动使用CFRetain和CFRelease来进行CF的内存管理。
过程由于没有使用好 __bridge_retained 和 CFRelease()导致出现内存泄漏。
image.png
在Objective-C 和 Core Foundation-style 对象之间进行转换，你必须通过以下宏来告诉编译器对象的持有者:
__bridge : 转换Objective-C 和 Core Foundation 指针，不移交持有权. 作用于外对象已经释放掉，作用于外再访问该对象就会崩溃
__bridge_retained : 转换 Objective-C 指针到Core Foundation 指针并移交持有权.
你要负责调用 CFRelease 或一个相关的函数来释放对象.
__bridge_transfer : 传递一个非Objective-C 指针到 Objective-C 指针并移交持有权给ARC , ARC负责释放对象.
网友评论