苹果ATS安全标准之HTTPS 证书验证浅析（上）

在WWDC16中，苹果公布：2017年1月1日IOS将实施ATS安全标准，如未达到ATS安全标准的所有APP将被App Store拒绝上线。为了给广大开发者适应新的规则，在2016年底，苹果公司宣布延期实行ATS标准。但IOS实行ATS标准已经成为了不可逆转的事实。

ATS安全标准要求所有新提交的 App 使用系统组件进行的 HTTP 网络请求都需要是 HTTPS 加密的，否则会导致请求失败而无法通过审核。

HTTPS 概要

HTTPS 是运行在 TLS/SSL 之上的 HTTP，与普通的 HTTP 相比，在数据传输的安全性上有很大的提升。
要了解它安全性的巧妙之处，需要先简单地了解对称加密和非对称加密的区别：

• 对称加密只有一个密钥，加密和解密都用这个密钥；
• 非对称加密有公钥和私钥，私钥加密后的内容只有公钥才能解密，公钥加密的内容只有私钥才能解密。

为了提高安全性，我们常用的做法是使用对称加密的手段加密数据。可是只使用对称加密的话，双方通信的开始总会以明文的方式传输密钥。那么从一开始这个密钥就泄露了，谈不上什么安全。所以 TLS/SSL 在握手的阶段，结合非对称加密的手段，保证只有通信双方才知道对称加密的密钥。大概的流程如下：

TSL:SSL_handshake.png

所以，HTTPS 实现传输安全的关键是：在 TLS/SSL 握手阶段保证仅有通信双方得到 Session Key！

TLS/SSL协议通常分为两层：TLS记录协议(TLS Record Protocol)和TLS握手协议(TLS Handshake Protocol)。 TLS记录协议建立在可靠的传输协议（如TCP）之上，为高层协议提供数据封装、压缩、加密等基本功能的支持。TLS握手协议建立在记录协议之上，用于在实际的数据传输开始前，通讯双方进行身份认证、协商加密算法、交换加密密钥等。除了这俩协议以外，还存在其它三种辅助协议： Changecipher spec 协议用来通知对端从handshake切换到record协议(有点冗余，在TLS1.3里面已经被删掉了)。alert协议，用来通知各种返回码。application data协议，就是把http，smtp等的数据流传入record层做处理并传输。

想象一种场景：通常我们会访问HTTPS://xxx的网站，当你在浏览器地址栏输入支持HTTPS协议的URL地址后，服务器返回的数据会显示在页面上。对于不了解HTTPS协议工作原理的小伙伴可能觉得这个过程很简单：发送请求－服务器响应请求－结果返回并显示。但对于HTTPS而言，在整个发送请求返回数据过程中还涉及到通讯双方证书验证、数据加密、数据完整性校验等。

下面以登录qq邮箱为例，通过Wireshark抓包可以看到如下图：

在浏览器与服务器进行Application Data传输之前，还经历了Client Hello－Server Hello－Client Key Exchange－Change Cipher Spec等过程。而这些过程正是TLS/SSL提供的服务所决定的：

• 认证服务器身份，确保数据发送到正确的服务器；
• 加密数据以防止数据中途被窃取；
• 维护数据的完整性，确保数据在传输过程中不被改变。

上述单向验证的完整握手过程，总结如下：

第一阶段：ClientHello

客户端发起请求，以明文传输请求信息，包含版本信息，加密套件候选列表，压缩算法候选列表，随机数random_C，扩展字段等信息。

第二阶段：ServerHello－ServerHelloDone

如上图可以看出这个阶段包含4个过程( 有的服务器是单条发送，有的是合并一起发送)。服务端返回协商的信息结果，包括选择使用的协议版本，选择的加密套件，选择的压缩算法、随机数random_S等，其中随机数用于后续的密钥协商。服务器也会配置并返回对应的证书链Certificate，用于身份验证与密钥交换。然后会发送ServerHelloDone信息用于通知服务器信息发送结束。

第三阶段：证书校验

在上图中的5-6之间，客户端这边还需要对服务器返回的证书进行校验。只有证书验证通过后，才能进行后续的通信。(具体分析可参看后续的证书验证过程)

第四阶段：ClientKeyExchange－Finished

服务器返回的证书验证合法后， 客户端计算产生随机数字Pre-master，并用server证书中公钥加密，发送给服务器。同时客户端会根据已有的三个随机数根据相应的生成协商密钥。客户端会通知服务器后续的通信都采用协商的通信密钥和加密算法进行加密通信。然后客户端发送Finished消息用于通知客户端信息发送结束。

第五阶段：服务器端生成协商密钥

服务器也会根据已有的三个随机数使用相应的算法生成协商密钥，会通知客户端后续的通信都采用协商的通信密钥和加密算法进行加密通信。然后发送Finished消息用于通知服务器信息发送结束。

第六阶段：握手结束

在握手阶段结束后，客户端和服务器数据传输开始使用协商密钥进行加密通信。

总结

简单来说，HTTPS请求整个过程主要分为两部分。一是握手过程：用于客户端和服务器验证双方身份，协商后续数据传输时使用到的密钥等。二是数据传输过程：身份验证通过并协商好密钥后，通信双方使用协商好的密钥加密数据并进行通信。在握手过程协商密钥时，使用的是非对称密钥交换算法，  密钥交换算法本身非常复杂，密钥交换过程涉及到随机数生成，模指数运算，空白补齐，加密，签名等操作。在数据传输过程中，客户端和服务器端使用协商好的密钥进行对称加密解密。

二、证书

PKI (Public Key Infrastructure)，公开密钥基础设施。它是一个标准,在这个标准之下发展出的为了实现安全基础服务目的的技术统称为PKI。 权威的第三方机构CA(认证中心)是PKI的核心， CA负责核实公钥的拥有者的信息，并颁发认证”证书”，同时能够为使用者提供证书验证服务。 x.509是PKI中最重要的标准，它定义了公钥证书的基本结构。

• 证书申请过程
• 证书申请者向颁发证书的可信第三方CA提交申请证书相关信息，包括：申请者域名、申请者生成的公钥(私钥自己保存)及证书请求文件.cer等
• CA通过线上、线下等多种手段验证证书申请者提供的信息合法和真实性。
• 当证书申请者提供的信息审核通过后，CA向证书申请者颁发证书，证书内容包括明文信息和签名信息。其中明文信息包括证书颁发机构、证书有效期、域名、申请者相关信息及申请者公钥等，签名信息是使用CA私钥进行加密的明文信息。当证书申请者获取到证书后，可以通过安装的CA证书中的公钥对签名信息进行解密并与明文信息进行对比来验证签名的完整性。

证书验证过程

• 验证证书本身的合法性（验证签名完整性，验证证书有效期等）
• 验证证书颁发者的合法性（查找颁发者的证书并检查其合法性，这个过程是递归的）

证书验证的递归过程最终会成功终止，而成功终止的条件是：证书验证过程中遇到了锚点证书，锚点证书通常指：嵌入到操作系统中的根证书(权威证书颁发机构颁发的自签名证书)。

证书验证失败的原因

• 无法找到证书的颁发者
• 证书过期
• 验证过程中遇到了自签名证书，但该证书不是锚点证书。
• 无法找到锚点证书(即在证书链的顶端没有找到合法的根证书)
• 访问的server的dns地址和证书中的地址不同

GDCA致力于网络信息安全，已通过WebTrust 的国际认证，是全球可信任的证书签发机构。其自主品牌——信鉴易 TrustAUTH  SSL证书：包括 OVSSL、EVSSL、代码签名证书等。为涉足互联网的企业打造更安全的生态环境，建立更具公信力的企业网站形象。GDCA专业技术团队将根据用户具体情况为其提供最优的产品选择建议，并针对不同的应用或服务器要求提供专业对应的HTTPS解决方案。

文章来源：腾讯Bugly