iOS 提高安全“门槛”：HTTPS，该升了吗？

两周前，苹果在发布会上宣布苹果持续将 iOS 9 的文件发送给开发者，确保 iOS 9 推出时相关 App 都已准备就绪。这些文件的资讯，包括一个叫做 App Transport Security (ATS) 的安全功能。它要求所有进入到 iOS 9 装置的资讯，都必须经过 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 ，绝对是值得的。

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