Https 与 iOS 信息安全

转载自：swift-cafe

什么是
Https

咱们从最直观的说起。 我们平时在用电脑访问网页的时候，有时候会在地址栏的左边多出一个小锁的图标，就像这样：

这是大多数主流浏览器的一个通用做法，当我们看到这个锁的时候，基本上就说明我们访问的这个网站是基于 Https 协议的了。

那么 Https 到底和我们熟知的 Http 有什么区别呢？ 主要的区别就是信息的安全加密。 使用 Https 传输的数据是经过加密的， 而 Http 不会加密。

那么为什么需要对网络请求加密呢？ 这就涉及到互联网的基本原理了。 大家知道，客户端的一个网络请求发出去，不是直接送达到我们的服务器的。 这中间要经过很多环节， 比如路由器，网关，运营商的基站等等。

我们的一个网络请求发出去，其实是这样一个流程：

如果是基于 Http 协议，那么我们网络通信的内容，除了终端和服务器之外，中间经过的所有路由器或者其他节点都是可以看到的。甚至它们还可以篡改这些信息。

这样说起来可能有些抽象，还是举一个通俗的例子， 比如访问我们的网站 swiftcafe.io，采用 Http 的流程是这样，客户端发送 Http 请求，包含了我们访问的 url， 比如这篇文章的地址。

当服务器收到这个请求的时候，根据它的规则给我们返回相应的内容，在我们这里就是这个地址的页面信息。 但由于是基于 Http 协议，无论是我们发送的请求内容，还是服务器返回的响应内容，都是可以被中间节点修改的。 假设途径某个路由器，它在服务端响应的网页内容中又注入它自己的内容，比如一段广告的 html 代码。那么最终返回给我们客户端的就不是服务器原本希望我们看到的内容了。 而是被这个中间路由器加了广告的页面了。

大家仔细想想，是不是在我们平时上网的时候，或多或少会遇到过这种情况呢，这个时候我们的信息其实就已经被监听和篡改了。被偷偷的加了广告还算是好的，甚至有些时候用户的一些隐私信息也会被这样偷走。

还是用一张图来表示：

Https
实现原理

如果你是第一次了解这个原理，会不会觉得自己在上网的时候时刻处在危机中呢？ 反正我是这样~，目前互联网上，大多数网站还都是基于 Http 协议的。尤其是国内的互联网。那么为什么当初会有 Http 这样不安全的协议呢？

我想主要原因是互联网刚刚诞生的时候，网站的逻辑都很简单，那时候大多数网站都只是一个简单的信息展现，并不涉及太多的交互和隐私数据。而且 Http 协议相比之下性能消耗小，协议实现起来简单，所以在那个时代 Http 是主流的应用。可随着互联网应用的形式发展的越来越快，现在的网站交互行为越来越多，涉及用户隐私的地方也越来越多，以及近几年移动互联网的兴起，还有 App 的数据接口也需要安全处理。这时 Http 协议就已经不太符合我们现在对于安全的需求了。 这也是 Https 开始应用的原因。

现在支持 Https 的网站已经越来越多了。 这也会是未来的一个趋势。

证书验证

现在我们就来了解一下 Https 的基本原理。

Https 是一种基于证书的加密连接。 应用服务器首先会向证书颁发机构申请一个数字证书。这个证书颁发机构一般是一些比较大的组织，比如 Godaddy, Comodo, Symantec 这些公司。

当我们客户端访问 https:// 开头的地址的时候。先会和服务器进行一次 "握手操作"。 服务器会把它的证书返回给客户端，比如我们电脑上的浏览器。

然后客户端会验证这个证书是不是可信任的，如果是可信任的才会进行下一步操作。

那么问题来了，什么样的证书才是可信任的呢， 这就涉及到证书的数字签名过程了。 我们前面提到的证书颁发机构都会有一个根证书，根证书上面会有两个秘钥，一个公钥一个私钥。公钥是公开的，而私钥只有颁发机构才会知道。 然后证书颁发机构会用根证书的私钥为它签发的子证书中的整体内容进行加密，然后生成数字签名，并且包含到这个子证书中，同时子证书中也会包含自己的公钥和私钥。 这样一来，我们在进行 Https 握手的时候，服务器发送给我们的证书中会带有数字签名， 我们在用颁发机构的公钥对数字签名进行解密，如果解密后的内容和证书本身的内容能够完全匹配，那么我们就可以信任这个证书了。

因为数字签名只有证书颁发机构用它的私钥才能够生成，所以第三方是不能伪造的，除非它能知道颁发机构的私钥。公钥-私钥的这种加密方式，我们称之为非对称加密。也就是说加密和解密过程使用的密钥是不同的。

通信加密

那么客户端验证成功后，接下来会做什么呢。由于非对称加密会比较消耗性能，我们只在握手的时候才会进行非对称加密，此后的 Https 消息中，我们还是采用对称加密的形式。

客户端在验证证书可信后，紧接着会生成一个对称加密的密钥，然后用这个证书的公钥对这个生成的秘钥再进行加密，发送给服务器。 当服务器接到这个加密的信息后，用它自己的私钥进行解密，这样就得到了此后的对称加密算法的秘钥了。又由于服务器证书的私钥只有服务器自己知道，中途的其他节点即便获取到了这段信息，也没办法解密出来。这样就保证了我们此后的对称加密的密钥不会被第三方截获。

上几张图就更明白了：

怎么样明白了吧。 没关系，没明白再仔细看看， 会明白的~ Https 协议的设计非常有艺术性，上面两幅图基本就是 Https 的握手过程了。 握手过后，客户端和服务器都拥有了对称加密的密钥，而这个对称加密的密钥是基于非对称加密的方式传输的。总之就是，这个密钥除了客户端和服务器，其他中间节点是无法知道的。

握手过后，接下来的网络请求的格式和基本的 Http 就没什么区别了，只是将所有的消息用对称加密的密钥进行加密，然后服务器再进行解密了。 因为这个密钥不会被第三方知道， 所以你们的通信就是安全的。

结尾

经过这么一番论述，我们把 Https 的基本原理，以及为什么要使用 Https 都和大家介绍了。 当然， Https 的很多实现细节我们这里并没有深入的讨论，而且任何一个安全机制也都不一定绝对安全。 但 Https 确实能够在很大程度上保护用户的隐私信息。接下来，我会和大家一起讨论在 iOS 中如何处理 Https 相关操作的方法。