iOS 9起苹果就开始推荐使用HTTPS，iOS 9中默认是禁止非HTTPS的协议来访问网络的.
2017年1月1日起苹果提出所有新提交的App默认不允许使用NSAllowsArbitraryLoads来绕过ATS的限制。
也就是说强制我们用HTTPS，
是从哪里买的或者是使用限时免费版只要符合苹果官方的证书要求，具体要求参考： Apple-NSAppTransportSecurity 。那么什么都不要设置，只需要启用项目的ATS，就可以HTTPS请求了。。
如果还想添加其它只支持HTTP的请求，按前面Exception Domains的设置即可。
iOS 中会话认证机制共有四种，大体分为两种类型：
枚举类如下：
说明：
HTTPS 通信中一般都是单向认证，这样可以保证数据的加密传输，也能够防止没有证书的钓鱼网站。而双向认证一般用于企业来禁止接口被第三方调用和解析。iOS 中的 NSURLSession 的默认实现、AFN 的默认实现都是单向认证，此时代理方法只会受到一种类型的回调，即： NSURLAuthenticationMethodServerTrust 。
双向认证建立在单向认证的基础上，需要自己去额外实现：
双向认证中代理方法会收到两个类型的回调：
与会话层面的认证机制相对的是特殊任务认证机制：
这些枚举的意义是？？？（见后文）
TLS （Transport Layer Security）就是 SSL（Secure Socket Layer），只不过版本不同而已：
SSL 和 HTTPS 的概念等不再赘述；
HTTPS 中的单向认证流程图如下：
其具体的流程为：
简化版流程图如下：
一般的 HTTPS 请求都采用单向认证，只有极少数对安全性要求很高的企业采用双向认证如金融企业，或者是企业对涉及到核心业务的接口采用双向认证；
单向认证中客户端认证服务端证书的特性就决定了，只要客户端愿意且服务端的证书正常，那么任意客户端都可以访问该服务器；
双向认证中，除了客户端对服务端进行认证，服务端还要对客户端进行认证。因此，服务端对客户端证书的认证逻辑就决定了客户端是被动的，能否访问该服务器完全由服务端决定。有的服务端只是单纯的对客户端证书进行 CA 认证，还有的会对证书的主体进行认证，非白名单内的主体不允许访问服务器；
NTLM 和 Kerberos 用于早期的 Windows 中，本文不做过多了解：
双向认证和白名单有这相同的作用，就是服务端限制某些客户端的访问，白名单机制的存在有这更方面成熟的实现机制，可能这就是双向认证不常用的原因？
是指使用某种算法计算出元数据的哈希值，以此确保元数据没有被篡改，最初的签名算法采用摘要算法，证书体系中的签名采用摘要算法+ 非对称加密的方式进行签名；
因为黑客可以修改元数据的同时修改摘要算法得出的哈希值，所以出现了证书，其目的是通过非对称加密来保证元数据的哈希值不被破解；
证书分为 TBSCertificate（To-Be-Signed） 和 Certificate，即待签名的证书和签名过的证书。TBSCertificate 证书中包含拥有者的各种信息，同时还包含拥有者的公钥。我们一般说的证书是经过签名的，这种证书中除了包含 TBSCertificate ，还会包含签名使用的算法、签名值；
非对称加密效率较低，所以证书的签名一般先对 TBSCertificate 使用摘要算法得到固定长度的哈希值，然后使用私钥对这个哈希值进行非对称加密，最终得到签名，所以证书体系中的签名已经不是单纯的摘要算法了；
最初的证书是自签名证书，拥有者使用自己的私钥对 TBSCertificate 进行签名，如果黑客攻击了证书发送者，并将证书上的公钥替换为自己的公钥，甚至直接将拥有者的私钥给窃取或者替换，那么接收者接收到的也是被篡改过的数据；
自签名证书中，私人的私钥安全性隐患很大，因此才有了权威的 CA 机构，证书体系中默认 CA 机构的安全性不会被破解，所以理论上 CA 的私钥不会被窃取。CA 机构会对个人信息进行验证，并且使用自己的私钥对 TBSCertificate 证书进行签名之后颁发给申请者；
CA 机构的私钥理论上绝对安全，公钥会被嵌入到计算机基础体系中，如被嵌入到 *** 作系统、浏览器中，所以浏览器可以直接使用 CA 的公钥对证书进行验签；
验签的流程就是先提取签名时使用的签名算法（signatureAlgorithm），这里主要是要知道签名时摘要算法采用的哪一种。然后提取出 TBSCertificate，使用摘要算法对 TBSCertificate 进行哈希，得到 Hash1。接着，使用 CA 公钥对签名值（signatureValue）进行解密，得到 Hash2，如果 Hash1 = Hash2，则证书校验成功；
至此，CA + 非对称加密 + 摘要算法就组成了证书体系；
Root CA 基本上就那几个，他们的公钥会被嵌入到计算机基础体系中。如果直接使用 Root CA 的公钥进行签发，那么一旦 Root CA 的私钥发生变化，如撤销、过期等，牵连范围极大。
所以 intermediate CA 出现了， intermediate CA 作为 Root CA 的代理，先向 Root CA 申请证书，其流程和上面的基本一致， intermediate CA 将自己的信息和公钥发送给 Root CA ，Root CA 验证信息后颁发 TBSCertificate 并使用自己的私钥进行签名，最后颁发给 intermediate CA；
Root CA 只对 intermediate CA 颁发证书， intermediate CA 使用自己的私钥对申请者的证书进行签名，这样就实现了代理的作用；
一张图做总结：
首先，三个随机数的正常使用流程如下：
最终客户端和服务端都有三个随机数，然后根据三个随机数使用协议中的算法计算出一个 master_random，后续都使用 master_random 对报文进行对称加密之后传输；
这里有几个重点：
要回答这两个问题，这里就涉及到 HTTPS 中计算对称加密最终 key 的两种算法：
如果只是用一个随机数，这个随机数由客户端生成之后，使用 RSA 加密之后传送给服务端，服务端和客户端都是用这个随机数作为对称加密的 key 进行对称加密，这种情况有两个问题：
流程如下：
HTTPS 中的 RSA 加密，通过 premaster_random 这一个随机数来计算 master_random 的算法就是只使用一个随机数，并且使用 RSA 加密传输。
这种算法存在上述两个问题，因此，开发出了 DH 算法，现在 HTTPS 一般通过 DH 算法计算最后的 master_random；
很显然，除非中间人攻击，即便知道g、p，窃取到X1、X2，也很那倒推出来P1、P2，也就没法计算出最后密钥。
流程如下：
DH 算法原理： https://blog.csdn.net/mrpre/article/details/52608867
如果不清楚上面的计算原理，只需要知道 DH 算法通过 3 个随机数来计算最终的 master_random 作为对称加密的 key，解决了伪随机数不一定随机的问题，还解决了 RSA 加密的向前攻击的问题；
为什么需要三个随机数，总结：
附-破解 HTTPS 的三种方法：
TCP报文格式：
序号：seq，用来标识从TCP源端向目的端发送的字节流。tcp中传输数据时，会把数据中的每个字节用序号进行标志，确保数据按顺序传输
确认号：ack，小写的。只有ACK标志位为1时，确认序号字段才有效，ack=Seq+1。确认方Ack=发起方Req+1，无论哪一端的确认号都是如此。比如A向B发送建立连接的请求时，seq=x，B回复的报文中 ACK 标志位为1，且确认号就是ack=x+1，表示收到了序列号为x的报文。
标志位：表示报文的六种格式，为1时才有效，默认为0；注意，ACK是标志位，而ack是确认号。
（A）URG：紧急指针（urgent pointer）有效。
（B）ACK：确认序号有效。
（C）PSH：接收方应该尽快将这个报文交给应用层。
（D）RST：重置连接。
（E）SYN：发起一个新连接。
（F）FIN：释放一个连接。
四次分手：
完整的通信流程：
总结：网络存在延迟、丢失的情况，两次握手会导致服务端开启多个无效连接，进而导致服务端在传送数据但是客户端并没有连接上的情况，而四次握手又多余了。
总结：客户端请求断开连接时，server有可能存在未发送完毕的数据，这种特性导致server将ACK和FIN报文分开发送，所以就会出现比三次握手时多一次的报文，三次握手时，server将ACK和SYN合并发送了；
结果：客户端和服务端的 master_random 是相同的，后面都使用这个数字作为对称加密的 key 来对数据进行对称加密之后进行传输；
ATS，即 App Transport Security，ATS 默认情况下要求 App 所有的请求都使用 HTTPS 连接，且对 HTTPS 认证中的摘要算法版本、对称算法版本等进行要求。Apple 利用自己的强势地位推动了客户端的安全性。
如果不额外在 info.plist 中设置 ATS，那么就相当于开启 ATS。
此时，所有的连接/请求都会被 ATS 机制拦截并使用 ATS 中默认的设置来进行连接的认证和建立，符合 ATS 要求的请求才能够通过，否则会被拒绝，ATS 默认策略的检测包括且不限于：
最常用的两个设置就是 NSAllowsArbitraryLoads 和 NSAllowsArbitraryLoadsInWebContent 。两者组合时，会根据版本的不同（是否大于 iOS10）而有不同的表现。鉴于现在的 iOS9 版本已经很少了，可以直接使用 iOS10 的版本，两个设置的优先级： NSAllowsArbitraryLoadsInWebContent > NSAllowsArbitraryLoads 。即设置了前者之后，后者会被忽略；
如果需要完全关闭 ATS，需要设置 NSAllowsArbitraryLoads = YES ，并且在提交审核时进行说明。
对于浏览器类 App，如果只是允许浏览器中使用非安全的请求(HTTP)，那么只需要设置 NSAllowsArbitraryLoadsInWebContent = YES 即可。
另外，还可以使用 NSExceptionDomains 来设置允许 HTTP 请求的白名单域名，这种设置相对于直接关闭 ATS 更容易过审，使用如下：
可以直接使用该网站来检测所请求的域名是否符合 ATS 标准： https://myssl.com/ats.html?domain=mobi.yocaigs.com&port=443
如图：
综上，如果公司使用的证书是 CA 申请下来的，且服务器端支持的加密算法符合 ATS 的要求，那么无论是 NSURLSession 还是 AFNetworking，都是可以直接进行网络请求的，Apple 已经完成了 HTTPS 中客户端对服务器证书的验证 *** 作，不需要开发者额外实现而且安全性能够得到保证。
所以，ATS 是 Apple 对客户端请求的安全标准和实现（封装）；
此种模式下，App 需要验证证书的签名，步骤如下：
使用签名校验的方式有一个缺点：
而公钥验证可以规避掉这个缺点，起流程如下：
我们在制作证书密钥时，公钥在证书的续期前后都可以保持不变（即密钥对不变），所以可以避免证书有效期问题；
如果采用证书锁定方式（Certificate Mode），则获取证书的摘要 hash，以 infinisign.com 为例：
所以其中的 wLgBEAGmLltnXbK6pzpvPMeOCTKZ0QwrWGem6DkNf6o= 就是我们将要进行证书锁定的指纹 (Hash) 信息。
如果采用公钥锁定方式（PublicKey Mode），则获取证书公钥的摘要hash，以 infinisign.com 为例
所以其中的 bAExy9pPp0EnzjAlYn1bsSEGvqYi1shl1OOshfH3XDA= 就是我们将要进行证书锁定的指纹 (Hash) 信息。
见文章： AFN中的鉴权
对于容器而言，这样做是合理的，因为浏览器可能会访问不安全的网站；
疑问：
参考：
所谓应用传输安全（App Transport Security，以下简称ATS）是一项提高了应用和web服务之间连接安全的特性。该特性由一些默认的连接要求组成，遵守这些要求可以获得最佳的安全连接实践。应用可以重载这些默认行为并且关闭传输安全。ATS在iOS 9及以后版本和OS X 10.11及以后版本可用。
中文名
应用传输安全
外文名
ATS
App Transport Security
默认行为例外情况TA说
默认行为
ATS在iOS 9及以后版本和OS X 10.11及以后版本可用。
在为iOS 9.0及以后版本和OS X10.11及以后版本编译的应用中，所有使用NSURLConnection, CFURL, 或 NSURLSession的连接都使用ATS默认行为。不遵守这些要求的连接将会失败。关于各种连接方法的更多信息请参考《NSURLConnection Class Reference》,《CFURL Reference》, 和 《NSURLSession Class Reference》。
以下是ATS的要求：
· 服务器必须至少支持TLS协议的1.2版本。
· 连接密码仅限于提供正向加密的密码（参见下面的密码列表）。
· 证书必须使用SHA256或更好的签名哈希算法进行签名，使用2048位或更高的RSA密钥，或者256位或更高的Elliptic-Curve (ECC)密钥。无效的证书将导致失败并断开连接。
以下是可接受的密码：
· TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
· TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
· TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
· TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
· TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
· TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
· TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
· TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
· TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
· TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
· TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
例外情况
你可以在你的App或App扩展的Info.plist文件中指定默认行为的例外情况。使用属性列表的特殊键就可以指定例外或关闭ATS。表1-1展示了这些键和它们的类型，并使用缩进指明了其结构。
分享你的世界
我要分享见解，
点击发布
纠错
大家还在搜
新款凯迪拉克
凯迪拉克报价
ats报价
凯迪拉克ats
ats汽车
ats优惠
ats上市
ats团购
广告
颜值主播邀你听歌，上YY甜蜜共唱
相关推荐
一分钟了解凯迪拉克ats
00:47
秒懂百科
7793
词条贡献者
该词条共有4人参与编辑，查看全部
词条有帮助，感谢贡献者
意见反馈权威合作百科协议
百度百科是免费编辑平台，无收费代编服务 | 详情
Baidu 京ICP证030173号
编辑
传视频
TA说
目录
在
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）