iOS ：HTTPS简析

前言

App的安全问题是咱们在开发过程当中每一个人都会遇到的，而因为iOS平台的封闭性，遭遇到的安全问题相比于Android来讲要少得多。但除系统安全以外，咱们仍是面临不少的安全问题：好比网络安全，下面就简单的了解一下HTTPS是怎么处理网络安全问题的。

HTTPS

下面就来了解一下HTTPS;😺

HTTPS的重要性

咱们知道HTTP自己是不具有加密功能的，因此也没法作到对通讯总体(使用 HTTP 协议通讯的请求和响应的内 容)进行加密。即，HTTP 报文使用明文方式发送。但是不光在HTTP协议中，在其余未加密的协议中都会存在相似问题：

1️⃣：通讯过程当中使用的是未加密的明文，内容会被取抓。

2️⃣：对于服务器或者客户端来讲，不会验证通讯方的身份，所以有可能遭到中间人的假装。

3️⃣：没法验证所发送报文的完整性和安全性，并且报文的内容也有多是中间人篡改以后发送过来的。

为了统一解决上述这些问题，须要在 HTTP 上再加入加密处理和认证等机制。咱们把添加了加密及认证机制 的 HTTP 称为 HTTPS。HTTPS开发的主要目的，是提供对网络服务器的身份认证，保护交换数据的隐私与完整性。

HTTPS介绍

HTTPS超文本传输安全协议是一种网络安全传输协议。在计算机网络上，HTTPS经由超文本传输协议HTTP进行通讯，但利用SSL/TLS来加密数据包。TLS/SSL全称安全传输层协议Transport Layer Security, 是介于TCP和HTTP之间的一层安全协议，不影响原有的TCP协议和HTTP协议，具备身份验证、信息加密和完整性校验的功能。

以前的 HTTP协议直接放置在 TCP协议之上，而 HTTPS则是在 HTTP和 TCP中间加上一层加密层 SSL。从发送端看，这一层负责把 HTTP的内容加密后送到下层的 TCP，从接收方看，这一层负责将 TCP送来的数据解密还原成 HTTP的内容。因此严格地讲， HTTPS并非一个单独的协议，而是对工做在一加密链接 TLS/SSL上的常规 HTTP协议的称呼。

HTTP + 加密 + 证书 + 完整性保护 = HTTPS

加密方式

在了解HTTPS通讯加密过程以前先来了解几个基本概念：

密钥

密码学中：密钥是一种参数，它是在明文转换为密文或将密文转换为明文的算法中输入的参数。密钥分为对称密钥与非对称密钥。

对称加密(共享密钥加密)

加密和解密同用一个秘钥的方式称为对称加密

也就是说在发送密文的同时，也会把密钥发送给对方。

举个小例子🌰：好比我想寄一些贵重的东西给女友，而后我就搞了个保险柜，而后把物品存在保险柜里（💰💰💰），而后我在锁好保险柜以后，把保险柜邮寄出去，而后把保险柜密码告诉女友，但是不当心隔墙有耳👂，有人听到了这个密码，那么完蛋了，个人保险柜有危险了。这里物品就是明文信息，保险柜就是加密后的密文，保险柜密码就是密钥，你看这样是否是不安全？

⚠️⚠️：注意这里有个危险，若是不发送密钥给对方，对方就没法解密，可是若是在发送密钥的过程当中，密钥有可能会被截获，一旦密钥泄漏，密码也就有可能被破解。那么怎么解决这个问题呢？🤔🤔🤔

那就是下面这个非对称加密了！！！👇👇👇

非对称加密(公开密钥加密)

非对称加密使用一对非对称密钥，一个叫私有密钥，另外一个叫公开密钥公有密钥随意发送，任何人均可以得到，私有密钥不让任何人知道。

也就是说，发送密文方使用对方的公开密钥进行加密，对方接受到加密信息后，再使用本身的私有密钥进行解密。利用这种方式再也不须要发送密钥，也不用担忧密钥被中间人获取。重要的是在不使用私有密钥状况下很难还原被加密的信息。（就比如把熟鸡蛋🥚还原成生鸡蛋🥚）

再来举个例子🌰：通过上次的事情以后，我学聪明了，我买了一个高级的保险柜，这个保险柜有两个密码，一个锁上的密码，一个打开的密码，而后女友设置完这两个密码以后，把锁上的密码告诉我了，而后我把物品装到保险柜以后，再次寄出去，此次就不怕别人知道密码了，由于打开保险柜的密码，只有女友知道，其余人便是知道保险柜锁上的密码也没有任何用。

HTTPS混合加密

从上面咱们能够了解到，对称加密解密的速度比较快，适合数据比较长时的使用，可是缺少安全性，非对称加密和解密花费的时间长、速度相对较慢，只适合对少许数据的使用，可是相对安全，任何一种方式都没法知足HTTPS:因此HTTPS采起混合加密的方式；

利用两种加密方式互补，也就是说，利用非对称加密方式安全地交换在对称密钥加密中要使用的密钥，在确保密钥安全前提下，使用对称密钥加密方式进行通讯。

进行到这里会不会以为一切都结束了，HTTPS安全加密的问题搞定了，其实这里还存在另一个安全隐患😨😨😨：因为公钥是透明公开的，在公钥的传输过程当中，正确的公钥有可能会被中间人攻击而替换掉，则可能形成数据的篡改。那么如何证实收到的公开密钥是本来预想那台服务器发行的密钥呢？🤔🤔🤔

数字证书

为了解决上述问题，可使用由数字证书认证机构(CA，Certificate Authority)和其相关机关颁发的公开密钥证书。 https协议中身份认证的部分是由CA数字证书完成的，证书由公钥、证书主体、数字签名等内容组成。在客户端发起SSL请求后，服务端会将数字证书发给客户端，客户端会对证书进行验证（验证这张证书是不是伪造的？也就是公钥是不是伪造的），若是证书不是伪造的，客户端就获取用于对称密钥交换的非对称密钥（获取公钥）.

数字证书有三个做用：

1️⃣：身份受权，确保浏览器访问的网站是通过CA验证的可信任的网站。

2️⃣分发公钥，每一个数字证书都包含了注册者生成的公钥（验证确保是合法的，非伪造的公钥）。在SSL握手时会经过certificate消息传输给客户端。

3️⃣：验证证书合法性，客户端接收到数字证书后，会对证书合法性进行验证。只有验证经过后的证书，才可以进行后续通讯过程。

那么怎么就能保证这个公开密钥是一个正确的公钥，而不是由中间人伪造的呢？

下面来看一下CA证书的申请流程：

下面经过浏览器看一下 web网站的证书：

这里：

• GlobalSign Root CA是指受信任的根证书颁发机构
• GlobalSign Domain Validation CA - SHA256 - G2 是指受信任的根证书颁发机构下的中级证书颁发机构
• juejin.in是指用户的SSL证书（是在"受信任的根证书颁发机构"下的"中级证书颁发机构"下颁发的证书）

这个三级证书是咱们将本身生成的CSR提交给签名商，他们用中级证书机构的私钥Private Key给咱们的签名成证书。而他们的的证书又是经过Root CA颁发的（即Root CA经过它的私钥对中级机构提交的CSR进行了签名）。

HTTPS通讯机制

通过上面的简单了解，大概已经知道了HTTPS的一个简单流程，在HTTPS的实际应用中，使用的就是数字证书这种校验方式。 下面经过一个流程图来了解一下HTTPS通讯机制：

以上流程图能够总结为一下几个步骤：

1️⃣：客户端发起请求，以明文传输请求信息，包含SSL版本信息，加密套件候选列表，随机数random_c，扩展字段等信息。

2️⃣：服务端返回选择使用的协议版本，选择的加密套件，选择的压缩算法、随机数random_s等，其中随机数用于后续的密钥协商。服务端也会配置并返回对应的证书Certificate，用于身份验证与密钥交换。而后会发送Server Hello Done信息用于通知服务端信息发送结束。

3️⃣：客户端对收到的证书进行校验，校验其合法性。

4️⃣：证书验证合法后， 客户端计算产生随机数字Pre-master Key（预设主密钥），并用服务端证书中的公钥加密，而后发送给服务端。同时客户端会根据已有的三个随机数根据相应的生成协商的通讯密钥（预主密钥+两个随机数经过复杂算法生成真正的传输密钥）。客户端会通知服务端后续的通讯都采用协商的通讯密钥和加密算法进行加密通讯。而后客户端发送Finished消息用于通知客户端信息发送结束。

5️⃣：服务端利用私钥解密获得预主密钥，也会根据已有的两个随机数使用相应的算法生成通讯密钥，而后会通知客户端后续的通讯都采用协商的通讯密钥和加密算法进行加密通讯。而后发送Finished消息用于通知服务端信息发送结束。

6️⃣：客户端和服务器数据传输开始使用通讯密钥进行加密通讯。直到客户端发送断开链接的报文。

为何不一直使用 HTTPS

这里可能会有疑问，既然 HTTPS 那么安全可靠，那什么还会见到有网站使用HTTP呢，为什么全部的 Web网站不一直使用 HTTPS?

由于加密通讯会消耗更多的 CPU及内存资源。若是每次通讯都 加密解密，会消耗至关多的资源。这对于访问量较大的网站来讲是有必定的压力的。所以，若是是非敏感信息则使用 HTTP 通讯，只有在包含我的信息，密码等敏感数据时，才利用 HTTPS 加密通讯。好比http://www.zhenai.com/

除此以外，想要节约购买证书的开销也是缘由之一。 要进行 HTTPS通讯，证书是必不可少的。而使用的证书必须向认证机构(CA)购买。证书价格可能会 根据不一样的认证机构略有不一样。那些购买证书并不合算的服务以及一些我的网站，可能只会选择采用 HTTP的通讯方式。

总结

HTTPS就是要使客户端与服务器端的通讯过程获得安全保证。HTTPS利用非对称加密创建链接，利用对称加密进行数据通讯,数字认证等等，虽然过程很复杂,在保证安全的同时，也提升访问速度。因此为了保证数据的安全，维护网络稳定，仍是要多使用HTTPS协议。 文中若有错误还请各位大佬指出。

感谢《图解HTTP》一书