-
修改plist文件配置
项目中除了网络接口请求需要https验证,什么打开网页啊,加载图片这些都不需要。ATS,每个应用都属于4个大类当中的一类。我们需要的应该是第4类。
plist文件配置如下:
<key>NSAppTransportSecurity</key>
<dict>
<key>NSAllowsArbitraryLoads</key>
<true/>
<key>NSExceptionDomains</key>
<dict>
<key>接口请求域名</key>
<dict>
<key>NSExceptionAllowsInsecureHTTPLoads</key>
<false/>
</dict>
<key>接口请求域名</key>
<dict>
<key>NSExceptionAllowsInsecureHTTPLoads</key>
<false/>
</dict>
</dict>
</dict>
-
运行项目,通过Charles进行抓包(抓包工具Charles使用教程)
主要就是手机和Charles通过设置同样Wi-Fi对应的IP,手机进行HTTP手动代理设置。请求接口数据在Charles中显示的乱码,说明数据已加密成功,即https配置OK。然而并没有那么完美,有一个测试域名请求接口返回:
Error Domain=kCFErrorDomainCFNetwork Code=310 "(null)" UserInfo={_kCFStreamErrorCodeKey=-2096, _kCFStreamErrorDomainKey=4}
,小白看不懂,估计应该是和域名有一些关系吧,或者安全 web 代理服务器 (HTTPS) 通信时出现问题。客户端代码和配置检查了无数遍,应该是OK的。
小白继续认真看iOS9AdaptationTips,原来文档早已说明:服务端的小伙伴参考Apple提供官方指南App Transport Security Technote进行服务的升级配置以满足ATS的要求,一个符合 ATS 要求的 HTTPS,应该满足如下条件:
1、Transport Layer Security协议版本要求TLS1.2以上。
2、服务的Ciphers配置要求支持Forward Secrecy等。
3、证书签名算法符合ATS要求等。
于是马上和服务端沟通进行检查,果不其然,服务端升级IIS,默认是禁用TLS的,调整对TLS版本的支持,搞定。
-
HTTPS 证书典型的购买、部署流程
1、在 *UNIX 环境下使用 openssl 工具生成一对一匹配的 私钥 和 CERTIFICATE REQUEST 文件(以 —–BEGIN CERTIFICATE REQUEST—– 开头)。私钥为绝密,绝对不能泄露,最好在生产服务器直接生成,这样就不需要网络传输,更加安全。
2、将 CERTIFICATE REQUEST 文件提交到证书服务机构,服务机构根据证书级别进行 域名认证、公司认证、安全认证 等不同级别的安全验证。
3、验证通过后,服务机构将基于我们提交的 CERTIFICATE REQUEST 内容,使用他已有的证书派生出子证书,提供给我们下载。
4、我们拿到服务机构颁发的两个 crt 格式的证书(root 证书 及我们的域名证书),再配合本地的私钥,到 Apache、Nginx 等 web server 上部署,部署时会验证“私钥”是否和“域名证书”匹配。
5、用户在以 HTTPS 协议访问网站时,浏览器会进行如下几步安全验证:域名证书中的域名和实际域名是否一致;域名证书和 root 证书是否匹配;root 证书是否可信。
-
需要注意的点
1、在某些低安全级别证书申请中(如仅验证域名所有权的证书),私钥可以让签发服务器代为生成,但这样做有一定的安全风险。
2、root 证书也可以在我们本机生成,如 12306 的自签名证书,但这样不会被普通浏览器信任。
3、私钥为绝密,因为证书全部都是公开的,任何人都可以提取,如果私钥被别人获取,被部署到别人的服务器中,那所有人就会认为那台服务器是完全合法的。这已经不是中间人攻击了,这时候他就是你。
-
NSURLSession 对证书的验证
1、发现是 HTTPS 请求,取出证书。
2、进入证书处理流程:
2.1、本地证书分两种情况:① 本地存储着证书服务机构颁发的 crt 文件转换而来的 cer 文件,使用 NSData 进行内容对比 ② 本地存储着自签名的 cer 格式的证书,使用 NSData 进行内容对比
匹配成功,手动让请求继续,这一步可以让自签名证书绕过 iOS 系统的证书合法性验证
2.2、匹配失败,进入错误处理流程
2.3、如果自签名证书不做手动处理,那么在这个方法结束后链接就会被系统关闭,因为 root 证书不合法。