WWDC 2017：Your Apps and Evolving
本文首发于《iOS 成长之路》，购买可查看更多 WWDC 系列文章，转载请联系作者。
现在，我们越来越关注用户的隐私和信息安全，但是随着时间的推移，计算机变得越来越高效，那些年代久远的网络协议和加密算法，在新的硬件和攻击方式下，变得岌岌可危。
针对网络安全，我们要怎样做？
- 时刻关注 App 的安全，保证 App 的及时更新
- 了解业界的发展变化，跟进最新的标准、学术研究和工业界的实践
- 确保集成的第三方库可以得到及时的更新，避免安全隐患
- OS 移除安全隐患
- 使用 ATS（App Transport Security），ATS 会强制在 App 中使用最佳实践
- 相比被攻击后的严重后果，前期投入一定的维护成本是值得的
常见的网络攻击
这里总结了一些常见的网络攻击，它们针对的对象有所不同，有的是想窃取数据，有的是想伪装身份，它们在图中以颜色进行区分。我将会通过一些实践来告诉你，如何去避免这些攻击，具体来说就是关于加密（encryption）、密码散列（cryptographic hashes）、公共密钥（public keys）、网络协议（protocols）、证书吊销检查（revocation）等内容的一些实践。
TLS 协议
现在大多数的 App 网络都已经切换到 HTTPS 了，HTTPS 其实就是在 HTTP 下加入了 TLS 层，TLS 是保证网络安全的基础，它可以对传输内容加密、进行身份验证、避免传输内容被篡改。
TLS 协议是由 TLS 握手协议和 TLS 记录协议两部分组成，TLS 记录协议负责对传输内容加密，TLS 握手协议又分为四个子协议，负责协商加密算法、共享密钥、传达警告等工作。
TLS 协议中涉及到多种不同的密码技术，比如在握手协议中使用到了非对称加密、散列函数、数字签名技术，在 TLS 记录协议中使用到了对称加密、散列函数等技术。具体的这些技术，在下面会详细介绍，并且说明哪些技术已经过时了，需要更换更安全的加密算法来保证安全。
密码技术介绍
本文中，涉及到一些加密算法，根据密钥的使用方式，可以分为对称加密和非对称加密：
- 对称加密：加密和解密的过程中使用的是同一种密钥。常用的加密算法有DES、AES等。
- 非对称加密：又叫做公钥加密，在加密和解密的过程中使用不同的密钥。常用的加密算法有RSA、ECC等。
除了上述两种加密算法，还有一些用来确保信息完整性和身份认证的技术：
- 密码散列算法：它不是一种加密算法，而是用来确保信息未被篡改。密码散列函数会根据信息的内容计算出一个散列值，这个散列值就被用来检查信息的完整性。
- 数字签名：信息的发送者用私钥加密，接收者使用公钥解密。用私钥加密的密文只能由对应的公钥来解密，所以可以将这个过程叫做数字签名，用来身份认证。
- 证书：经过 CA 机构数字签名后的公钥证书，用于身份认证。
加密
加密是我们众所周知的用来防止信息被窃听的手段，但是一些加密算法已经非常不安全，很容易被攻击者攻破。特别是 RC4， 目前可以在短短三天之内就可以攻破它。而且，Triple-DES 和 AES 加密算法在 BEAST 和 Lucky 13 这些攻击面前，也无法保证安全性。苹果正在计划在所有平台上弃用 Triple-DES 和 RC4，同时也不推荐使用 AES-CBC 算法，但是还没给出具体的日期。Apple 推荐我们使用 AES-GCM 或者 ChaCha20/Poly1305 算法。
密码散列
密码散列会有一个输入值和一个输出值，输入的称为消息，输出的称为散列值。密码散列会根据输入的内容计算一个散列值出来，这个散列值可以用来判断信息是否完整。但是其中一些密码散列已经不安全了，黑客可以通过碰撞攻击的方式来篡改数据。碰撞攻击是通过大量的尝试，来找到不同的输入值，但是输出值是一样的情况，进而篡改数据。因为篡改后的散列值并没有发生变化，所以你无法判断数据是否被修改过。
MD-5 和 SHA-1 已经不安全了，Apple 已经在前几年在移除了 MD-5 算法的签名证书。SHA-1 在今年的早些时候，也遭遇了攻击。所以，Apple 将也不再信任 SHA-1 算法的签名证书。为了保证绝对的安全，开发者应该使用 SHA-2 算法。
公钥密码
一般情况下，经过公钥加密的内容，只能通过私钥打开加密内容。但是，768 位的 RSA 在2009 年被攻破，Apple 在 2016 年春天已经移除了对 1024 位以下 RSA 签名的证书的支持。由此来看，对 1024 位 RSA 加密的攻击也快要来到了，所以 Apple 也宣布将不再对 2048 位以下 RSA 签名的证书信任。你应该使用 2048 位以上的 RSA 加密，或者其他 Apple 平台信任的椭圆曲线密码。
协议
如果开发者正在使用HTTP协议，那就代表着你传输的内容，任何监听者都可以获取到。同时，一些老化的 TLS 版本，也是不安全的，比如 SSL 3.0、TLS1.1 和 TLS1.0。应该避免使用这些协议，开发者应该使用基于 TLS1.2 的 HTTPS 协议。
同时，Apple 宣布发布 TLS 1.3 Beta 版，后续会详细讲。
吊销
当私钥泄漏或者或者其他一些情况出现时，我们可能需要吊销证书。客户端在收到证书的时候，需要确认证书的吊销情况。
Apple平台默认是不进行吊销检查的。目前存在的吊销机制有以下几种：
- 证书吊销列表（Certificate Revocation List ，CRL），这是一个包含吊销证书序列号的列表，证书颁发机构维护着这样的列表。它的缺点在于，CRL 会越来越大，实时查询会越来越慢，同时需要不断请求 CA 的CRL，具有一定的延迟性。
- 在线证书状态协议（Online Certificate Status Protocol，OCSP），OCSP 是这样工作的。首先，服务端会从 CA 申请一个证书，服务端会把证书发送给客户端作为验证，客户端为了验证服务端的身份会向 CA 发送一个请求，来获取该证书的吊销信息，CA 会返回该证书的状态给客户端。客户端根据返回结果来判断服务端的证书是否正确。可以看出来，OCSP 有明显的缺陷，客户端需要向 CA 发送额外的网络请求，这导致了它存在一些性能问题。并且 OCSP 是明文传输，会存在安全隐患。基于这两个原因，Apple默认不支持OCSP验证。如果开发者想启用 OCSP 查询，需要在 App 中集成其他API。
- OCSP Stapling，它弥补了 OCSP 的缺陷，服务端在从 CA 请求证书的时候，也会从 CA 请求到证书的吊销信息，然后将吊销信息和证书一起发送给客户端，客户端可以同时对证书和吊销信息进行校验。
尽管 Apple 鼓励开发者在服务端采用 OCSP Stapling 这种方式，但是普及程度远远不够。Apple 同时宣布加强在所有平台的证书吊销验证。Apple 会从 Certificate Transparency log 中获取信赖的证书列表，开发者和CA都可以向 Certificate Transparency log 提交证书，提交的证书会受到监控和审计。然后 Apple 会从证书颁发机构查询证书的吊销状态，把所有吊销证书的信息捆绑到一起，每隔一段时间自动下发给客户端设备，这样客户端就可以周期性的验证证书的吊销状态了。
在进行 TLS 会话时，如果发现证书在吊销列表内，那么客户端则执行一次 OCSP 检查，去校验证书是否真的已经被吊销。如果证书没有在吊销列表中，则不进行 OCSP 检查。这样的话，客户端一般就不需要向 CA 发送额外的网络请求，避免了性能问题。
回顾
Apple 关于加密、散列函数、网络协议、证书吊销校验和公钥密码方面的修改如图所示：
新的证书报错界面
在 Safari 中重新设计了新的证书报错界面，如果你用了不符合要求的证书，那么将会看到如下界面。
可以通过证书查看器，进一步查看证书错误的详细情况。
ATS 与 TLS 1.3
ATS 在 iOS 9 的时候推出，是为了保证开发者使用加密的网络来传输数据。但是 Apple 发现全部转为 ATS 的过渡期要比预期长，所以 Apple 扩大了对 ATS 的豁免的支持。
去年 Apple 发现目前的 ATS 豁免并不能满足所有开发者的需求，所以就开放了对AVFoundation、WebView 和 Webkit 的单独豁免支持。豁免可以限制在一个单一域名内和整个 App 内，同时也支持对本地网络（原始 IP 地址和不合格的主机名）的豁免。
虽然目前扩大了对豁免的支持，但是 Apple 依然相信使用 ATS 才是正确的选择，依然会积极推荐 ATS 的使用。
TLS 发展历程
TLS 的前身其实就是 SSL（Secure Sockets Layer），Netscape 是最早发布 SSL 的公司，后续由于互联网标准化组织的接手，将 SSL 标准化，并在 1999 年将其称为 TLS（Transport Layer Security）。后续又在 2006 年 4 月对 TLS 1.0 进行了更新，这个版本与 1.0 差异不大。2008 年发布了 TLS 1.2，也就是目前 Apple 推荐在 HTTPS 网络上使用的协议。
TLS 1.3 是正在制定的 TLS 新标准，目前还是草案版本。
TLS 1.3
在 WWDC 上 Apple 阐述了 TLS 1.3 相比 TLS 1.2 的一些改变：
- 最佳实践
- 取消对老旧加密算法支持，比如 RC4、SHA-1、CBC 和 RSA 加密算法。
- 更简单的配置、更容易测试
- 在 TLS 握手和会话恢复方面性能提升
关于第四点应该是我们最关心的优化点，TLS 握手从原来的四次握手变成了两次握手，也就是说减少了一个 RTT，TLS 1.3 的密钥交换和加密算法的协商都放在了一块。由于这套更高效的握手方法，Apple 宣布大概可以减少三分之一的握手延迟。
虽然正式的版本还没发布，但是现在你可以对 TSL 1.3 beta 版本进行测试了，你可以在 https://developer.apple.com/go/?id=tls13-mobile-profile 下载安装一个配置文件在手机上，同时手机系统升级到 iOS 11 就可以体验最新的 TLS 协议了。同时，在 macOS High Sierra 中，可以通过以下终端命令启用 TLS 1.3。
defaults write /Library/Preferences/com.apple.networkd tcp_connect_enable_tls13 1
