iOS9苹果将原http协议改成了https协议的方法
转载 & & 投稿：mrr
这篇文章主要介绍了iOS9苹果将原http协议改成了https协议的方法的相关资料,需要的朋友可以参考下
解决方法：
在info.plist 加入key
&key&NSAppTransportSecurity&/key&
&key&NSAllowsArbitraryLoads&/key&
下面给大家介绍ios中http 和https 协议的访问
最近做个项目，开始采用的是HTTP协议实现客户端和服务器端的交互，后来需要改成HTTPS协议。在修改的过程中发现了一些问题，解决方案如下：
NSString *urlString =[NSString stringWithFormat:@"https://127.0.0.1/default.aspx?USER=%@",@"111"];
NSMutableURLRequest *request = [[[NSMutableURLRequest alloc] init] autorelease];
[request setURL:[NSURL URLWithString:urlString]];
[request setHTTPMethod:@"GET"];
NSHTTPURLResponse* urlResponse =
NSError *error = [[NSError alloc] init];
NSData *responseData = [NSURLConnection sendSynchronousRequest:request returningResponse:&urlResponse error:&error];
NSMutableString *result = [[NSMutableString alloc] initWithData:responseData encoding:NSUTF8StringEncoding];
NSLog(@"The result string is :%@",result);
NSString *urlString =[NSString stringWithFormat:@"https://127.0.0.1/default.aspx?USER=%@",@"111"];
NSMutableURLRequest *request = [[NSMutableURLRequest alloc] initWithURL:[NSURL URLWithString:urlString] cachePolicy:NSURLRequestReloadIgnoringLocalCacheData timeoutInterval:5];
//设置请求方式为get
[request setHTTPMethod:@"GET"];
//添加用户会话id
[request addValue:@"text/html" forHTTPHeaderField:@"Content-Type"];
//连接发送请求
finished =
NSURLConnection *conn = [[NSURLConnection alloc] initWithRequest:request delegate:self];
//堵塞线程，等待结束
while(!finished) {
[[NSRunLoop currentRunLoop] runMode:NSDefaultRunLoopMode beforeDate:[NSDate distantFuture]];
- (void)connection:(NSURLConnection *)connection didReceiveResponse:(NSURLResponse*)response
- (void)connectionDidFinishLoading:(NSURLConnection *)connection
//[_waitingDialog dismissWithClickedButtonIndex:0 animated:NO];
[connection release];
-(void)connection:(NSURLConnection *)connection didFailWithError:(NSError *)error
- (BOOL)connectionShouldUseCredentialStorage:(NSURLConnection *)connection{
return NO;
//下面两段是重点，要服务器端单项HTTPS 验证，iOS 客户端忽略证书验证。
- (BOOL)connection:(NSURLConnection *)connection canAuthenticateAgainstProtectionSpace:(NSURLProtectionSpace *)protectionSpace {
return [protectionSpace.authenticationMethod isEqualToString:NSURLAuthenticationMethodServerTrust];
- (void)connection:(NSURLConnection *)connection didReceiveAuthenticationChallenge:(NSURLAuthenticationChallenge *)challenge {
NSLog(@"didReceiveAuthenticationChallenge %@ %zd", [[challenge protectionSpace] authenticationMethod], (ssize_t) [challenge previousFailureCount]);
if ([challenge.protectionSpace.authenticationMethod isEqualToString:NSURLAuthenticationMethodServerTrust]){
[[challenge sender] useCredential:[NSURLCredential credentialForTrust:challenge.protectionSpace.serverTrust] forAuthenticationChallenge:challenge];
[[challenge sender] continueWithoutCredentialForAuthenticationChallenge: challenge];
NSLog(@"get the whole response");
//[receivedData setLength:0];
//处理数据
- (void)connection:(NSURLConnection *)connection didReceiveData:(NSData *)data
您可能感兴趣的文章:
大家感兴趣的内容
12345678910
最近更新的内容
常用在线小工具主题信息（必填）
主题描述（最多限制在50个字符）
申请人信息（必填）
申请信息已提交审核，请注意查收邮件，我们会尽快给您反馈。
如有疑问，请联系
CSDN &《程序员》研发主编，投稿&纠错等事宜请致邮
你只管努力，剩下的交给时光！
如今的编程是一场程序员和上帝的竞赛，程序员要开发出更大更好、傻瓜都会用到软件。而上帝在努力创造出更大更傻的傻瓜。目前为止，上帝是赢的。个人网站：www.xttblog.com。个人QQ群：、
个人大数据技术博客：http://www.iteblog.com
WeTest 导读日起，苹果公司将强制使用HTTPS协议传输。本文通过对HTTPS基础原理和通信过程内容的讲解，介绍APP开发者在这个背景下的应对办法。几周前，我们在《https大势已来？看腾讯专家如何在高并发压测中支持https》中介绍了腾讯WeTest在基于epoll的高并发机器人框架中加入openssl的方法支持HTTPS接口测试的方法，不仅介绍了具体的使用办法，并且了解到HTTPS注定会是未来的主流趋势。而随着2016年行将结束，我们发现，这一天，已经越来越近了。随着全球互联网安全意识的进一步觉醒，越来越多的公司意识到网络信息安全的重要性，只有绝对的加密才能保证在线交易和商务活动的安全进行。互联网无疑是个人信息和隐私泄露最频繁的场合，各种以窃取信息为方式而展开的网络犯罪是互联网发展所面临的最大挑战。在这样一个大环境下，苹果公司首先做出应对，在苹果全球开发者大会（WWDC）的一场安全演示会上，苹果公司公布了一个最后期限——2017 年 1 月 1 日——即 App Store 当中的所有应用必须启用 App Transport Security （ATS）安全功能。一、这个举措意味着什么？苹果公司强制所有iOS App在日前使用HTTPS加密，这就意味着，如果您的APP如果仍采用HTTP传输，那么，在Apple Store中您的APP将不再能被用户下载使用。二、什么是App Transport Security （ATS）安全功能？App Transport Security，简称 ATS，是苹果在 iOS 9 当中首次推出的一项安全功能。在启用 ATS 之后，它会强制应用通过 HTTPS（而不是 HTTP）连接网络服务，这能够通过加密来保障用户数据安全。HTTPS 当中的“S”代表的是“安全”（secure），在登录银行或电邮账号时，你会常常看到它出现在浏览器地址栏。不过，移动应用在网络连接安全性上面没有那么透明，用户很难知道应用连接网络时使用的是 HTTP 还是 HTTPS。ATS 由此登场，它在 iOS 9 当中是默认开启的。然而，开发者仍然能够关闭 ATS，让自己的应用通过 HTTP 连接传输数据——现在的情况是，这招在年底之后就行不通了。（技术人员注意：ATS 要求使用 TLS v 1.2，但那些已经经过加密的批量数据例外，比如流媒体数据。）在今年年底时，苹果将要求所有提交到 App Store 的应用强制开启 ATS。现在有了明确的最终期限，那些一直 想知道 HTTP 会在什么时候遭此重击的应用开发者可以松一口气了，而用户也能安心地知道，他们的 iPhone 和 iPad 应用将默认使用安全连接。三、为什么这么做？企业对于网络信息安全的也越来越高，只有保证绝对的加密传输才能确保在线交易及用户个人隐私数据的安全性。由于HTTP明文传输带来的安全事件频发，企业对于HTTP已无信任可言，只有通过HTTPS加密传输才能有效的防钓鱼，防篡改，防监听，防劫持使网站安全可信。四、开发者应该做什么？首先需要选择合适的证书为部署https证书做决策，然后调整后台应用实现后台应用全站https，协调运营及开发完成部署完善服务端应用部署及Web服务器配置，最后以安全方式发布应用完成应用改造，重新发布应用。为了让大家更好的理解上述措施，下面具体介绍一下相关的HTTPS基础原理和通信过程。五、HTTPS的基础原理和通信过程HTTPS(Secure Hypertext Transfer Protocol) 安全超文本传输协议 它是一个安全通信通道，它基于 HTTP 开发，用于在客户计算机和服务器之间交换信息。它使用安全套接字层(SSL)进行信息交换，简单来说它是 HTTP 的安全版,是使用 TLS/SSL 加密的 HTTP 协议。HTTP 协议采用明文传输信息，存在信息窃听、信息篡改和信息劫持的风险，而协议 TLS/SSL 具有身份验证、信息加密和完整性校验的功能，可以避免此类问题。TLS/SSL 全称安全传输层协议 Transport Layer Security, 是介于 TCP 和 HTTP 之间的一层安全协议，不影响原有的 TCP 协议和 HTTP 协议，所以使用 HTTPS 基本上不需要对 HTTP 页面进行太多的改造。
1、TLS/SSL 原理HTTPS 协议的主要功能基本都依赖于 TLS/SSL 协议，本节分析安全协议的实现原理。TLS/SSL 的功能实现主要依赖于三类基本算法：散列函数 Hash、对称加密和非对称加密，其利用非对称加密实现身份认证和密钥协商，对称加密算法采用协商的密钥对数据加密，基于散列函数验证信息的完整性。
散列函数 Hash，常见的有 MD5、SHA1、SHA256，该类函数特点是函数单向不可逆、对输入非常敏感、输出长度固定，针对数据的任何修改都会改变散列函数的结果，用于防止信息篡改并验证数据的完整性；对称加密，常见的有 AES-CBC、DES、3DES、AES-GCM等，相同的密钥可以用于信息的加密和解密，掌握密钥才能获取信息，能够防止信息窃听，通信方式是1对1；非对称加密，即常见的 RSA 算法，还包括 ECC、DH 等算法，算法特点是，密钥成对出现，一般称为公钥(公开)和私钥(保密)，公钥加密的信息只能私钥解开，私钥加密的信息只能公钥解开。因此掌握公钥的不同客户端之间不能互相解密信息，只能和掌握私钥的服务器进行加密通信，服务器可以实现1对多的通信，客户端也可以用来验证掌握私钥的服务器身份。在信息传输过程中，散列函数不能单独实现信息防篡改，因为明文传输，中间人可以修改信息之后重新计算信息摘要，因此需要对传输的信息以及信息摘要进行加密；对称加密的优势是信息传输1对1，需要共享相同的密码，密码的安全是保证信息安全的基础，服务器和 N 个客户端通信，需要维持 N 个密码记录，且缺少修改密码的机制；非对称加密的特点是信息传输1对多，服务器只需要维持一个私钥就能够和多个客户端进行加密通信，但服务器发出的信息能够被所有的客户端解密，且该算法的计算复杂，加密速度慢。结合三类算法的特点，TLS 的基本工作方式是，客户端使用非对称加密与服务器进行通信，实现身份验证并协商对称加密使用的密钥，然后对称加密算法采用协商密钥对信息以及信息摘要进行加密通信，不同的节点之间采用的对称密钥不同，从而可以保证信息只能通信双方获取。2、PKI 体系（1）RSA 身份验证的隐患身份验证和密钥协商是 TLS 的基础功能，要求的前提是合法的服务器掌握着对应的私钥。但 RSA 算法无法确保服务器身份的合法性，因为公钥并不包含服务器的信息，存在安全隐患：客户端 C 和服务器 S 进行通信，中间节点 M 截获了二者的通信；节点 M 自己计算产生一对公钥 pub_M 和私钥 pri_M;C 向 S 请求公钥时，M 把自己的公钥 pub_M 发给了 C;C 使用公钥 pub_M 加密的数据能够被 M 解密，因为 M 掌握对应的私钥 pri_M，而 C 无法根据公钥信息判断服务器的身份，从而 C 和 M 之间建立了”可信”加密连接；中间节点 M 和服务器S之间再建立合法的连接，因此 C 和 S 之间通信被M完全掌握，M 可以进行信息的窃听、篡改等操作。另外，服务器也可以对自己的发出的信息进行否认，不承认相关信息是自己发出。因此该方案下至少存在两类问题：中间人攻击和信息抵赖。
几周前，我们在《https大势已来？看腾讯专家如何在高并发压测中支持https》中介绍了腾讯WeTest在基于epoll的高并发机器人框架中加入openssl的方法支持HTTPS接口测试的方法，不仅介绍了具体的使用办法，并且了解到HTTPS注定会是未来的主流趋势。而随着2016年行将结束，我们发现，这一天，已经越来越近了。随着全球互联网安全意识的进一步觉醒，越来越多的公司意识到网络信息安全的重要性，只有绝对的加密才能保证在线交易和商务活动的安全进行。互联网无疑是个人信息和隐私泄露最频繁的场合，各种以窃取信息为方式而展开的网络犯罪是互联网发展所面临的最大挑战。在这样一个大环境下，苹果公司首先做出应对，在苹果全球开发者大会（WWDC）的一场安全演示会上，苹果公司公布了一个最后期限——2017 年 1 月 1 日——即 App Store 当中的所有应用必须启用 App Transport Security （ATS）安全功能。（2）身份验证-CA 和证书解决上述身份验证问题的关键是确保获取的公钥途径是合法的，能够验证服务器的身份信息，为此需要引入权威的第三方机构 CA。CA 负责核实公钥的拥有者的信息，并颁发认证”证书”，同时能够为使用者提供证书验证服务，即 PKI 体系。基本的原理为，CA 负责审核信息，然后对关键信息利用私钥进行”签名”，公开对应的公钥，客户端可以利用公钥验证签名。CA 也可以吊销已经签发的证书，基本的方式包括两类 CRL 文件和 OCSP。CA 使用具体的流程如下：
a.服务方 S 向第三方机构CA提交公钥、组织信息、个人信息(域名)等信息并申请认证；b.CA 通过线上、线下等多种手段验证申请者提供信息的真实性，如组织是否存在、企业是否合法，是否拥有域名的所有权等；c.如信息审核通过，CA 会向申请者签发认证文件-证书。证书包含以下信息：申请者公钥、申请者的组织信息和个人信息、签发机构 CA 的信息、有效时间、证书序列号等信息的明文，同时包含一个签名；签名的产生算法：首先，使用散列函数计算公开的明文信息的信息摘要，然后，采用 CA 的私钥对信息摘要进行加密，密文即签名；d.客户端 C 向服务器 S 发出请求时，S 返回证书文件；e.客户端 C 读取证书中的相关的明文信息，采用相同的散列函数计算得到信息摘要，然后，利用对应 CA 的公钥解密签名数据，对比证书的信息摘要，如果一致，则可以确认证书的合法性，即公钥合法；f.客户端然后验证证书相关的域名信息、有效时间等信息；g.客户端会内置信任 CA 的证书信息(包含公钥)，如果CA不被信任，则找不到对应 CA 的证书，证书也会被判定非法。在这个过程注意几点：1.申请证书不需要提供私钥，确保私钥永远只能服务器掌握；2.证书的合法性仍然依赖于非对称加密算法，证书主要是增加了服务器信息以及签名；3.内置 CA 对应的证书称为根证书，颁发者和使用者相同，自己为自己签名，即自签名证书；4.证书=公钥+申请者与颁发者信息+签名；六、HTTPS接口测试那么在完成了全站HTTPS，完成了后台和服务器端的部署之后，如何快速的对“新站“进行快速的测试，检测APP接口的承载能力？腾讯WeTest提供了针对https的服务器性能测试功能，使用方法如下：1、点击服务器性能测试产品首页（ ）中的快捷入口：HTTP直压。模式选择简单模式，名称和描述可以自己填写。（图中示例起始人数50人，每隔60秒增加50人，加到200人为上限）
点击左侧“HTTP直压“进入压测2、新建一个客户端请求，接口压测包括读写接口，读接口基本是GET请求，写接口基本是POST请求。GET请求使用url请求参数，填写测试用例的基础数值，选择正确的URL
配置页面header信息3、随后进行Header的配置，Header的名称在选定URL的内，打开URL的链接（推荐使用chrome浏览器），敲击F12并刷新页面，选定Network-Name-Headers-Request Headers（Header的名称与值均在内查看，如下图所示）
查看页面header信息到这里，基本就完成了对https的配置过程了，是不是很简单？下面动图可以再回顾一下操作的流程：gif动态图展示操作的流程七、HTTPS性能与优化在对HTTPS协议页面进行了测试之后，下面再介绍一些HTTPS页面性能优化的方法。1、HTTPS 性能损耗HTTPS的优势在于进行完身份验证、信息加密与完整性校验等操作后，可以不对 TCP 和 HTTP 协议做任何修改。但通过增加新协议以实现更安全的通信必然需要付出代价，HTTPS 协议的性能损耗主要体现如下：（1）增加延时分析前面的握手过程，一次完整的握手至少需要两端依次来回两次通信，至少增加延时2 RTT，利用会话缓存从而复用连接，延时也至少1 RTT*。（2）消耗较多的 CPU 资源除数据传输之外，HTTPS 通信主要包括对对称加解密、非对称加解密(服务器主要采用私钥解密数据)；压测 TS8 机型的单核 CPU：对称加密算法AES-CBC-256 吞吐量 600Mbps，非对称 RSA 私钥解密200次/s。不考虑其它软件层面的开销，10G 网卡为对称加密需要消耗 CPU 约17核，24核CPU最多接入 HTTPS 连接 4800；静态节点当前10G 网卡的 TS8 机型的 HTTP 单机接入能力约为10w/s，如果将所有的 HTTP 连接变为HTTPS连接，则明显 RSA 的解密最先成为瓶颈。因此，RSA 的解密能力是当前困扰 HTTPS 接入的主要难题。2、HTTPS 接入优化（1）CDN 接入HTTPS 增加的延时主要是传输延时 RTT，RTT 的特点是节点越近延时越小，CDN 天然离用户最近，因此选择使用 CDN 作为 HTTPS 接入的入口，将能够极大减少接入延时。CDN 节点通过和业务服务器维持长连接、会话复用和链路质量优化等可控方法，极大减少 HTTPS 带来的延时。（2）会话缓存虽然前文提到 HTTPS 即使采用会话缓存也要至少1*RTT的延时，但是至少延时已经减少为原来的一半，明显的延时优化；同时，基于会话缓存建立的 HTTPS 连接不需要服务器使用RSA私钥解密获取 Pre-master 信息，可以省去CPU 的消耗。如果业务访问连接集中，缓存命中率高，则HTTPS的接入能力讲明显提升。当前 TRP 平台的缓存命中率高峰时期大于30%，10k/s的接入资源实际可以承载13k/的接入，收效非常可观。（3）硬件加速为接入服务器安装专用的 SSL 硬件加速卡，作用类似 GPU，释放 CPU，能够具有更高的 HTTPS 接入能力且不影响业务程序的。测试某硬件加速卡单卡可以提供 35k 的解密能力，相当于175核 CPU，至少相当于7台24核的服务器，考虑到接入服务器其它程序的开销，一张硬件卡可以实现接近10台服务器的接入能力。（4）远程解密本地接入消耗过多的 CPU 资源，浪费了网卡和硬盘等资源，考虑将最消耗 CPU 资源的RSA解密计算任务转移到其它服务器，如此则可以充分发挥服务器的接入能力，充分利用带宽与网卡资源。远程解密服务器可以选择 CPU 负载较低的机器充当，实现机器资源复用，也可以是专门优化的高计算性能的服务器。当前也是 CDN 用于大规模HTTPS接入的解决方案之一。（5）SPDY/HTTP2前面的方法分别从减少传输延时和单机负载的方法提高 HTTPS 接入性能，但是方法都基于不改变 HTTP 协议的基础上提出的优化方法，SPDY/HTTP2 利用 TLS/SSL 带来的优势，通过修改协议的方法来提升 HTTPS 的性能，提高下载速度等。腾讯WeTest服务器性能测试运用了沉淀十多年的内部实践经验总结，通过基于真实业务场景和用户行为进行压力测试，帮助游戏开发者发现服务器端的性能瓶颈，进行针对性的性能调优，降低服务器采购和维护成本，提高用户留存和转化率。功能目前免费对外开放中，欢迎大家的体验
体验地址：如果对使用当中有任何疑问，欢迎联系腾讯WeTest企业qq：天极传媒：天极网全国分站
您现在的位置：
& >>2017年所有iOS应用将使用HTTPS联网
2017年所有iOS应用将强制使用HTTPS安全连接
Yesky天极新闻
作者：一夏末
责编：一夏末
　　【天极网手机频道】在昨日的WWDC 2016开发者大会上，苹果在讲解全新的 10中提到了数据安全这一方面，并且苹果宣布iOS应用将从2017年1月起启用名为App Transport Security的安全传输功能。
2017年所有iOS应用将强制使用HTTPS安全连接
　　苹果在iOS 9中首次引入了ATS安全传输功能，当应用请求联网的时候，该功能将强制应用使用HTTPS连接而非一般的 HTTP。启用HTTPS网络连接之后，数据传输的安全性将大幅提示，不容易被黑客拦截破译。
　　ATS在许多银行和通信应用中具有很重要的作用，尽管当前ATS还只是一个可选功能，不过从2017年开始，App Store中的所有应用都将会被强制启用这一功能，而这一决定符合苹果一贯对保护用户隐私安全的态度，今年苹果与FBI的就解锁的争论足以记入史册。(via: CNET)
（作者：一夏末责任编辑：一夏末）
天极新媒体&最酷科技资讯扫码赢大奖
* 网友发言均非本站立场，本站不在评论栏推荐任何网店、经销商，谨防上当受骗！
整机数码游戏软件苹果 2017 年 1 月 1 日强制使用 https 会影响 safari 访问网站吗
13:14:56 +08:00 · 1887 次点击
公司很多 app 的下载链接都印刷了二维码，下载链接是 http://的。重新印刷麻烦大了。。。
ATS 会影响浏览器访问吗？
10 回复 &| &直到
10:33:04 +08:00
& & 13:27:57 +08:00
浏览器肯定没影响
& & 13:33:51 +08:00
强制的是 APP
& & 13:35:02 +08:00
@ 一般用户都用微信扫二维码，不知道微信会不会有影响？
& & 13:37:34 +08:00
chrome 都只是标一下不安全，水果不可能敢那么激进的，也就是自己的生态圈内可以强行要求一下开发者。。
& & 13:40:04 +08:00
@ 扫码出来是网址的话，微信用自己内置的浏览器打开，理论上受影响，但微信应该会关闭 HTTPS 限制。
App Store 的这个要求不是完全强制的， plist 里有开关可以关闭限制，提交审核时需要向审核员说明原因。看到时候微信怎么处理。
& & 13:55:27 +08:00
@ @ 明白，谢谢。
& & 14:20:59 +08:00
@ 可能情况是微信作为那么大体量的巨头，可以享有豁免，现在 itunes connect 里面上传的时候能看到有一项叫做 App 使用非豁免类加密的标注，不清楚是否和这个有关系。
& & 14:31:37 +08:00
@ 我个人开发一个不支持 HTTPS 论坛的第三方 App 也可以向 App Store 申请关闭限制，这是规则内的。
至于微信被特殊关照，本来腾讯和 Apple 关系就好，微信团队和 App Store 审核团队有直接接触（听说），上次 iOS 10 电话拦截也用 Tencent 来演示。
& & 23:33:51 +08:00 via Android
不考虑跳转吗？
& & 10:33:04 +08:00
@ 正在部署 https ，主要是客户更换包装盒的二维码成本太高，?
& · & 1988 人在线 & 最高记录 3541 & · &
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.0 · 68ms · UTC 13:36 · PVG 21:36 · LAX 05:36 · JFK 08:36? Do have faith in what you're doing.iOS安全系列之：HTTPS进阶_黑客技术与网络安全_传送门
iOS安全系列之：HTTPS进阶
黑客技术与网络安全
来自：Jamin's Homepage作者：jaminzzhang链接：http://oncenote.com//Security-2-HTTPS2/（点击尾部阅读原文前往）本文分为以下五节：1、中间人攻击：介绍中间人攻击常见方法，并模拟了一个简单的中间人攻击；2、校验证书的正确姿势：介绍校验证书的一些误区，并讨论了正确校验方式；3、ATS：讨论下 iOS 9.0 新发布的的特性App Transport Security；4、调试SSL/TLS：讨论使用Wireshark进行SSL/TLS调试的方法；5、后记其中第1节“中间人”是比较常见基础的知识，网上也可以找到相关的资料，如果对中间人攻击已经有了足够的了解，可以跳过。后面几节则是个人在iOS方面的实践总结，除了一些与系统相关的特性外，大部分都是系统无关的通用知识，并且每一章节都比较独立，所以可以直接跳到感兴趣的地方阅读。1、中间人攻击关于HTTPS，我经常会提到的就是中间人攻击，那究竟什么是中间人攻击呢？中间人攻击，即所谓的Main-in-the-middle attack(MITM)，顾名思义，就是攻击者插入到原本直接通信的双方，让双方以为还在直接跟对方通讯，但实际上双方的通信对方已变成了中间人，信息已经是被中间人获取或篡改。当然，本文并不是科普性文章，本节就针对HTTPS攻击，特别是HTTPS在App这一应用场景下的常见的攻击手段进行分析讨论。由前文我们知道，HTTPS在建立了TCP连接之后，会进行SSL握手（SSL Handshake）来校验证书，协商加密协议和对称加密的密钥，之后就会使用协商好的密钥来进行传输。所以HTTPS攻击一般分为SSL连接建立前的攻击，以及HTTPS传输过程中的攻击；常见的HTTPS中间人攻击，首先需要结合ARP、DNS欺骗等技术，来对会话进行拦截，1.1 SSL证书欺骗攻击此类攻击较为简单常见。首先通过ARP欺骗、DNS劫持甚至网关劫持等等，将客户端的访问重定向到攻击者的机器，让客户端机器与攻击者机器建立HTTPS连接（使用伪造证书），而攻击者机器再跟服务端连接。这样用户在客户端看到的是相同域名的网站，但浏览器会提示证书不可信，用户不点击继续浏览就能避免被劫持的。所以这是最简单的攻击方式，也是最容易识别的攻击方式。此类攻击有个经典的工具：SSLSniff。SSLSniff是大神Moxie Marlinspike开发的工具，该工具一开始是设计用于上一篇文章中提到的Basic Constaints 漏洞的，这类系统级别的漏洞，基本上可以让你不知不觉；现在的操作系统和浏览器基本修复了这一漏洞。但也可以使用SSLSniff来伪造证书实现钓鱼攻击。防范措施：钓鱼类攻击，App直接调用系统API创建的HTTPS连接（NSURLConnection）一般不会受到影响，只使用默认的系统校验，只要系统之前没有信任相关的伪造证书，校验就直接失败，不会SSL握手成功；但如果是使用WebView浏览网页，需要在UIWebView中加入较强的授权校验，禁止用户在校验失败的情况下继续访问。1.2 SSL剥离攻击（SSLStrip）SSL剥离，即将HTTPS连接降级到HTTP连接。假如客户端直接访问HTTPS的URL，攻击者是没办法直接进行降级的，因为HTTPS与HTTP虽然都是TCP连接，但HTTPS在传输HTTP数据之前，需要在进行了SSL握手，并协商传输密钥用来后续的加密传输；假如客户端与攻击者进行SSL握手，而攻击者无法提供可信任的证书来让客户端验证通过进行连接，所以客户端的系统会判断为SSL握手失败，断开连接。该攻击方式主要是利用用户并不会每次都直接在浏览器上输入https://xxx.xxx.com来访问网站，或者有些网站并非全网HTTPS，而是只在需要进行敏感数据传输时才使用HTTPS的漏洞。中间人攻击者在劫持了客户端与服务端的HTTP会话后，将HTTP页面里面所有的https://超链接都换成http://，用户在点击相应的链接时，是使用HTTP协议来进行访问；这样，就算服务器对相应的URL只支持HTTPS链接，但中间人一样可以和服务建立HTTPS连接之后，将数据使用HTTP协议转发给客户端，实现会话劫持。这种攻击手段更让人难以提防，因为它使用HTTP，不会让浏览器出现HTTPS证书不可信的警告，而且用户很少会去看浏览器上的URL是https://还是http://。特别是App的WebView中，应用一般会把URL隐藏掉，用户根本无法直接查看到URL出现异常。防范措施：该种攻击方式同样无法劫持App内的HTTPS连接会话，因为App中传入请求的URL参数是固定带有https://的；但在WebView中打开网页同样需要注意，在非全网HTTPS的网站，建议对WebView中打开的URL做检查，检查应该使用https://的URL是否被篡改为http://；也建议服务端在配置HTTPS服务时，加上“HTTP Strict Transport Security”配置项。参考：【流量劫持】躲避HSTS的HTTPS劫持1.3 针对SSL算法进行攻击上述两种方式，技术含量较低，而且一般只能影响 WebApp，而很难攻击到 Native App ， 所以高阶的 Hacker，会直接针对SSL算法相关漏洞进行攻击，期间会使用很多的密码学相关手段。由于本人非专业安全相关人员，没有多少相关实践经验，所以本节不会深入讲解相关的攻击原理和手段，有兴趣的同学可以查看以下拓展阅读：OpenSSL漏洞常见的HTTPS攻击方法防范措施：这类攻击手段是利用SSL算法的相关漏洞，所以最好的防范措施就是对服务端 SSL/TLS 的配置进行升级：只支持尽量高版本的TLS（最低TLSv1）；禁用一些已爆出安全隐患的加密方法；使用2048位的数字证书；1.4 模拟最简单的攻击经过上述几种攻击方式的说明之后，我们来模拟下最简单的中间人攻击。中间人攻击步骤方式的上文已经说过了，流量劫持相关操作不是本文重点，可以参考流量劫持是如何产生的？， 本例直接使用Charles来做代理，对流量进行劫持。并使用SSL代理来模拟下对iPhone设备HTTPS请求的中间人攻击，让大家在思考理解中间人攻击方式的同时，了解在开发中如何防范类似的攻击。1) Charles设置代理在Charles中开启并设置HTTP代理和SSL代理，Menu -> Proxy -> Proxy Setting，设置如图：HTTP代理设置，注意记住端口号为：8888SSL代理设置，在Locations上可以设置想要进行SSL代理的域名，这里以百度的百付宝*.baifubao.com为模拟对象。2) 在iPhone端设置HTTP代理在Mac上获取当前机器的IP地址：ifconfig en0:还有一个简单的方法，按住option+点击顶部菜单栏的WiFi网络图标：可以看到当前电脑的IP地址为：192.168.199.249。将iPhone连接到与电脑相同的WiFi，在iPhone设置中：无线局域网 -> 已连接WiFi右边的Info详情图标 -> HTTP代理 -> 手动 -> 设置HTTP代理：设置完成之后，打开Safari随便访问一个网页，初次设置代理的话，Charles会弹出一个iPhone请求代理的确认框，点击Allow即可。然后在Charles上就可以看到iPhone上的HTTP请求了。为了避免Mac上的请求过多影响对被代理iPhone上HTTP请求的查看和调试，可以在Charles取消Mac的代理：Menu -> Proxy -> 取消勾选Mac OS X Proxy 即可。假如你访问的是被代理的目标 URL http://www.baifubao.com 则打不开网页。因为iPhone的HTTPS请求已经被Charles拦截，但iPhone无法信任Charles的证书，所以SSL Handshake失败，无法建立HTTPS连接。3) 伪造证书欺骗在被代理的iPhone上打开Safari，访问http://www.charlesproxy.com/getssl，会弹出安装描述符文件的界面，该描述文件包含了Charles根证书：注意：这个Charles证书是内置在Charles中的，可以在菜单Help -> SSL Proxying可以直接保存和安装证书。安装后的描述文件可以在iPhone设备的设置 -> 通用 -> 描述文件进行查看和管理。“安装”完成之后，就会将Charles根证书加入系统可信任证书列表中，使用该证书签发的子证书也会被系统信任。Charles会为之前SSL代理设置中配置的域名生成对应的SSL证书，这样伪造证书的证书就实现了欺骗。可以使用Mac SSL代理查看下：4) 结果验证下载百度App，然后登录账号，在我 -> 我的钱包，就会访问百付宝：看到已成功获取到HTTPS请求包的内容。从这里，我们可以猜测出该App是使用系统默认的校验方式：系统信任了这个中间人服务器返回的SSL证书，App就信任了这一校验，SSL握手成功；而没有对服务器证书进行本地对比校验。这是当下非常多App存在的安全隐患。这个简单的SSL代理模拟了简单钓鱼式的中间人攻击，大家应该都基本明白了这种攻击方式的所针对的漏洞，以及防范这种攻击方法的措施：不要随意连入公共场合内的WiFi，或者使用未知代理服务器不要安装不可信或突然出现的描述文件，信任伪造的证书；App内部需对服务器证书进行单独的对比校验，确认证书不是伪造的；2、校验证书的正确姿势上一节对中间人攻击进行了简单介绍，本节就上一节我们遇到的安全隐患问题，来讨论下在App中，应该怎么校验服务器返回的SSL证书，来保证HTTPS通信的安全。上一篇文章《iOS安全系列之一：HTTPS》有对基本校验过程相关代码进行讲解，本文不会赘述这些细节，而是主要讨论校验证书中几个重要的点：2.1 域名验证前不久，iOS上最知名的网络开源库AFNetworking爆出HTTPS校验漏洞，该漏洞是因为其校验策略模块 AFSecurityPolicy 内的参数 validatesDomainName 默认为NO，这会导致校验证书的时候不会校验这个证书对应的域名。即请求返回的服务器证书，只要是可信任CA机构签发的，都会校验通过，这是非常严重的漏洞。该漏洞已在v2.5.2版本中修复，对应Git版本号3e631b203dd95bb82dfbcc2c47a2d84b59d1eeb4。这个漏洞以及AFNetworking的相关源码会让很多人以为系统的默认校验是不校验证书对应域名的，实际上并非如此。这里AFNetworking确有画蛇添足之嫌。首先我们查看下系统的默认校验策略：- (void)connection:(NSURLConnection *)connection willSendRequestForAuthenticationChallenge:(NSURLAuthenticationChallenge *)challenge {//1)获取trust objectSecTrustRef trust = challenge.protectionSpace.serverT//获取默认的校验策略CFArrayRef defaultPolicies = NULL;SecTrustCopyPolicies(serverTrust, &defaultP);NSLog(@"Default Trust Policies: %@", (__bridge id)defaultPolicies);//...}打印默认校验策略信息：5 : {contents = "ValidRoot"} = {value = true}6 : {contents = "SSLHostname"} = {contents = "xxx.xxx.com"}8 : {contents = "ValidLeaf"} = {value = true}从打印信息来看，系统的默认校验策略中已包含了域名校验。然后再看AFSecurityPolicy中相关源码：- (BOOL)evaluateServerTrust:(SecTrustRef)serverTrustforDomain:(NSString *)domain{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);//...}这其实也是很多开发者在处理异常与默认逻辑分支时会犯的错误，这段逻辑推荐实现方式是：//取代validatesDomainName，默认为NO，就是系统默认行为@property (nonatomic, assign) BOOL skipDomainNameV//校验- (BOOL)evaluateServerTrust:(SecTrustRef)serverTrustforDomain:(NSString *)domain{if (self.skipDomainNameValidation) {NSMutableArray *policies = [NSMutableArray array];[policies addObject:(__bridge_transfer id)SecPolicyCreateBasicX509()];SecTrustSetPolicies(serverTrust, (__bridge CFArrayRef)policies);}//...}从代码上看，逻辑是否变得更清晰了？而且也表明系统默认的校验方式是会验证域名的。实际上调用SecTrustSetPolicies来重新设置校验策略，主要是用于使用IP进行HTTPS请求，或者一个证书用于多个域名的场景；在这些场景下，服务器证书上的域名和请求域名（可能是IP，也可能是其他域名）就会出现不一致，导致校验不通过；这就需要重新设置下校验策略，把这个证书对应的域名设置下。详细说明请查看官方文档：《Overriding TLS Chain Validation Correctly》2.2 校验证书链？上一篇文章介绍系统验证SSL证书的方法和流程时，不是已经说明了会对证书链进行层层校验，以保证证书的可信么？为什么还需要讨论这一问题？其实本节要讨论的是AFNetworking中validatesCertificateChain的问题。先说明下结果：在AFNetworking最新发布的V2.6.0，已经将该特性去掉了。相关的讨论：SSL Pinning: What Should Be Certificate Chain Validation Expected Behavior?#2744AFNetworking中实现的验证证书链，是将App本地打包好的证书与服务器返回的证书链进行数据上的一一对比，只有打包到App的证书中包含了服务器返回的证书链上的所有证书，校验才会通过。如google的SSL证书：开启validatesCertificateChain后请求https://google.com，需要将GeoTrust Global CA、Google Internet Authority G2和google.com的证书都导入App中才能验证通过。请回忆下上一篇文章关于证书链的可信任机制，会发现这是完全没有必要的；证书链的验证，主要由三部分来保证证书的可信：叶子证书是对应HTTPS请求域名的证书，根证书是被系统信任的证书，以及这个证书链之间都是层层签发可信任链；证书之所以能成立，本质是基于信任链，这样任何一个节点证书加上域名校验（CA机构不会为不同的对不同的用户签发相同域名的证书），就确定一条唯一可信证书链，所以不需要每个节点都验证。2.3打包证书校验那是否就不需要在App中打包证书进行验证了呢？这时需要想想为什么伪造证书是可以实现中间人攻击的？答案就在于用户让系统信任了不应该信任的证书。用户设置系统信任的证书，会作为锚点证书(Anchor Certificate)来验证其他证书，当返回的服务器证书是锚点证书或者是基于该证书签发的证书（可以是多个层级）都会被信任。这就是基于信任链校验方式的最大弱点。我们不能完全相信系统的校验，因为系统的校验依赖的证书的源很可能被污染了。这就需要选取一个节点证书，打包到App中，作为Anchor Certificate来保证证书链的唯一性和可信性。所以还是需要App本地打包证书，使用SecTrustSetAnchorCertificates(SecTrustRef trust, CFArrayRef anchorCertificates)来设置Anchor Certificate进行校验。需要注意的是，官方文档《Certificate, Key, and Trust Services Reference》针对传入的 Anchor Certificates 有说明：IMPORTANTCalling this function without also calling SecTrustSetAnchorCertificatesOnly disables the trusting of any anchors other than the ones specified by this function call.也就是说，单纯调用SecTrustSetAnchorCertificates方法后不调用SecTrustSetAnchorCertificatesOnly来验证证书，则只会相信SecTrustSetAnchorCertificates传入的证书，而不会信任其他锚点证书。关于这一点，SecTrustSetAnchorCertificatesOnly方法参数讲解中也有说明：anchorCertificatesOnly:If true, disables trusting any anchors other than the ones passed in with the SecTrustSetAnchorCertificates function. If false, the built-in anchor certificates are also trusted. If SecTrustSetAnchorCertificates is called and SecTrustSetAnchorCertificatesOnly is not called, only the anchors explicitly passed in are trusted.只相信传入的锚点证书，也就只会验证通过由这些锚点证书签发的证书。这样就算被验证的证书是由系统其他信任的锚点证书签发的，也无法验证通过。最后一个问题：选择证书链的哪一节点作为锚点证书打包到App中？很多开发者会直接选择叶子证书。其实对于自建证书来说，选择哪一节点都是可行的。而对于由CA颁发的证书，则建议导入颁发该证书的CA机构证书或者是更上一级CA机构的证书，甚至可以是根证书。这是因为：1) 一般叶子证书的有效期都比较短，Google和Baidu官网证书的有效期也就几个月；而App由于是客户端，需要一定的向后兼容，稍疏于检查，今天发布，过两天证书就过期了。2) 越往证书链的末端，证书越有可能变动；比如叶子证书由特定域名(aaa.bbb.com)改为通配域名(*.bbb.com)等等。短期内的变动，重新部署后，有可能旧版本App更新不及时而出现无法访问的问题。因此使用CA机构证书是比较合适的，至于哪一级CA机构证书，并没有完全的定论，你可以自己评估选择。3、ATS在本文发表的时间（），大部分的iOS开发同学应该升级到iOS9了，在iOS9下进行HTTP/HTTPS请求时会遇到如下错误：Request failed: Error Domain=NSURLErrorDomain Code=-1022 "The resource could not be loaded because the App Transport Security policy requires the use of a secure connection." UserInfo=0x7fbb4a158f00 {NSUnderlyingError=0x7fbb4a1141c0 "The resource could not be loaded because the App Transport Security policy requires the use of a secure connection.", NSErrorFailingURLStringKey=http://api.xxx.com/mobile, NSErrorFailingURLKey=http://api.xxx.com/mobile, NSLocalizedDescription=The resource could not be loaded because the App Transport Security policy requires the use of a secure connection.}这是iOS9中一个重大的更新：App Transport Security，简称ATS。ATS对使用NSURLConnection, CFURL, 或NSURLSession 等 APIs 进行网络请求的行为作了一系列的强制要求，反逼服务器配置，以提高网络数据传输的安全性：These are the App Transport Security requirements:1) The server must support at least Transport Layer Security (TLS) protocol version 1.2.2) Connection ciphers are limited to those that provide forward secrecy (see the list of ciphers below.)3) Certificates must be signed using a SHA256 or better signature hash algorithm, with either a 2048 bit or greater RSA key or a 256 bit or greater Elliptic-Curve (ECC) key. Invalid certificates result in a hard failure and no connection.ATS要求运行在iOS9的App，需将HTTP连接升级到HTTPS，并且TLS版本不得低于v1.2；而且规定了支持的加密套件(Cipher Suite)和证书签名的哈希算法；如果想要向前兼容的话，可以通过设置Info.plist来降低校验强度，具体可以看这篇文章：Configuring App Transport Security Exceptions in iOS 9 and OSX 10.11。本人升级到iOS9 GM版，从App Store上下载了一些并没有完全支持ATS的应用，使用起来也完全没有问题，估计iOS系统对使用低于SDK9编译的App做了兼容，这方面也是符合预期的，毕竟ATS的影响实在太大，基本上没有任何的App能够幸免，比如图片下载一般使用HTTP，而不会使用HTTPS。所以建议可以暂时使用NSAllowsArbitraryLoads来取消ATS的限制，后续慢慢完善对ATS的支持。日益复杂脆弱的网络难以保证用户的数据安全，因此Apple才在iOS9上强推ATS，反向逼迫服务端升级，以提供更安全的网络环境。建议开发者不要简单地将ATS禁用，而应该升级服务器的配置支持ATS，为用户提供更安全的服务。4、调试SSL/TLS开发一个新的App，通常终端和后端先协商好了具体业务逻辑的通信协议，后端和终端按照协议实现逻辑之后，就进入联调阶段，第一次联调往往会回到很多问题，包括数据格式不对，缺少基础字段等；假如是基于HTTPS的网络请求，则很可能由于后台配置问题，导致遇到如CFNetwork SSLHandshake failed (-9824)这类握手失败的错误。面对这类SSL错误，该如何来解决呢？根据本人经验，主要是分两步：4.1 错误码这会不会太简单了？其实最简单的往往是最有效的。SSL相关错误码可以在中找到。上面-9824的错误，对应的是errSSLPeerHandshakeFail = -9824, /* handshake failure */，其他常见的错误码还有：//.../* fatal errors detected by peer */errSSLPeerUnexpectedMsg
/* unexpected message received */errSSLPeerBadRecordMac
/* bad MAC */errSSLPeerDecryptionFail
/* decryption failed */errSSLPeerRecordOverflow
/* record overflow */errSSLPeerDecompressFail
/* decompression failure */errSSLPeerHandshakeFail
/* handshake failure */errSSLPeerBadCert
/* misc. bad certificate */errSSLPeerUnsupportedCert
/* bad unsupported cert format */errSSLPeerCertRevoked
/* certificate revoked */errSSLPeerCertExpired
/* certificate expired */errSSLPeerCertUnknown
/* unknown certificate */errSSLIllegalParam
/* illegal parameter */errSSLPeerUnknownCA
/* unknown Cert Authority */errSSLPeerAccessDenied
/* access denied *//* more errors detected by us */errSSLHostNameMismatch
/* peer host name mismatch */errSSLConnectionRefused
/* peer dropped connection before responding */errSSLDecryptionFail
/* decryption failure */errSSLBadRecordMac
/* bad MAC */errSSLRecordOverflow
/* record overflow */errSSLBadConfiguration
/* configuration error *///...但靠错误码只能判断大概的情况，很多时候并不能明确知道到底是什么原因导致的，所以最直观的，还是需要抓包分析。4.2 抓包分析在这一阶段，使用Charles来抓包是没有用的，因为Charles是作为HTTP代理工作的，它会抓取代理的网络报文，然后将报文组合成HTTP/HTTPS协议包，对于HTTP调试非常方便，但由于细节的缺失，没办法使用它来分析SSL相关错误。所以我们需要使用上古神器Wireshark。关于Wireshark就不再多介绍了，网上已经有很多相关介绍和抓包教程，如《Mac OS X上使用Wireshark抓包》等，基本上可以很快上手。下面我们就以适配iOS9的ATS为例，来说下如何进行抓包分析，找出因为不支持ATS导致SSL握手失败问题。还记得SSL握手过程么？不记得可以重温下这篇文章：图解SSL/TLS协议。我们也来看看Wireshark上抓取到的包来直观学习正常的SSL握手流程：上图是一个标准的HTTPS请求抓取的包：1) 在TCP三次握手成功之后，客户端发起SSL的Client Hello(No.68帧)，传递随机数(Random)，和客户端支持的加密套件(Cipher Suites)、压缩方法、签名算法等信息； 如下图所示，这是Client Hello所携带的信息，可以展开来看相关的详情：2) 服务器从Client Hello中匹配支持的加密套件(Cipher Suites)、压缩算法和签名算法，和服务器新生成的一个随机数返回给客户端，这就是Server Hello(No.70帧)。 下图就是对1)中Client Hello的回应，由图可以看出，服务端匹配的Cipher Suite是TLS_DHE_RSA_WITH_AES_256_CBC_SHA256：3) 服务器同时会将证书发给客户端(No.73帧)；有时候抓取的包只有Client Hello和Server Hello，而没有再发送证书的，这是SSL/TLS的Session重用了：由于新建立一个SSL/TLS Session的成本太高，所以之前有建立SSL/TLS连接Session的话，客户端会保存Session ID，在下一次请求时在Client Hello中带上，服务端验证有效之后，就会成功重用Sesssion。拓展阅读：RFC5246#Handshake Protocol Overview查看Handshake的流程和相关信息。Apple官方开发文档：TLS Session Cache4) 客户端确认证书有效，则会生产最后一个随机数(Premaster secret)，并使用证书的公钥RSA加密这个随机数，发回给服务端。为了更高的安全性，会改为Diffie-Hellman算法（简称DH算法）；采用DH算法，最后一个随机数(Premaster secret)是不需要传递的，客户端和服务端交换参数之后就可以算出。Client Key Exchange(No. 75帧)；5) 接下来双方都会发送Change Cipher Spec通知对方，接下来的所有消息都会使用签名约定好的密钥进行加密通信。6) 最后是双方的Finished Message（即Encrypted Handshake Message， No. 77、79帧），这个消息是最终的校验，里面包含了握手过程中的Session Key等信息，如果对方能够解密这个消息则表示握手成功，结束整个SSL Handshake流程。掌握了SSL/TLS握手流程之后，调试SSL/TLS就会变得非常简单，只需要看在哪个环节报错(Alert)，就可以基本推断出相关的错误。相关SSL/TLS接口信息，请查看：RFC5246以及SSL/TLS in Detail下面就列举下调试适配ATS过程中遇到的主要问题：1) 加密套件（Cipher Suite）等参数无法匹配：加密套件不匹配是最常见的握手失败的例子。在ATS中，可接受的加密套件有包括：TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHATLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHATLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA但往往很多服务器的HTTPS配置很久没有升级，没办法支持这些Cipher Suite；客户端发送Client Hello给服务端，带上支持加密套件参数；服务端查看这些参数，发现一个都不支持，则直接返回Handshake Failure的信息。如下图：一般在接受到客户端发送的Client Hello后返回Handshake Failure，都是因为服务端无法匹配客户端SSL握手参数。至于是不是加密套件这个参数匹配的问题，建议抓取取消ATS了的正常HTTPS请求包进行对比，找出具体不匹配的参数。2) SSL/TLS版本过低，这个也非常常见，但一般会被上一个参数不匹配的错误所掩盖。因为大多数SSL/TLS版本低的服务器HTTPS配置支持的加密套件等参数版本也比较低，而SSL/TLS版本是客户端收到Server Hello之后才验证的，但前面握手失败就走不到这一步了。所以加密套件（Cipher Suite）等参数无法匹配支持，一般也就意味着服务端SSL/TLS版本过低。3) 证书链配置错误：在开发过程中，本人遇到过证书链没有按照顺序进行配置的问题，也遇到过只配置了叶子证书的问题。对于这些问题，可以直接查看SSL握手过程中，服务端返回的Certificate包：上图可以看到证书链Certificates只有一个，这是典型的配置错误。PS：使用Wireshark进行抓包的时候，有时候由于一些HTTPS请求的SSL/TLS版本号太低，Wireshark没办法辨认其是SSL包，而是显示为TCP；此时可以手动来Decode：选择对应的TCP数据帧，右键 -》Decode As -》Transport 选择SSL -》Apply既可。5、后记这个时代，安全重要么？这是我曾常疑惑的。90%以上的大众对安全没有切实的概念，即使安全上了春晚，过了热潮一切又重归原样。特别最近换工作到保险金融类公司，安全问题更是触目惊心。一直相信，人如同一个圆，你知道的越多，学的越深，接触的越广，圆就越大，越知道自己的渺小，越懂得敬畏。这世界永远不会缺少矛和盾，没有“Mission Impossible”，不是么？●本文编号33，以后想阅读这篇文章直接输入33即可。●输入m可以获取到全部文章目录
觉得不错，分享给更多人看到
黑客技术与网络安全 微信二维码
分享这篇文章
黑客技术与网络安全 最新头条文章
黑客技术与网络安全 热门头条文章}