iOS 之网络安全HTTPS

HTTP 缺点

1. 通信使用明文（不加密），内容可能会被窃听

由于HTTP 本身不具备加密的功能，所以也无法做到对通信整体（使用HTTP 协议通信的请求和相应的内容）进行加密。窃听通信并非难事，只需要收集在互联网上流动的数据包（帧）就行了。对于收集来的数据包解析的工作，可以交给抓包工具（Charles）

2. 不验证通信方的身份就可能遭遇伪装

任何人都已发起请求，HTTP 协议通信时，不存在确认通信方的处理步骤。服务器只要接收到请求，不管对方是谁都会返回一个响应（但也仅限于发送端的IP 地址和端口号没有被Web 服务器设定限制访问的前提下）

3. 无法证明报文完整性，可能已遭篡改

完整性是指信息的准确度，若无法证明其完整性，通常也就意味着无法判断信息是否准确。

比如，从某个Web 网站上下载内容，是无法确定客户端下载的文件和服务器上存放的文件是否前后一致的。文件内容在传输途中可能已经被篡改为其他的内容。即使内容真的以改变，作为接收方的客户端也是觉察不到的，这个情况称为中间人攻击

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

为了解决上述问题，需要在HTTP 上再加入加密处理和认证的机制。我们把添加了加密及认证机制的HTTP 称为HTTPS。

HTTPS 并非是应用层的一种新协议。只是HTTP 通信接口部分用SSL（Secure Socket Layer）和TLS（Transport Layer Security）协议代替而已。通常HTTP 直接和TCP 通信，当使用SSL 时，则变成先和SSL通信，再由SSL 和TCP通信了。所以HTTPS 实际是身披SSL 协议这层外壳的HTTP。

加密方式

1. 对称加密

加密和解密同用一个密钥的方式称为对称加密。所以客户端和服务端可以采用同一个密钥的方式对通信内容进行加密解密，但是有一个问题，这个密钥在传输时也可能被中间人获取，中间人可以将其换成自己的密钥，也就失去了加密的意义。怎么才能安全的转交这个密钥呢？

2. 非对称加密

非对称加密使用了两个密钥，一个称为公钥，可以随意对外公布，另一个称为私钥，自己保留，不能让其他人知道。私钥加密的内容只有公钥才能解开，反之公钥加密的内容只有私钥才能解开。

另外如果想要根据公钥和密文恢复信息原文是异常困难的，因为解密过程就是在对离散对数进行求值，这并非轻而易举就能办到的。

HTTPS 采用混合加密机制

为什么不单独使用非对称加密？因为非对称加密的方式要比对称加密的方式更为复杂，所以应充分利用两者的优势。用非对称加密的方式来安全传输对称加密的密钥，之后建立的通信交换报文阶段则使用对称加密的方式。

但是这里又有个问题，非对称加密的公钥要怎么安全传输？因为公钥传输的过程中，可能已经被攻击者替换掉了。

数字证书

为了解决这个问题，我们使用了由权威数字证书认证机构（CA，Certificate Autority）颁发的数字证书。该证书包含了持有者的信息、公钥以及证明该证书有效的数字签名。一般是由服务器发给客户端，接收方通过验证这个证书是不是由信赖的CA 签发，或者与本地的证书相对比，来判断证书是否可信；假如需要双向验证，则服务器和客户端都需要发送数字证书给对方验证。

怎么来验证数字证书是由CA签发的，而不是第三方伪造的呢？

在回答这个问题前，我们需要先了解CA 的组织结构。首先，CA组织结构中，最顶层的就是根CA，根CA 下可以授权给多个二级CA，而二级CA 又可以授权多个三级CA，所以CA 的组织结构是一个树结构。对于SSL证书市场来说，主要被Symantec(旗下有VeriSign和GeoTrust)、Comodo SSL、Go Daddy 和 GlobalSign 瓜分。
了解了CA的组织结构后，来看看数字证书的签发流程：

image

数字证书的签发机构CA，在接收到申请者的资料后进行核对并确定信息的真实有效，然后就会制作一份符合X.509标准的文件。证书中的证书内容包含的持有者信息和公钥等都是由申请者提供的，而数字签名则是CA机构对证书内容进行hash加密后得到的，而这个数字签名就是我们验证证书是否是有可信CA签发的数据。

image

假设上图证书是由证书签发机构CA1签发的。

1. 接收端接到一份数字证书Cer1后，对证书的内容做Hash得到H1；
2. 从签发该证书的机构CA1的数字证书中找到公钥，对证书上数字签名进行解密，得到证书Cer1签名的Hash摘要H2；
3. 对比H1和H2，如相等，则表示证书没有被篡改。
4. 但这个时候还是不知道CA是否是合法的，我们看到上图中有CA机构的数字证书，这个证书是公开的，所有人都可以获取到。而这个证书中的数字签名是上一级生成的，所以可以这样一直递归验证下去，直到根CA。根CA是自验证的，即他的数字签名是由自己的私钥来生成的。合法的根CA会被浏览器和操作系统加入到权威信任CA列表中，这样就完成了最终的验证。所以，一定要保护好自己环境（浏览器/操作系统）中根CA信任列表，信任了根CA就表示信任所有根CA下所有子级CA所签发的证书，不要随便添加根CA证书。

一般操作系统和浏览器只包含根CA机构的证书，而在配置Web服务器的HTTPS时，也会将配置整个证书链，所以整个校验流程是从最后的叶子节点证书开始，用父节点校验子节点，一层层校验整个证书链的可信性。

HTTPS 验证流程

image

1. 客户端发起一个HTTPS 的请求，把自身支持的SSL 的指定版本、加密算法发送给服务端

2. 服务端接收到后与自身支持的对比，如果不支持则连接断开，反之则会从中选出一种加密算法和HASH算法以证书的形式返回给客户端，证书中还包含了公钥、颁证机构、网址、失效日期等等。

3. 客户端收到服务端响应后会做以下几件事

   • 验证证书的合法性
     颁发证书的机构是否合法与是否过期，证书中包含的网站地址是否与正在访问的地址一致等，证书验证通过后，在浏览器的地址栏会加上一把小锁(每家浏览器验证通过后的提示不一样 不做讨论)

   • 生成随机密码
     如果证书验证通过，或者用户接受了不授信的证书，此时浏览器会生成一串随机数，然后用证书中的公钥加密。

   • Hash 握手信息
     用最开始约定好的Hash 方式，把握手消息取Hash 值，然后用随机数加密"握手消息+握手消息Hash值(签名)" 并一起发送给服务端

     在这里之所以要取握手消息的Hash 值，主要是把握手消息做一个签名，用于验证握手消息在传输过程中没有被篡改过。

4. 服务端拿到客户端传来的密文，用自己的私钥来解密握手消息取出随机数密码，再用随机数密码 解密 握手消息与Hash 值，并与传过来的Hash 值做对比确认是否一致。然后用随机密码加密一段握手消息(握手消息+握手消息的HASH值 )给客户端

5. 客户端用随机数解密并计算握手消息的HASH，如果与服务端发来的HASH一致，此时握手过程结束，之后所有的通信数据将由之前浏览器生成的随机密码并利用对称加密算法进行加密，因为这串密钥只有客户端和服务端知道，所以即使中间请求被拦截也是没法解密数据的，以此保证了通信的安全

非对称加密算法：RSA，DSA/DSS 在客户端与服务端相互验证的过程中用的是对称加密
对称加密算法：AES，RC4，3DES 客户端与服务端相互验证通过后，以随机数作为密钥时，就是对称加密
HASH算法：MD5，SHA1，SHA256 在确认握手消息没有被篡改时

总结HTTPS

HTTPS要使客户端与服务器端的通信过程得到安全保证，必须使用的对称加密算法，但是协商对称加密算法的过程，需要使用非对称加密算法来保证安全，然而直接使用非对称加密的过程本身也不安全，会有中间人篡改公钥的可能性，所以客户端与服务器不直接使用公钥，而是使用数字证书签发机构颁发的证书来保证非对称加密过程本身的安全。这样通过这些机制协商出一个对称加密算法，就此双方使用该算法进行加密解密。从而解决了客户端与服务器端之间的通信安全问题。

作者：郑嘉成_
链接：https://www.jianshu.com/p/0db870cad611
来源：
著作权归作者所有，任何形式的转载都请联系作者获得授权并注明出处。