iOS 提高安全“门槛”:HTTPS,该升了吗?

jopen 8年前

两周前,苹果在发布会上宣布苹果持续将 iOS 9 的文件发送给开发者,确保 iOS 9 推出时相关 App 都已准备就绪。这些文件的资讯, 包括一个叫做 App Transport Security (ATS) 的安全功能。 它要求所有进入到 iOS 9 装置的资讯,都必须经 过 HTTPS 加密设定。这样可以防止黑客窥探用户进行网路传输的资料。

iOS 提高安全“门槛”:HTTPS,该升了吗?

此 消息一出,引发了网友与业界的热烈讨论, Google 发文表示:“虽然 Google 认同产业采用 HTTPS ,但对于经过我们系统的第三方广告 网络和创新程式码而言,却不见得完全认同此想法。”无论如何,苹果此举多少都算是为移动端数据安全设立了一个更高的新“门槛”。

因此,除了广告商,一大批依旧采用 HTTP 的移动互联网企业都需要加快步伐,在近期作出是否要切换成 HTTPS 的抉择。那对于企业来说,选择 HTTPS 在当下来说是否值得?它的利弊何在?下面我们就将从不同角度入手,为大家进行分析。

 

升级 HTTPS,价值何在?

HTTPS 实 质上是一种面向安全信息通信的协议。从最终的数据解析的角度上看,HTTPS 与 HTTP 没有本质上的区别。对于接收端而言,SSL/TSL 将接收 的数据包解密,将数据传给 HTTP 协议层,就形成了 HTTP 数据。而 HTTPS 则是将 HTTP 数据包通过 SSL/TSL 层加密, 从 而保证传输数据的安全性。

SSL/TSL 是一个分层协议,共有两层组成,其中 SSL/TSL 握手协议允许服务方与客户方互相认证,并在应用层协议传送数据之前协商出一个加密算法和会话密钥。SSL/TSL的握手协议主要交换数字证书、随机数、机密通信协议这三个信息,以保证访问的安全。

借此,HTTPS 可完成以下目标,这也是它基于安全性的主要价值:

●数据保密性。保证内容在传输过程中不会被第三方查看到,通过非对称加密及密钥交换来实现。

●数据完整性。可及时发现被第三方篡改的传输内容,以确保数据的完整性得到及时维护。

●身份校验。保证数据到达用户期望的目的地,即PKI和数字证书。

这样就可以明白为什么 Google 广告没法投放了:当用户使用 Safari 浏览网页,若广告内容不是透过 HTTPS 连线(对绝大多数广告来说并不需要进行加密),在 iOS 9 将无法顺利执行,也就遭到了屏蔽。

 

难掩之瑕:HTTPS 两大弊端

对于企业来说,切换成 HTTPS 的成本并不高,还可以大幅提升安全性。可还是有部分互联网企业不愿意使用它,为什么?这是因为 HTTPS 也有一些不容忽视的弊端存在。

首先,HTTPS 会拖慢访问速度。由上文可见,要做到从 HTTP 到 HTTPS 的转变,需要多次计算和交互,SSL 完全握手导致的延时,证书的状态检查等。这些自然影响了 HTTPS 的访问速度。这是 HTTPS 不被很多公司选择的主要原因。

其次,HTTPS 消耗 CPU 的计算能力。这主要发生在握手阶段的大数运算,其中密钥交换时的私钥解密阶段的性能消耗可以高达整个 SSL 握手性能消耗的 95% 。完全握手时, web server 的处理能力会降低至 HTTP 的 10% 甚至以下。

以上两点是 HTTPS 的主要劣势所在。因此即便它在安全性上具有得天独厚的价值,很多互联网企业基于用户体验和产品性能的考虑,还是选择不用 HTTPS。


选择 HTTPS,值还是不值?

因此,说 HTTPS “瑕不掩瑜”显然不太公允,因为我们可以看到,它的这些弊端很容易“戳中”不少产品的性能侧重点。但同时也要看到,针对它的这些劣势,尤其是造成访问延时这方面,已经存在很成熟的优化方法。

百度从 2014 年开始对外开放了 HTTPS 的访问,之后进行监测分析,发现如果网站什么优化都不做,HTTPS 明显慢很多。而如果站点本身已经做过常规优化,但是不针对 HTTPS 做优化,百度实测的结果是 0.2 - 0.4 秒耗时的增加。

因此,企业可以针对网站做部分优化,具体可分为以下几个方面:

首 先,我们可以在服务器端配置 HSTS ,减少 302 跳转;设置 ssl session 的共享内存 cache ;配置相同 的 session ticket key ,部署在多个服务器上,这样多个不同的服务器也能产生相同的 session ticket;设 置 ocsp stapling file,这样 ocsp 的请求就不会发往 ca 提供的 ocsp 站点,而是发往网站的 webserver。

我 们还可以优先使用 ecdhe 密钥交换算法,因为它支持 PFS( perfect forward secrecy ),能够实 现 false start;设置 tls record size ,最好是能动态调整 record size ,即连接刚建立 时 record size 设置成 msg ,连接稳定之后可以将 record size 动态增加。

如果有条件的话,还可以启用 tcp fast open。或者启用 SPDY,这样会明显提升 HTTPS 速度,甚至比 HTTP 还要快。在无线 WIFI 环境下, SPDY 比 HTTP 要快 50ms 左右,3G 环境下比 HTTP 要快 250ms。

这 些方法,可以从 HTTPS 运作的各个方面入手来优化访问速度,降低延迟。当然,这些优化做起来并不是一件简单的事情,但企业大可以不必亲自操刀来 搞 —— 你可以选择接入提供充分优化过的 HTTPS 服务的云平台。以 UPYUN 为例,作为国内首家提供全节点 HTTPS 访问(自定 义 SSL 服务)的云 CDN 厂商,UPYUN 支持客户自主上传 SSL 证书,开启完全自定义的 HTTPS 访问。

借此,接入该 服务的客户将享受完全自主、全网的 HTTPS 加密功能,并与 UPYUN 云CDN 加速服务相结合,将流经用户和服务器之间数据进行加密。同 时,UPYUN 将支持默认域名 HTTPS 服务和自主域名 HTTPS 服务两种方式选择使用,结合客户实际需求,将“HTTPS + CDN” 整 合到客户产品体系中,实现终端访问“加密+加速”的服务。

关键的一点,UPYUN 自定义 SSL 支持 TLS 协议支持的版本就有苹果指定的 TLS v 1.2,这让使用 UPYUN HTTPS 服务的用户可以与 iOS 9 系统下的苹果设备无缝对接。

这样一来,以 UPYUN 为代表的提供 HTTPS 服务的云平台,让企业得以一站式地享受 HTTPS 的安全性价值、规避它的性能劣势。效果等同于用户自主切换并构建 HTTPS 优化系统,还帮助用户节省了这两项工作的成本花费。

无论选择哪种途径,针对性的优化都会最大限度地消除 HTTPS 两大弊端对用户体验及产品性能的消极影响,从而凸显它杰出的安全性价值。在这个前提下,结合数据安全对于企业发展的重要性,以及快速抢占 iOS 新市场的意义,我们可以得出这样一个结论:选择 HTTPS ,绝对是值得的。

苹果又一次引领了行业的潮流,适时跟上不失为明智之举。你的选择,又是什么呢?

稿源:雷锋网/Randy Orton