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 ，绝对是值得的。
苹果又一次引领了行业的潮流，适时跟上不失为明智之举。你的选择，又是什么呢？