iOS 中HTTPS 的使用

谣言四起，大限将至。各种谣言皆因苹果开发者大会开始，从那个时间开始，都说2017年1月1日为HPPTS即将开始的日子。从此大航海时代就要开始了。从此就成了我挥之不去的心魔，吓得本大少和服务器端调呀调。总算调好了。好吧，我们聊聊HTTPS。

成都创新互联公司主要从事做网站、网站设计、网页设计、企业做网站、公司建网站等业务。立足成都服务东西湖,十载网站建设经验,价格优惠、服务专业,欢迎来电咨询建站服务:18982081108

HTTPS（全称：Hyper Text Transfer Protocol over Secure Socket Layer），是以安全为目标的HTTP通道，简单讲是HTTP的安全版。即HTTP下加入SSL层，HTTPS的安全基础是SSL，因此加密的详细内容就需要SSL。 它是一个URI scheme（抽象标识符体系），句法类同http:体系。用于安全的HTTP数据传输。https:URL表明它使用了HTTP，但HTTPS存在不同于HTTP的默认端口及一个加密/身份验证层（在HTTP与TCP之间）。这个系统的最初研发由网景公司(Netscape)进行，并内置于其浏览器Netscape Navigator中，提供了身份验证与加密通讯方法。（摘自百度百科）

PKI（公钥基础设施）技术是HTTPS的基础，PKI与非对称密钥加密技术密切相关，包括消息摘要、数字签名和加密服务，而数字证书以及证书机构（CA – Certificate Authority）是PKI中的重要概念。

iOS9中新增App Transport Security（简称ATS）特性, 主要使到原来请求的时候用到的HTTP，都转向TLS1.2协议进行传输。这也意味着所有的HTTP协议都强制使用了HTTPS协议进行传输。

一般我们如果还是使用的http,不更新的话，可通过在 Info.plist 中声明，倒退回不安全的网络请求

首先找后台要一个证书（SSL证书,一般你跟后台说要弄https，然后让他给你个证书，他就知道了），

我们需要的是.cer的证书。但是后台可能给我们的是.crt的证书。

我们需要转换一下：打开终端 - cd到.crt证书路径 - 输入openssl x509 -in 你的证书.crt -out 你的证书.cer -outform der

证书就准备好了，拖入工程，记得选copy。一般叫做servicer.cer

--此段引用自大神 vision_colion 的文章，他文章里面有单向认证的哦。

然后我们还得需要一个client.p12证书.还是问服务器端给。

苹果官方文档

lanp74的博客

iOS中的HTTPS认证

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 算法原理：

如果不清楚上面的计算原理，只需要知道 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 标准： ;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中的鉴权

对于容器而言，这样做是合理的，因为浏览器可能会访问不安全的网站；

疑问：

参考：

iOS HTTPS的基本用法 以及连接建立过程

HTTPS（全称：Hyper Text Transfer Protocol over Secure Socket Layer），是以安全为目标的HTTP通道，简单讲是HTTP的安全版。

即HTTP下加入SSL层，HTTPS的安全基础是SSL，因此加密的详细内容就需要SSL。 它是一个URI scheme（抽象标识符体系），句法类同http:体系。用于安全的HTTP数据传输。

https: URL表明它使用了HTTP，但HTTPS存在不同于HTTP的默认端口及一个加密/身份验证层（在HTTP与TCP之间）。

一、https协议需要到ca申请证书，一般免费证书很少，需要交费。

二、http是超文本传输协议，信息是明文传输，https 则是具有安全性的ssl加密传输协议。

三、http和https使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。

四、http的连接很简单，是无状态的；HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全。

1）HTTPS的主要思想是在不安全的网络上创建一安全信道，并可在使用适当的加密包和服务器证书可被验证且可被信任时，对窃听和中间人攻击提供合理的保护。

2）HTTPS的信任继承基于预先安装在浏览器中的证书颁发机构（如VeriSign、Microsoft等）（意即“我信任证书颁发机构告诉我应该信任的”）。

3）因此，一个到某网站的HTTPS连接可被信任，如果服务器搭建自己的https 也就是说采用自认证的方式来建立https信道，这样一般在客户端是不被信任的。

4）所以我们一般在浏览器访问一些https站点的时候会有一个提示，问你是否继续。

1 客户端打包请求 。

   其中包括URL、端口、账号和密码等。使用账号和密码登陆应该用的是POST方式，所以相关的用户信息会被加载到body中。这个请求应该包含3个方面：网络地址、协议和资源路径。注意：这里用的是HTTPS，即HTTP+SSL/TLS，在HTTP上又加了一层处理加密信息的模块（相当于加了一个锁）。这个过程相当于客户端请求钥匙。

2 服务器端接受请求。

    一般客户端的请求会先被发送到DNS服务器中。DNS服务器负责将网络地址解析成IP地址，这个IP地址对应网上的一台计算机。这其中可能发生Hosts Hijack和ISP failure的问题。过了DNS这一关，信息就到服务器端，此时客户端和服务端的端口之间会建立一个socket连接。socket一般都是以file descriptor的方式解析请求的。这个过程相当于服务器端分析是否要想客户端发送钥匙模板。

3 服务器端返回数字证书。

   服务器端会有一套数字证书（相当于一个钥匙模板），这个证书会先被发送个客户端。这个过程相当于服务端向可独断发送钥匙模板。

4 客户端生成加密信息。

    根据收到的数字证书（钥匙模板），客户端就会生成钥匙，并把内容锁起来，此时信息已经被加密。这个过程相当于客户端生成钥匙并锁上请求。

5 客户端方发送加密信息 。

   服务器端会收到由自己发送的数字证书加密的信息。这个时候生成的钥匙也一并被发送到服务端。这个过程相当于客户端发送请求。

6 服务端解锁加密信息。

     服务端收到加密信息后，会根据得到的钥匙进行解密，并把要返回的数据进行对称加密。这个过程相当于服务器端解锁请求，生成、加锁回应信息。

7 服务器端向客户端返回信息。

     客户端会收到相应的加密信息。这个过程相当于服务器端向客户端发送回应信息。

8 客户端解锁返回信息。

    客户端会用刚刚生成的钥匙进行解密，将内容显示在浏览器上。

以上内容摘自《iOS面试之道》一书，感谢作者。

网站名称：ioshttps开发的简单介绍
本文链接：http://pwwzsj.com/article/dscgsge.html