App 与不断发展的网络安全标准

作者:@Joy_xx ,网易 iOS 工程师

现在,我们越来越关注用户的隐私和信息安全,但是随着时间的推移,计算机变得越来越高效,那些年代久远的网络协议和加密算法,在新的硬件和攻击方式下,变得岌岌可危。

针对网络安全,我们要怎样做?

  • 时刻关注 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。

top Created with Sketch.