售前咨询
技术支持
渠道合作

深入认识苹果ATS安全标准,备战IOS App Stroe审核

苹果ATS安全标准延迟给无疑给了各大开发者适应的更大空间,但实施ATS安全标准已成为不可逆转的事实。目前,仍然有一些开发者并不太了解ATS标准。下面,GDCA(数安时代科技股份有限公司)和大家一起对ATS安全标准做一个深度的了解。

App Transport Security

iOS9中新增App Transport Security(简称ATS)特性, 主要使到原来请求的时候用到的HTTP,都转向TLS1.2协议进行传输。这也意味着所有的HTTP协议都强制使用了HTTPS协议进行传输。在 IOS 9 和 OS X 10.11 中,默认情况下非 HTTPS 的网络访问是被禁止的。当然,因为这样的推进影响面非常广,作为缓冲,我们可以在 Info.Plist 中添加 NS App Transport Security 字典并且将 NS Allows Arbitrary Loads 设置为 YES 来禁用 ATS。

不过,WWDC 16 中,Apple 表示将继续在 IOS 10 和 mac OS 10.12 里收紧对普通 HTTP 的访问限制。日后,所有新提交的app 默认是不允许使用 NS Allows Arbitrary Loads 来绕过 ATS 限制的,也就是说,我们最好保证 app 的所有网络请求都是 HTTPS 加密的,否则可能会在应用审核时遇到麻烦。

IOS 10 NS App Transport Security

通过在info.plist中配置这个键,开发者可以自定义网络安全策略。例如:

允许针对个别服务器的不安全访问。

允许不安全的 web 或媒体内容访问,但不影响整个app的ATS策略。

启用新的安全特性,例如Certificate Transparency。

对NS App Transport Security的支持自 iOS9.0,OS X v10.11 开始,适用于 app 和 app extension。

自 iOS10.0,mac OS 10.12 开始,增加了对下列子键的支持:

NS Allows Arbitrary LoadsIn Media

NS Allows Arbitrary LoadsIn Web Content

NS Requires Certificate Transparency

NS Allows Local Networking

ATS Configuration Basics / ATS 配置基础知识

对于使用 iOS9.0, OS X v10.11 SDK 及以上的 app 来说,ATS(App Transport Security)默认开启,NS Allows Arbitrary Loads是字典NS App Transport Security的根键,默认值NO。

在启用 ATS 的情况下,所有的 HTTP 请求必须为 HTTPS(RFC 2818) 连接。任何不安全的 HTTP 请求都将失败。ATS 使用 TLS(Transport Layer Security)v1.2(RFC 5246)。

下面是字典NS App Transport Security的总体结构,所有键都是非必填项:

[objc] view plain copy 在CODE上查看代码片派生到我的代码片

NS App Transport Security : Dictionary {

NS Allows Arbitrary Loads : Boolean

NS Allows Arbitrary Loads In Media : Boolean

NS Allows Arbitrary Loads In Web Content : Boolean

NS Allows Local Networking : Boolean

NS Exception Domains : Dictionary {

<domain-name-string> : Dictionary {

NS Includes Sub domains : Boolean

NS Exception Allows Insecure HTTP Loads : Boolean

NS Exception Minimum TLS Version : String

NS Exception Requires Forward Secrecy : Boolean   // Default value is YES

NS Requires Certificate Transparency : Boolean

}

}

}

 

可以看出,所有键可以分为两类:主键,这些键用来定义 app 的总体 ATS 策略;子键,即NS Exception Domains下面的键,使用这些键针对某个域名单独配置。

主键包括:

NS Allows Arbitrary Loads

设置为 YES,解除整个 app 的 ATS 限制;但是,通过NS Exception Domains进 行的配置依然有效。默认值为 NO。

注意:设置为 YES,会引发 App Stroe 的审查,开发者必须说明原因。

NS Allows Arbitrary Loads In Media

设置为 YES,解除通过 AV Foundation 框架访问媒体内容时的 ATS 限制;启用这个 键,务必确保载入的媒体内容已经被加密,例如受Fair Play保护的文件,或者是安全的 HLS流媒,其中不包含敏感的个人信息。默认为 NO。

NS Allows Arbitrary Loads In Web Content

设置为 YES,解除通过 web view 发出的网络请求的 ATS 限制。启用这个键,可以使 app 访问任意网页内容,但不影响 app 的总体 ATS 策略。此键值默认为 NO。

NS Allows Local Networking

设置为 YES,使得 app 可以载入任意本地资源,但不影响 app 的总体 ATS 策略。默 认为 NO。

 

NS Exception Domains

为一个或多个域名单独配置 ATS。

被单独配置的域名,默认受到完全的 ATS 限制,不管NS Allows Arbitrary Loads的值 如何;需要通过子键,进一步配置

所有的子键都属于NS Exception Domain。向Info.plist中添加这一主键:

创建字典,针对一个或多个域名,以便进行 ATS 配置。

这意味着之前使用主键所做的设置,对于这个域名来说,已经无效。

例如,及时之前设置NS Allows Arbitrary Loads In Media为 YES,然而NS Exception Domain所代表的域名依然不能访问不安全的媒体内容。

基于这样的设定,可以针对域名进行 ATS 配置,增加或减少安全措施。例如:

将NS Exception Allows Insecure HTTP Loads设置为 YES,就 ;这样做会引发 App Store 的审查,详情见App Store Review for ATS。

通过配置NS Exception Requires Forward Secrecy为 NO,取消正向保密。

通过配置NS Exception Minimum TLS Version,更改 TLS 最低版本。

NS Exception Domains字典构成:

<域名字符串>

代表想要配置的特定域名。可以添加多个域名(即添加多个这样的键),为它们统一配置 ATS 策略。这个键对应一个字典,包含以下子键:

NS Includes Sub domains

* 设置为 YES,当前域名的 ATS 策略适用于其所有子域名。默认为 NO。

NS Exception Allows Insecure HTTP Loads

* 设置为 YES,可以同时通过 HTTP 和 HTTPS 访问当前域名。默认为 NO。

注意,配置这个键值,将引发 App Store 的审查,开发者必须说明原因。

NS Exception Minimum TLS Version

* 指定 TLS 的最低版本,因此可以使用版本较低,有安全漏洞的 TLS 协议。

注意,配置这个键值,将引发 App Store 的审查,开发者必须说明原因。

NS Exception Requires Forward Secrecy

* 设置为 NO,允许针对当前域名使用不支持正向保密的 TLS 加密算法。默认为 YES。

NS Requires Certificate Transparency

* 设置为 YES,将验证域名服务器证书的Certificate Transparency时间戳 。默认为 NO。

 

Requirements for Connecting Using ATS / 使用 ATS 的前提条件

在 ATS 完全开启的情况下,系统要求 app 的 HTTPS 连接必须满足以下要求:

X.509 数字证书必须满足下列标准中的一项:

由操作系统内嵌的根证书颁发机构签发

由通过操作系统管理员或用户主动安装的根证书颁发机构签发

TLS 版本必须为1.2,任何不使用或使用较低版本 TLS / SSL 的连接,都将失败。

连接必须使用 AES-128 或 AES-256 对称加密算法。 TLS 算法套装必须以 ECDSA 密钥交换的形式支持正向保密,加密算法必须为下面之一:

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384

TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA

TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256

TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256

TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

服务端的叶证书签名密钥必须为下面之一:

至少2048位的 RSA 密钥

至少256位的 ECC 密钥

此外,服务器证书的哈希算法必须为 SHA-2,其摘要长度至少位256位(即 SHA-256 及以上)。

上面的标准,未来可能会发生变化。但不会影响到 app 二进制包的兼容性。

App Store Review for ATS / App Store 对于 ATS 相关项的审核

某些对 ATS 的配置会引发 App Store 的审核,开发者必须说明原因。这些键有:

NS Allows Arbitrary Loads

NS Exception Allows Insecure HTTP Loads

NS Exception Minimum TLS Version

以下是一些原因说明例子,供参考:

必须连接由其他机构控制的服务器,其还不支持安全连接。

必须支持那些还未升级至可使用安全连接,不得不通过公共域名访问网络的设备。

必须通过 web 展示来源不一的各种网络内容,但又不能完全使用NS Allows Arbitrary Loads In Web Content所管理的类。

向 App Store 提交审核时,开发者应主动提供足够的信息,以便解释 app 无法使用安全连接的原因。

GDCA已通过WebTrust EV的国际认证,是全球可信任的证书签发机构。GDCA专业技术团队将根据用户具体情况为其提供最优的产品选择建议,并针对不同的应用或服务器要求提供专业对应的HTTPS解决方案。GDCA签发的SSL证书,均可以达到苹果ATS对证书的硬性标准,帮助App开发商解决这迫在眉睫的服务器安全升级问题。

上一篇:

下一篇:

相关新闻

 

领取优惠
免费预约

申请试用SSL证书

提交成功!

咨询客服