iOS HTTPS适配

快速适配直接看下面的示例代码吧,概念有点多。。。

自己客户端生成证书放在服务器上,可以自签
服务器必须ca签署,服务器生成,提供给我们

SSL/TLS协议运行机制概述
图解SSL/TLS协议

一、单向认证

HTTPS在建立Socket连接之前,需要进行握手。
1.客户端向服务器端发送SSL协议版本号、加密算法种类、随机数等信息。
2.服务端给客户端返回SSL协议版本号、加密算法种类、随机数等信息,同时也返回服务器端的证书,即公钥证书。
3.客户端使用服务端返回的信息验证服务器的合法性,包括

  • 证书是否过期
  • 发行服务器证书的CA是否可靠
  • 返回的公钥是否能正确解开返回证书中的数字签名
  • 服务器证书上的域名是否和服务器的实际域名相匹配
    验证通过后,将继续进行通信,否则,终止通信

4.客户端向服务端发送自己所能支持的对称加密方案,供服务器端进行选择。
5.服务器端在客户端提供的加密方案中选择加密程度最高的加密方式。
6.服务器将选择好的加密方案通过明文方式返回给客户端。
7.客户端接收到服务器端返回的加密方式后,使用该加密方式生成产生随机码,用作通信过程中对称加密的秘钥,使用服务器端返回的公钥进行加密,将加密后的随机码发送至服务器。
8.服务器收到客户端返回的加密信息后,使用自己的私钥进行解密,获取对称加密秘钥。
9.在接下来的会话中,服务器和客户端将会使用该密码进行对称加密,保证通信过程中信息的安全。
单向认证:保证server是真的,通道是安全的(对称密钥);
双向认证:保证client和server是真的,通道是安全的(对称密钥);

二、双向认证

为了便于更好的认识和理解SSL协议,这里着重介绍SSL协议的握手协议。SSL协议既用到了公钥加密技术又用到了对称加密技术,对称加密技术虽然比公钥加密技术的速度快,可是公钥加密技术提供了更好的身份认证技术。SSL的握手协议非常有效的让客户和服务器之间完成相互之间的身份认证。
1.客户的浏览器向服务器传递客户端SSL协议的版本号,加密算法的种类,产生的随机数,以及其他服务器和客户端之间通讯所需要的各种信息。
2.服务器向客户端传送SSL协议的版本号,加密算法的种类,随机数以及其他相关信息,同时服务器还将向客户端传送自己的证书。
3.客户利用服务器传过来的信息验证服务器的合法性,服务器的合法性包括

  • 证书是否过期
  • 发行服务器证书的CA是否可靠
  • 发行者证书的公钥能否正确解开服务器证书的“发行者的数字签名”
  • 服务器证书上的域名是否和服务器的实际域名相匹配

如果合法性验证没有通过,通讯将断开,如果合法性验证通过,将继续进行第四步。

4.用户端随机产生一个用于后面通讯的“对称密码”,然后用服务器的公钥(服务器的公钥从步骤2终端服务器的证书中获得)对其加密,然后将加密后的“预主密码”传给服务器。
5.如果服务器要求客户的身份认证(在握手过程中为可选),用户可以建立一个随机数然后对其进行数据签名,将这个含有签名的随机数和客户自己的证书以及加密过的“预主密码”一起传给服务器。
6.如果服务器要求客户的身份认证,服务器必须检验客户证书和签名随机数的合法性,具体的合法性验证过程包括:

  • 客户的证书使用日期是否有效
  • 为客户提供证书的CA是否可靠
  • 发行CA的公钥能否正确解开客户证书的发行CA的数字签名
  • 检查客户的证书是否在证书废止列表(CRL)中。

检验如果没有通过,通讯立刻中断;如果验证通过,服务器将用自己的私钥解开加密的“预主密码”,然后执行一系列步骤来产生主通讯密码(客户端也将通过同样的方法产生相同的主通讯密码)。
7.服务器和客户端用相同的主密码即“通话密码”,一个对称密钥用于SSL协议的安全数据通讯的加解密通讯。同时在SSL通讯过程中还要完成数据通讯的完整性,防止数据通讯中的任何变化。
8.客户端向服务器端发出信息,指明后面的数据通讯将使用步骤7中的主密码为对称密钥,同时通知服务器客户端的握手过程结束。
9.服务器向客户端发出信息,指明后面的数据通讯将使用的步骤7中的主密码为对称密钥,同时通知客户端服务器端的握手过程结束。
10.SSL的握手部分结束,SSL安全通道的数据通讯开始,客户和服务器开始使用相同的对称密钥进行数据通讯,同时进行通讯完整性的检验。

双向认证SSL协议的具体过程

1.浏览器发送一个连接请求给安全服务器。
2.服务器将自己的证书,以及同证书相关的信息发送给客户浏览器。
3.客户浏览器检查服务器送过来的证书是否是由自己信赖的CA中心所签发的。如果是,就继续执行协议;如果不是,客户浏览器就给客户一个警告消息:警告客户这个证书不是可信赖的,询问客户是否需要继续。
4.接着客户浏览器比较证书里的消息,例如域名和公钥,与服务器刚刚发送的相关消息是否一致,如果是一致的,客户浏览器认可这个服务器合法身份。
5.服务器要求客户发送客户自己的证书。收到后,服务器验证客户的证书,如果没有通过验证,拒绝连接;如果通过验证,服务器获得用户的公钥。
6.客户浏览器告诉服务器自己所能够支持的通讯对称密码方案。
7.服务器从客户发送过来的密码方案中,选择一种加密程度最高的密码方案,用客户的公钥加过密后通知浏览器。
8.浏览器针对这个密码方案,选择一个通话密钥,接着用服务器的公钥加过密后发送给服务器。
9.服务器接收到浏览器送过来的消息,用自己的私钥解密,获得通话密钥。
10.服务器、浏览器接下来的通讯都是用对称密码方案,对称密钥是加过密的。

上面所述的是双向认证 SSL 协议的具体通讯过程,这种情况要求服务器和用户双方都有证书。单向认证 SSL 协议不需要客户拥有 CA 证书,具体的过程相对于上面的步骤,只需将服务器端验证客户证书的过程去掉,以及在协商对称密码方案,对称通话密钥时,服务器发送给客户的是没有加过密的 (这并不影响 SSL 过程的安全性)密码方案。 这样,双方具体的通讯内容,就是加过密的数据,如果有第三方攻击,获得的只是加密的数据,第三方要获得有用的信息,就需要对加密的数据进行解密,这时候的 安全就依赖于密码方案的安全。而幸运的是,目前所用的密码方案,只要通讯密钥长度足够的长,就足够的安全。这也是我们强调要求使用 128 位加密通讯的原因。

双向认证和单向认证原理基本差不多,只是除了客户端需要认证服务端以外,增加了服务器端对客户端的认证。

单向认证只要求站点部署了SSL证书就行,任何用户都可以去访问(IP被限制除外等),只是服务器端提供了身份认证。而双向认证则是需要服务端需要客户端提供身份认证,只能是服务端允许的客户能去访问,安全性相对要高一些。

一般Web应用都是采用单向认证的,原因很简单,用户数目广泛,且无需做在通讯层做用户身份验证,一般都在应用逻辑成来保护用户的合法登入。但如果是企业对应对接,情况就不一样,可能会要求对客户端做身份验证。这时就需要做双向认证。

与单向认证的区别就是产生的是二分之一的对称密钥。
即对称密钥是client与server各自产生一半。

随意画了画,大家别按我这个来

HTTPS = HTTP + SSL/TLS + TCP

TLS 是SSL新的别称
也就是说 TLS 1.0 = SSL 3.1

常用的是下面这些

SSL 2.0
SSL 3.0
TLS 1.0 (SSL 3.1)
TLS 1.1 (SSL 3.1)
TLS 1.2 (SSL 3.1)

使用明文传播,带来了三大风险

窃听风险(eavesdropping):第三方可以获知通信内容。
篡改风险(tampering):第三方可以修改通信内容。
冒充风险(pretending):第三方可以冒充他人身份参与通信。

SSL/TLS协议是为了解决这三大风险而设计的,希望达到:

所有信息都是加密传播,第三方无法窃听。
具有校验机制,一旦被篡改,通信双方会立刻发现。
配备身份证书,防止身份被冒充。

苹果ATS安全设置的要求
ATS默认的安全要求:

  • 服务器必须支持传输层安全(TLS)协议1.2以上版本;
  • 通讯加密套件仅限支持完全正向加密的套件;
  • 证书必须使用SHA256或更高的哈希算法签名;以及2048位以上RSA密钥或256位以上ECC密钥。

不满足以上条件,ATS会拒绝连接。

方案一:让公司的服务端升级使用TLS 1.2

方案二:虽Apple不建议,但可通过在 Info.plist 中声明,倒退回不安全的网络请求依然能让App访问指定http,甚至任意的http。

一、准备工作

申请一个SSL证书

申请免费SSL证书教程

SSL证书按验证的类别可分:

DV SSL证书(域名验证型):只验证域名所有权,适合个人网站、博客等站点使用;

OV SSL证书(企业验证型):验证网站所属单位身份,适合企业级用户使用;

EV SSL证书(扩展验证型):扩展验证网站所属单位身份,这种证书在浏览器中会显示醒目的绿色地址栏,可信度最高,适合需要用户高度信任的企业级用户使用。

.crt文件转成.cer文件

二、AFNetworking适配

注:AFNetworking 3.0以上

首先向后台拿到证书(jks格式/Mac:.cer格式) ,或者你可以打开请求的完整链接 在Mac上下载该证书 (导入Xcode工程)

可以去腾讯云申请免费的SSL证书

检测接口是否满足苹果的ATS要求,有以下两种方法:
1.腾讯云提供的检测页面检测
https://www.qcloud.com/product/tools
2.终端输入 nsurl --ats-diagnostics --verbose 你的接口地址

关于iOS9中的ATS相关说明及适配

在info.plist删掉或改为NO
单向认证示例代码
+ (AFSecurityPolicy *)customSecurityPolicy
{
    // 先导入证书,在这加证书,一般情况适用于单项认证
    // 证书的路径
    NSString *cerPath = [[NSBundle mainBundle] pathForResource:@"xxx" ofType:@"cer"];
    
    NSData *cerData = [NSData dataWithContentsOfFile:cerPath];
    
    if (cerData == nil) {
        return nil;
    }
    NSSet *setData = [NSSet setWithObject:cerData];
    //AFSSLPinningModeCertificate 使用证书验证模式
    AFSecurityPolicy *securityPolicy = [AFSecurityPolicy policyWithPinningMode:AFSSLPinningModeCertificate];
    
    // allowInvalidCertificates 是否允许无效证书(也就是自建的证书),默认为NO
    // 如果是需要验证自建证书,需要设置为YES
    securityPolicy.allowInvalidCertificates = YES;
    
    // validatesDomainName 是否需要验证域名,默认为YES;
    // 假如证书的域名与你请求的域名不一致,需要把该项设置为NO;如设成NO的话,即服务器使用其他可信任机构颁发的证书,也可以建立连接,这个非常危险,建议打开。
    // 设置为NO,主要用于这种情况:客户端请求的事子域名,而证书上的是另外一个域名。因为SSL证书上的域名是独立的,假如证书上注册的域名是www.google.com,那么mail.google.com是无法验证通过的;当然有钱可以注册通配符的域名*.google.com,但这个还是比较贵的。
    // 如设置为NO,建议自己添加对应域名的校验逻辑。
    securityPolicy.validatesDomainName = NO;
    
    [securityPolicy setPinnedCertificates:setData];

    return securityPolicy;
}

然后在相应位置加入

[manager setSecurityPolicy:[self customSecurityPolicy]];

AFNetworking定义了三种SSLpinningmode:
AFSSLPinningModeNone: 代表客户端无条件地信任服务器端返回的证书

AFSSLPinningModePublicKey : 代表客户端会将服务器端返回的证书与本地保存的证书PublicKey的部分进行校验;如果正确,才继续进行。

AFSSLPinningModeCertificate: 代表客户端会将服务器端返回的证书和本地保存的证书中的所有内容,包括PublicKey和证书部分,全部进行校验;如果正确,才继续进行。

双向认证示例代码

http://blog.csdn.net/guobing19871024/article/details/53841373
http://blog.csdn.net/jerryvon/article/details/8548802

//校验证书
+ (void)checkCredential:(AFURLSessionManager *)manager
{
    [manager setSessionDidBecomeInvalidBlock:^(NSURLSession * _Nonnull session, NSError * _Nonnull error) {
    }];
    __weak typeof(manager)weakManager = manager;
    [manager setSessionDidReceiveAuthenticationChallengeBlock:^NSURLSessionAuthChallengeDisposition(NSURLSession*session, NSURLAuthenticationChallenge *challenge, NSURLCredential *__autoreleasing*_credential) {
        NSURLSessionAuthChallengeDisposition disposition = NSURLSessionAuthChallengePerformDefaultHandling;
        __autoreleasing NSURLCredential *credential =nil;
        NSLog(@"authenticationMethod=%@",challenge.protectionSpace.authenticationMethod);
        //判断是核验客户端证书还是服务器证书
        if([challenge.protectionSpace.authenticationMethod isEqualToString:NSURLAuthenticationMethodServerTrust]) {
            // 基于客户端的安全策略来决定是否信任该服务器,不信任的话,也就没必要响应挑战
            if([weakManager.securityPolicy evaluateServerTrust:challenge.protectionSpace.serverTrust forDomain:challenge.protectionSpace.host]) {
                // 创建挑战证书(注:挑战方式为UseCredential和PerformDefaultHandling都需要新建挑战证书)
                NSLog(@"serverTrust=%@",challenge.protectionSpace.serverTrust);
                credential = [NSURLCredential credentialForTrust:challenge.protectionSpace.serverTrust];
                // 确定挑战的方式
                if (credential) {
                    //证书挑战  设计policy,none,则跑到这里
                    disposition = NSURLSessionAuthChallengeUseCredential;
                } else {
                    disposition = NSURLSessionAuthChallengePerformDefaultHandling;
                }
            } else {
                disposition = NSURLSessionAuthChallengeCancelAuthenticationChallenge;
            }
        } else {
            // client authentication
            SecIdentityRef identity = NULL;
            SecTrustRef trust = NULL;
            NSString *p12 = [[NSBundle mainBundle] pathForResource:@"xxx"ofType:@"p12"];
            NSFileManager *fileManager =[NSFileManager defaultManager];
            
            if(![fileManager fileExistsAtPath:p12])
            {
                NSLog(@"client.p12:not exist");
            }
            else
            {
                NSData *PKCS12Data = [NSData dataWithContentsOfFile:p12];
                
                if ([self extractIdentity:&identity andTrust:&trust fromPKCS12Data:PKCS12Data])
                {
                    SecCertificateRef certificate = NULL;
                    SecIdentityCopyCertificate(identity, &certificate);
                    const void*certs[] = {certificate};
                    CFArrayRef certArray =CFArrayCreate(kCFAllocatorDefault, certs,1,NULL);
                    credential =[NSURLCredential credentialWithIdentity:identity certificates:(__bridge  NSArray*)certArray persistence:NSURLCredentialPersistencePermanent];
                    disposition =NSURLSessionAuthChallengeUseCredential;
                }
            }
        }
        *_credential = credential;
        return disposition;
    }];
}

//读取p12文件中的密码
+ (BOOL)extractIdentity:(SecIdentityRef*)outIdentity andTrust:(SecTrustRef *)outTrust fromPKCS12Data:(NSData *)inPKCS12Data {
    OSStatus securityError = errSecSuccess;
    //client certificate password
    NSDictionary *optionsDictionary = [NSDictionary dictionaryWithObject:@"123456"
                                                                  forKey:(__bridge id)kSecImportExportPassphrase];
    
    CFArrayRef items = CFArrayCreate(NULL, 0, 0, NULL);
    securityError = SecPKCS12Import((__bridge CFDataRef)inPKCS12Data,(__bridge CFDictionaryRef)optionsDictionary,&items);
    
    if(securityError == 0) {
        CFDictionaryRef myIdentityAndTrust =CFArrayGetValueAtIndex(items,0);
        const void*tempIdentity =NULL;
        tempIdentity= CFDictionaryGetValue (myIdentityAndTrust,kSecImportItemIdentity);
        *outIdentity = (SecIdentityRef)tempIdentity;
        const void*tempTrust =NULL;
        tempTrust = CFDictionaryGetValue(myIdentityAndTrust,kSecImportItemTrust);
        *outTrust = (SecTrustRef)tempTrust;
    } else {
        NSLog(@"Failedwith error code %d",(int)securityError);
        return NO;
    }
    return YES;
}

然后在相应位置加入

[manager setSecurityPolicy:[self customSecurityPolicy]];
[self checkCredential:manager]; 

三、NSURLConnection、NSURLSession适配

http://www.cnblogs.com/lmfboke/p/6232656.html
http://oncenote.com/2014/10/21/Security-1-HTTPS/
http://www.jianshu.com/p/97745be81d64

四、其他

SDWebImage绕过证书验证去加载图片

[imageView sd_setImageWithURL:[NSURL URLWithString:urlString] placeholderImage:self.placeholder options:SDWebImageAllowInvalidSSLCertificates];

五、部分参考

http://www.jianshu.com/p/72bf60b5f94d
http://www.cnblogs.com/lmfboke/p/6232656.html
http://blog.csdn.net/iostiannan/article/details/53763082
http://www.wosign.com/faq/faq-ios-https.htm
http://www.cocoachina.com/ios/20150702/12384.html
http://www.wosign.com/news/ios-app-https.htm
http://www.cocoachina.com/ios/20161207/18308.html
http://edison0663.iteye.com/blog/996526

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 203,772评论 6 477
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 85,458评论 2 381
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 150,610评论 0 337
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,640评论 1 276
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,657评论 5 365
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,590评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,962评论 3 395
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,631评论 0 258
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,870评论 1 297
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,611评论 2 321
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,704评论 1 329
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,386评论 4 319
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,969评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,944评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,179评论 1 260
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 44,742评论 2 349
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,440评论 2 342

推荐阅读更多精彩内容