苹果强制使用HTTPS传输后APP开发者必须知道的事

[复制链接]
hyt_xcx手机认证 实名认证 视频认证 发表于 2016-12-21 20:59:14 | 显示全部楼层 |阅读模式 打印 上一主题 下一主题
本帖最后由 hyt_xcx 于 2016-12-21 22:23 编辑
来源于WeTest

2017年1月1日起,苹果公司将强制使用HTTPS协议传输。本文通过对HTTPS基础原理和通信过程内容的讲解,介绍APP开发者在这个背景下的应对办法。


几周前,我们在《https大势已来?看腾讯专家如何在高并发压测中支持https》中介绍了腾讯WeTest在基于epoll的高并发机器人框架中加入openssl的方法支持HTTPS接口测试的方法,不仅介绍了具体的使用办法,并且了解到HTTPS注定会是未来的主流趋势。

而随着2016年行将结束,我们发现,这一天,已经越来越近了。

随着全球互联网安全意识的进一步觉醒,越来越多的公司意识到网络信息安全的重要性,只有绝对的加密才能保证在线交易和商务活动的安全进行。互联网无疑是个人信息和隐私泄露最频繁的场合,各种以窃取信息为方式而展开的网络犯罪是互联网发展所面临的最大挑战。在这样一个大环境下,苹果公司首先做出应对,在苹果全球开发者大会(WWDC)的一场安全演示会上,苹果公司公布了一个最后期限——2017 年 1 月 1 日——即 App Store 当中的所有应用必须启用 App Transport Security (ATS)安全功能。

一、这个举措意味着什么?

苹果公司强制所有iOS App在2017年1月1日前使用HTTPS加密,这就意味着,如果您的APP如果仍采用HTTP传输,那么,在Apple Store中您的APP将不再能被用户下载使用。

二、什么是App Transport Security (ATS)安全功能?

App Transport Security,简称 ATS,是苹果在 iOS 9 当中首次推出的一项安全功能。在启用 ATS 之后,它会强制应用通过 HTTPS(而不是 HTTP)连接网络服务,这能够通过加密来保障用户数据安全。

HTTPS 当中的“S”代表的是“安全”(secure),在登录银行或电邮账号时,你会常常看到它出现在浏览器地址栏。不过,移动应用在网络连接安全性上面没有那么透明,用户很难知道应用连接网络时使用的是 HTTP 还是 HTTPS。

ATS 由此登场,它在 iOS 9 当中是默认开启的。然而,开发者仍然能够关闭 ATS,让自己的应用通过 HTTP 连接传输数据——现在的情况是,这招在年底之后就行不通了。(技术人员注意:ATS 要求使用 TLS v 1.2,但那些已经经过加密的批量数据例外,比如流媒体数据。)

在今年年底时,苹果将要求所有提交到 App Store 的应用强制开启 ATS。现在有了明确的最终期限,那些一直 想知道 HTTP 会在什么时候遭此重击的应用开发者可以松一口气了,而用户也能安心地知道,他们的 iPhone 和 iPad 应用将默认使用安全连接。

三、为什么这么做?

企业对于网络信息安全的也越来越高,只有保证绝对的加密传输才能确保在线交易及用户个人隐私数据的安全性。由于HTTP明文传输带来的安全事件频发,企业对于HTTP已无信任可言,只有通过HTTPS加密传输才能有效的防钓鱼,防篡改,防监听,防劫持使网站安全可信。

四、开发者应该做什么?

首先需要选择合适的证书为部署https证书做决策,然后调整后台应用实现后台应用全站https,协调运营及开发完成部署完善服务端应用部署及Web服务器配置,最后以安全方式发布应用完成应用改造,重新发布应用。
为了让大家更好的理解上述措施,下面具体介绍一下相关的HTTPS基础原理和通信过程。

五、HTTPS的基础原理和通信过程

HTTPS(Secure Hypertext Transfer Protocol) 安全超文本传输协议 它是一个安全通信通道,它基于 HTTP 开发,用于在客户计算机和服务器之间交换信息。它使用安全套接字层(SSL)进行信息交换,简单来说它是 HTTP 的安全版,是使用 TLS/SSL 加密的 HTTP 协议。
HTTP 协议采用明文传输信息,存在信息窃听、信息篡改和信息劫持的风险,而协议 TLS/SSL 具有身份验证、信息加密和完整性校验的功能,可以避免此类问题。

TLS/SSL 全称安全传输层协议 Transport Layer Security, 是介于 TCP 和 HTTP 之间的一层安全协议,不影响原有的 TCP 协议和 HTTP 协议,所以使用 HTTPS 基本上不需要对 HTTP 页面进行太多的改造。

LabImage_81332d844993b06850f0676b1dfcfde0.png
1、TLS/SSL 原理

HTTPS 协议的主要功能基本都依赖于 TLS/SSL 协议,本节分析安全协议的实现原理。
TLS/SSL 的功能实现主要依赖于三类基本算法:散列函数 Hash、对称加密和非对称加密,其利用非对称加密实现身份认证和密钥协商,对称加密算法采用协商的密钥对数据加密,基于散列函数验证信息的完整性。

LabImage_8eace6985a49e3a9db4bc4353551f6ac.png
散列函数 Hash,常见的有 MD5、SHA1、SHA256,该类函数特点是函数单向不可逆、对输入非常敏感、输出长度固定,针对数据的任何修改都会改变散列函数的结果,用于防止信息篡改并验证数据的完整性;对称加密,常见的有 AES-CBC、DES、3DES、AES-GCM等,相同的密钥可以用于信息的加密和解密,掌握密钥才能获取信息,能够防止信息窃听,通信方式是1对1;非对称加密,即常见的 RSA 算法,还包括 ECC、DH 等算法,算法特点是,密钥成对出现,一般称为公钥(公开)和私钥(保密),公钥加密的信息只能私钥解开,私钥加密的信息只能公钥解开。因此掌握公钥的不同客户端之间不能互相解密信息,只能和掌握私钥的服务器进行加密通信,服务器可以实现1对多的通信,客户端也可以用来验证掌握私钥的服务器身份。

在信息传输过程中,散列函数不能单独实现信息防篡改,因为明文传输,中间人可以修改信息之后重新计算信息摘要,因此需要对传输的信息以及信息摘要进行加密;对称加密的优势是信息传输1对1,需要共享相同的密码,密码的安全是保证信息安全的基础,服务器和 N 个客户端通信,需要维持 N 个密码记录,且缺少修改密码的机制;非对称加密的特点是信息传输1对多,服务器只需要维持一个私钥就能够和多个客户端进行加密通信,但服务器发出的信息能够被所有的客户端解密,且该算法的计算复杂,加密速度慢。

结合三类算法的特点,TLS 的基本工作方式是,客户端使用非对称加密与服务器进行通信,实现身份验证并协商对称加密使用的密钥,然后对称加密算法采用协商密钥对信息以及信息摘要进行加密通信,不同的节点之间采用的对称密钥不同,从而可以保证信息只能通信双方获取。

2、PKI 体系

(1)RSA 身份验证的隐患
身份验证和密钥协商是 TLS 的基础功能,要求的前提是合法的服务器掌握着对应的私钥。但 RSA 算法无法确保服务器身份的合法性,因为公钥并不包含服务器的信息,存在安全隐患:
客户端 C 和服务器 S 进行通信,中间节点 M 截获了二者的通信;

节点 M 自己计算产生一对公钥 pub_M 和私钥 pri_M;
C 向 S 请求公钥时,M 把自己的公钥 pub_M 发给了 C;
C 使用公钥 pub_M 加密的数据能够被 M 解密,因为 M 掌握对应的私钥 pri_M,而 C 无法根据公钥信息判断服务器的身份,从而 C 和 M 之间建立了”可信”加密连接;
中间节点 M 和服务器S之间再建立合法的连接,因此 C 和 S 之间通信被M完全掌握,M 可以进行信息的窃听、篡改等操作。

另外,服务器也可以对自己的发出的信息进行否认,不承认相关信息是自己发出。

因此该方案下至少存在两类问题:中间人攻击和信息抵赖。

LabImage_deeda5da52a2f1758892f4bebfb55fe4.png
几周前,我们在《https大势已来?看腾讯专家如何在高并发压测中支持https》中介绍了腾讯WeTest在基于epoll的高并发机器人框架中加入openssl的方法支持HTTPS接口测试的方法,不仅介绍了具体的使用办法,并且了解到HTTPS注定会是未来的主流趋势。

而随着2016年行将结束,我们发现,这一天,已经越来越近了。

随着全球互联网安全意识的进一步觉醒,越来越多的公司意识到网络信息安全的重要性,只有绝对的加密才能保证在线交易和商务活动的安全进行。互联网无疑是个人信息和隐私泄露最频繁的场合,各种以窃取信息为方式而展开的网络犯罪是互联网发展所面临的最大挑战。在这样一个大环境下,苹果公司首先做出应对,在苹果全球开发者大会(WWDC)的一场安全演示会上,苹果公司公布了一个最后期限——2017 年 1 月 1 日——即 App Store 当中的所有应用必须启用 App Transport Security (ATS)安全功能。

(2)身份验证-CA 和证书

解决上述身份验证问题的关键是确保获取的公钥途径是合法的,能够验证服务器的身份信息,为此需要引入权威的第三方机构 CA。CA 负责核实公钥的拥有者的信息,并颁发认证”证书”,同时能够为使用者提供证书验证服务,即 PKI 体系。
基本的原理为,CA 负责审核信息,然后对关键信息利用私钥进行”签名”,公开对应的公钥,客户端可以利用公钥验证签名。CA 也可以吊销已经签发的证书,基本的方式包括两类 CRL 文件和 OCSP。CA 使用具体的流程如下:

LabImage_1c23bc060fd82dc60192d89e8e7f3fe4.png
a.服务方 S 向第三方机构CA提交公钥、组织信息、个人信息(域名)等信息并申请认证;

b.CA 通过线上、线下等多种手段验证申请者提供信息的真实性,如组织是否存在、企业是否合法,是否拥有域名的所有权等;

c.如信息审核通过,CA 会向申请者签发认证文件-证书。
证书包含以下信息:申请者公钥、申请者的组织信息和个人信息、签发机构 CA 的信息、有效时间、证书序列号等信息的明文,同时包含一个签名;
签名的产生算法:首先,使用散列函数计算公开的明文信息的信息摘要,然后,采用 CA 的私钥对信息摘要进行加密,密文即签名;

d.客户端 C 向服务器 S 发出请求时,S 返回证书文件;

e.客户端 C 读取证书中的相关的明文信息,采用相同的散列函数计算得到信息摘要,然后,利用对应 CA 的公钥解密签名数据,对比证书的信息摘要,如果一致,则可以确认证书的合法性,即公钥合法;

f.客户端然后验证证书相关的域名信息、有效时间等信息;

g.客户端会内置信任 CA 的证书信息(包含公钥),如果CA不被信任,则找不到对应 CA 的证书,证书也会被判定非法。

在这个过程注意几点:
1.申请证书不需要提供私钥,确保私钥永远只能服务器掌握;
2.证书的合法性仍然依赖于非对称加密算法,证书主要是增加了服务器信息以及签名;
3.内置 CA 对应的证书称为根证书,颁发者和使用者相同,自己为自己签名,即自签名证书;
4.证书=公钥+申请者与颁发者信息+签名;

六、HTTPS接口测试

那么在完成了全站HTTPS,完成了后台和服务器端的部署之后,如何快速的对“新站“进行快速的测试,检测APP接口的承载能力?
腾讯WeTest提供了针对https的服务器性能测试功能,使用方法如下:

1、点击服务器性能测试产品首页(http://wetest.qq.com/gaps/ )中的快捷入口:HTTP直压。模式选择简单模式,名称和描述可以自己填写。(图中示例起始人数50人,每隔60秒增加50人,加到200人为上限)


回复

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

专注源码分享,教程分享
全国服务电话

187-8198-7163

周一至周8:00-22:00

反馈建议

cdhaoyt@163.com 在线QQ咨询

扫描二维码关注我们

Powered by Discuz! X3.2© 2001-2013 Comsenz Inc.( 蜀ICP备16032957号-1