[Diving into WWDC 2017] Your Apps and Evolving Network Security Standards

苹果关于网络安全的最佳实践

标签：应用安全 网络技术 TLS OCSP

本 Session 包含两个部分:

阐述了苹果在移动安全领域所做的工作，并且给予了开发者相应的建议 深入介绍了 ATS 现状和未来的发展计划

第一部分：苹果在安全领域所做的工作

随着互联网技术的发展，互联网安全也面临越来越严峻的挑战。

最近这些年，针对网络安全的攻击类似 BEAST、CRIME、BREACH、DROWN 层出不穷，也时刻威胁着所有的 App。而随着网络安全协议使用时间越来越久，计算机的速度越来越快，他们内部所依赖的算法也越来越容易被用碰撞、分解和暴力的方式破解。

下图是目前存在的一些针对网络安全的攻击方式。

所以 Apple 持续的关注网络安全技术的发展，来避免自己的网络服务和 App 受到攻击。

以下几点是 Apple 一直坚持并行之有效的建议，也提供给开发者：

关注安全，清楚自己 App 现在所使用的安全协议和算法 跟进业界最新的研究成果以及安全事件，并针对性的完善安全措施 如果使用了一些第三方代码，保证这些第三方代码的安全性，及时更新 如果使用 ATS，只要避免 ATS exception，苹果会保证你的安全 提醒所有用户及时更新 App

下面，我们从加密、加密哈希、公钥、协议和证书撤销五个方面阐述苹果对安全领域所做的工作。

加密：

不推荐：RC4、3DES-CBC、AES-CBC 推荐：AES-GCM、ChaCha20/Poly1305

加密是用来避免攻击者盗取信息的一种手段。

但是实际上一直使用的某些加密算法非常容易被破解。例如 RC4 可以在短短三天内就被破解。

另外，像 3DES-CBC 和 AES-CBC 也很容易被 BEAST 和 Lukcy13 攻击。所以 Apple 打算在未来的平台上从 TLS 中移除 RC4 和 3DES-CBC。

建议使用 AES-GCM 或 ChaCha20/Poly1305 等认证加密算法。

加密哈希：

不推荐：MD5、SHA-1 推荐：SHA-2 Family

加密哈希是一种可以让我们检查数据是否发生变化的机制。

但是现有的加密哈希算法很容易受到碰撞攻击的影响，碰撞攻击可以让两个不同的输入产生同样的输出，这样使用者就无法知道数据是否发生变化。

而 MD5 和 SHA-1 都已经被碰撞攻击突破，FLAME 攻击就攻破了 MD5 签署的证书。

在今年早些时候， SHA-1也已经被攻破。Apple 在早些年就移除了对 MD5 的信任，现在宣布也将移除对 SHA-1 签名证书的信任。并建议使用 SHA-2 Family 或者其他能避免碰撞攻击的算法。

公钥

不推荐：< 2048-bit RSA 推荐：>= 2048-bitRSA、Elliptic Curves

公钥是一种提供身份证明的机制。用来保证其他人可以识别出内容是由公钥的所有者提供，并且可以给公钥所有者发送只有所有者能用私钥解密的加密数据。

但不幸的是，小于 1024 位的 RSA 秘钥很容易被分解攻击。2009 年，768 位的 RSA 秘钥被攻破，导致 Apple 在 2016 年春天移除了对小于 1024 位秘钥的信任。而现在 Apple 认为对 1024 位的攻击马上就会到来，所以宣布将会移除所有小于 2048 位秘钥的信任，建议使用大于等于 2048 的 RSA 秘钥。

协议：

不推荐：HTTP、SSLv3(2015 年秋天已废弃)、TLS 1.0、TLS1.1 推荐：HTTPS 运行在 TLS1.2 上的 HTTP，支持了 TLS1.3

协议是用于端与服务器通讯的标准。

这意味着只要支持了某协议，就可以在全世界与任何一台同样支持该协议的服务器进行交流。 但是有一些安全协议安全性非常弱，例如使用 HTTP，所有的用户清晰都是明文的。

而一些较老的加密协议，例如 SSLv3、TSL1.0、TSL1.1 也很容易被攻击。

Apple 在 2015 年秋天取消了对 SSLv3 的支持，建议开发者都使用目前最安全的标准 TLS1.2，并且增加了对 TLS1.3 Beta 的支持。

证书撤销

不推荐：不检查 推荐：OCSP Stapling + CT logs

证书撤销是用于客户端检查证书是否已经失效的机制。

最糟糕的做法当然就是完全不检查，iOS 平台默认也未检查证书撤销。除非使用 OCSP Stapling 协议。

我们先看下 OCSP 的运行原理。

OCSP 即在线证书状态协议。客户端为了校验证书的合法性，会每次从证书颁发机构请求该证书的状态，并根据该状态决定是否连接到目标服务器。

从 OSCP 的运行机制可以看出，OCSP 存在两个与生俱来的缺陷：

增加网络耗时：增加额外的一次网络请求，导致速度偏慢 用户信息泄露：OCSP 是明文的，这就意味着所有人都知道用户想检查哪个证书；如果想加密的话，意味着还需要建立一个安全的连接，陷入了一个死循环

也是因为这两个原因，所以并未默认开启 OCSP；并且 OCSP 使用时还需要引入额外的 API。 由于 OSCP 这些天然的缺陷无法解决，由此引出了 OCSP Stapling。

OCSP Stapling

和 OCSP 一样，服务器从证书颁发机构获取证书。但是在将该证书发送给客户端之前，服务器从 CA 请求 OCSP 响应并验证它，将其与证书一起发送给客户端。

OCSP Stapling 很好的解决了 OCSP 存在的两个问题，对于客户端来说，首先不需要一次额外的网络请求，其次也不需要再去和第三方校验证书是否合码。

但是 OCSP Stapling 也存在两个问题，首先它的使用比例还很低，其次也是最重要的是它并不能保护用户免受恶意服务的侵害，而服务器只要忽略掉 OCSP 响应，那客户端就无法知道证书的真实状态。

为了解决 OCSP Stapling 的问题，我们引入了 Certificate transparency logs 简称 CT logs。

Certificate transparency logs

中文一般称为证书透明。是 IETF 在 2013 年启动的开源项目，把所有已知的合法证书做了一个白名单，浏览器在验证证书的同时也会去查看这个证书是不是在白名单里面。如果不在的话，就会告知用户这个证书找不到记录，有可能是假或者是被盗的证书。

而开发者需要做的，就是确保自己的证书包含在 CT logs 中。

Apple 现在可以从 CT logs 中知道平台上所有信任的证书颁发机构，可以从这些机构中拿到所有的证书撤销信息，将其打成一个 bundle 同步给客户端。

客户端会定期从 Apple 更新所有的证书撤销信息。

如果直接点击证书，则会直接执行 OCSP 或 OCSP Stapling(如果支持的话)。

这样，存在隐私问题的就只有那一部分没有支持 OCSP Stapling 的用户。

使用这套机制，在 iOS 平台上安全性有了巨大的飞跃，并且这些信息总能保持最新而且是免费的。具体的运行机制如下图：

前面已经提到了为了安全删除了大量对不安全协议和算法的支持，但是如果是以下的几种情况，暂时不会受到影响：

不影响根证书。根证书在 2015 年秋天已经不支持 2048 以下的 RSA ，所以已经不会再有 2048 位以下的 RSA。 不影响企业通过 Mobile Device Management 发布的证书。 不影响用户通过邮件、Safari 和 Keychain 安装的证书。 不影响 TLS 中使用相互认证的证书。

对于这些证书的安全性问题，Apple 表示需要时间给企业和用户去更新相关的安全服务，在将来(没说具体啥时候)，这些不符合标准的证书也将被取消信任。所以现在如果开发者的服务仍然不符合上述的标准，就需要准备更新证书了。

如果你在浏览器中发现了错误为 invalid searching or -9807 SSL error，就需要让服务器管理员去升级你们的证书。

最后来总结下为了确保安全需要做的事情。

首先检查所有的代码、第三方库和服务是否和上述有不相符的地方。

如果是一个服务端开发人员，需要做的事情会比较多：

替换 SHA-1 或者弱 RSA 证书 升级协议到 TLS1.2 开启 OCSP Stapling 检查你的证书是否在 CT logs 中

如果是一个客户端开发人员，只需要做一件事，就是尽量避免 ATS Exception。

第二部分：ATS

ATS 全名为 App Transport Security，是苹果在 iOS 9 中发布的新功能，旨在增加用户的安全性并保护用户的隐私。

ATS 现在已经使用了一套非常安全的标准：

协议上支持 TLS1.2 强大的密码安全：使用 AES 和 SHA-2 前向安全—ECDHE（椭圆曲线迪菲-赫尔曼密钥交换）

但现实是，并不是所有的服务器都使用了这些标准，而一旦需要使用不符合这些标准的场景，就会引入 ATS exception。ATS exception 主要的目的是为了保持现有的功能，并给 TLS 的配置升级腾出时间。

去年，Apple 已经开始计划要求提交在 App Store 中的应用必须有合理的理由，才能使用 ATS exception。但是后来听到了一些使用场景现有的 ATS exception 并不能满足使用需求。但使用 ATS 仍然是未来的目标，

为了推广 ATS 的使用，Apple 深入研究了这些不满足使用需求的场景并且提供了更多的 ATS exception 以满足这些特例。这些特例包括 AVFoundation、webView 和本地网络。

在过去的一年中，Apple 仍然致力于升级更多的服务去兼容 ATS，现在下图所列出的服务都已经兼容 ATS。这意味着如果您的应用在和他们做数据交互时不需要再进行特殊的处理。

对于服务端开发人员，需要及时升级 TLS 配置，支持 TLS 1.2 或者更新的版本。

最后，来谈谈 TLS 1.3。

多年以来，有很多不同的 TLS 版本被各种服务器所使用。在这些年的演进中也被打过很多补丁用来解决一些设计缺陷以应对前文提到的诸多攻击。

所以，互联网社区认为是时候需要设计一个更新更好的 TSL 版本了，这就是 TLS 1.3。

秉承一贯坚持使用最佳实现的原则， Apple 一直在跟进 TLS 1.3 的进度，并准备随时采用它。

在 TLS 1.2中，启动 TLS 握手后，客户端和服务器需要 say hello 并交换一些初始化信息以及继续其余的连接。而在 TLS 1.3 中，双方实际上也开始进行秘钥的协商，这意味着下一步就可以直接发送数据。

根据 Apple 搜集到的世界各地的运营商的数据，TLS 1.2 在蜂窝网络下有 10% 的连接超过 800ms，WiFi 下有 10% 的连接超过 500ms+，而 TLS 1.3 能把上述时间缩短三分之一，这将是移动世界的巨大进步。

目前 TLS 1.3 的规范还在研发中，所以它还不是默认选项，但是可以在这里下载一个 profile 在 iOS 上开启。

或者可以在 macOS 上执行:

defaults write /Library/Preferences/com.apple.networkd tcp_connect_enable_tls13 1  

所有这一切的最终目标是保护用户安全和隐私，所以 Apple 会不断分享最佳实践方式和技术去实现这个目标。当然这也需要开发者进行一些工作去升级到最新的 TLS 配置。如果是服务提供者，意味着只要升级到 TLS 1.2，就可以确保符合 ATS 的应用可以与您通信。如果是应用开发者，尽量避免 ATS exception。

最后，如果想要进一步的探索 TLS 1.3，可以从 Apple 提供的网址下载试用。