HTTP 有时候比 HTTPS 好

做为一家安全公司，我们在站点 Stormpath 上经常被开发者问到的是有关安全方面最优做法的问题。其中一个被经常问到的问题是:
我是否应当在站点上运行 HTTPS？
很不幸，查遍整个因特网，你大多数情况下会得到同样的建议：加密所有的东西！对所有站点进行 SSL 加密等等！然而，现实情况表明这通常不是一个好的建议。
许多情况下使用 HTTP 比使用 HTTPS 要好很多。事实上，HTTP 是一个在性能上和可用性上比 HTTPS 更好的一种协议，这也就是我们经常推荐客户使用 HTTP 的原因。下面我们说一说我们的理由……

使用 HTTPS 会出现的问题

HTTPS 是一个错漏百出的协议. 此协议及其现今流行的实现中许许多多众所周知的问题使得它不适用于许多各种各样的 web 服务。

HTTPS 十分缓慢

应用 HTTPS 的主要阻碍之一就是 HTTPS 协议十分缓慢的这一事实。
就其特性而言，HTTPS 就是在两端之间进行安全的加密通信。这需要两端都持续耗费宝贵的 CPU 时间周期：
一开始说“hello”就决定使用哪种类型的加密方式 (暗号方案套件) 验证 SSL 证书 为每一个请求的验证以及对请求/回应的验证核实，运行加密代码

而这听起来不是特别形象，其实就是加密代码运行的是 CPU 密集型的操作。它会重度使用浮点运算的 CPU 寄存器，会征用你的 CPU 从而使得请求的处理变慢。

这里有一个内容十分丰富的 ServerFault 线程，展示了在使用代用 Apache2 的一个 Ubuntu 服务器时，相比之下的处理速度你所能预计会有多大的降低： http://serverfault.com/questions/43692/how-much-of-a-performance-hit-for-https-vs-http-for-apache 。

如下是结果:

即使是像上面所展示的一个非常简单的示例，HTTPS 也能将你的 Web 服务器的速度拖慢超过 40 倍! 这可拖了 web 性能很大的后腿.

在今天的环境中， 将你的应用程序作为 REST API 的一个组成部分来构建是很普遍的 — 使用 HTTPS 确实是会拖慢你的网站、影响你的应用程序性能并给你的服务器 CPU 带来不必要的冲击的一种方式，而且通常会惹恼你的用户。

对于许多对速度敏感的应用程序而言，使用原始的 HTTP 常常要好很多。

HTTPS 不是一个放之四海而皆准的安全保障

 

许多人都会抱有 HTTPS 会让他们的站点更安全，这样一种印象。这其实不是真的。

HTTPS 只是对你和服务器之间的流量进行了加密 — 一旦 HTTPS 信息的传输中断了，一切就又都是一场公平的游戏。

这意味着如果你的计算机已经感染的了恶意软件，或者你已经被受到欺骗运行了某些恶意软件 — 这个世界上所有的 HTTPS 对于你而言也都无能为力了。

此外，如果 HTTPS 服务器上存在任何的漏洞，某些攻击者就能够简单的等到 HTTPS 已经处理结束，然后再在其它的层（例如 web 服务这一层）抓取到不管什么数据。

SSL 证书本身也经常被滥用。比如，其在浏览器上的处理方式就很容易发生错误：

每种浏览器（Mozilla,google 等）都是独立审计并核准根证书提供商来保证他们安全地处理 SSL 证书 一旦核准通过，这些根 SSL 证书就会被添加到浏览器的可信证书列表，这意味任何由根证书提供商签名的证书都是默认可信的。 这些提供商因此可随意乱搞，导致各类安全问题频发，比如 2011 年发生的  DigiNostar  事件。

以上种种，著名证书授权机构错误地签名了大量的伪造和欺诈的证书，直接损害数以万计的 Mozilla 用户的安全。

而 HTTP 并没有提供任何形式的加密服务，至少你知道你正在处理什么东西。

HTTPS 流量很容易被监听

如果你正在构建一个需要被不安全的设备（比如移动 app）使用的 web 服务，你可能觉得因为你的服务运行于 HTTPS 上，通信就不会被监听了。

如果真这么想的话，你就错了。

其他人可以轻松地在电脑上设置代理来截获并查看 HTTPS 流量，也就越过了 SSL 证书检查，这就直接泄漏了你的私人信息。

这篇博文 就演示了移动设备上的 https 消息监听。

你觉得没多大事？别做梦了！就连 Uber 这种大公司的移动应用都被逆向了，它们也用了 HTTPS。如果你灰心了，我劝你还是别看 这篇文章 了。

好了，接受现实吧，不管你怎么做，攻击者都能用这样或那样的方法来监听你的网络流量。与其把时间浪费在修复 SSL 的问题上，还不如花点时间想想如何明智地使用 HTTP 吧。

HTTPS 有漏洞

大家都知道 HTTPS 并不是铁板一块。多年来 HTTPS 被曝出了不少漏洞：

POODLE  (pdf) BEAST CRIME Heartbleed …

以后的攻击会越来越多。再加上 NSA 为了解密，正不遗余力地收集着 SSL 流量——使用 HTTPS 似乎一点用处都没有，因为不定什么时候你的 HTTPS 流量就会被一览无余。

HTTPS 太贵

最后要说的一点是 HTTPS 太贵了。你需要从根证书颁发机构购买浏览器和客户端能够识别的 SSL 证书。

这可不便宜啊。

SSL 证书年费从几美刀到几千不等——如果你正在构建基于多个微服务（multiple microservices）的分布式应用，你需要买的证书可不只一个。

 

对于小项目或预算紧张的人来说成本一下子就抬高了不少。

为什么 HTTP 是一个不错的选择

在另一方面，让我们稍稍不那么消极片刻，而是专注于积极的东西 : 是什么使得 HTTP 很棒的。大多数开发者并不欣赏它的好处。

正确条件下的安全

当然 HTTP 本身没有提供任何安全性，通过正确的设置你的基础设施和网络，你可以避免几乎所有的安全问题。

首先，对于所有的你可能会用到的内部 HTTP 服务， 要确保你的网络是私有的，不能从公共的外部环境嗅探到数据包. 这意味着你将可能徐昂要将你的 HTTP 服务部署在一个像 Amazon EC2 这样的非常安全的网络里面.

通过在 EC2 部署公共的云服务器，就能保证你拥有一流的网络安全， 防止任何其他的 AWS 用户嗅探到你的网络流量.

使用 HTTP 的不安全性来扩展

人们过多的关注于 HTTP 缺乏安全和加密特点的时候，许多人没有想到的是，这种协议可以提供很好的扩展性。

大部分现代的 Web 应用程序通过队列来扩展。

你有一个 Web 服务器接受请求，然后用处在相同网络上的服务器集群运行单独的 jobs 来处理更多的 CPU 和内存密集型任务。

为了处理任务的排队，人们通常使用一个诸如 RabbitMQ or Redis 这样的系统。两个都是不错的选择，但是否可以 除了你的 网络外 不使用任何 基础设施组件 而获得任务队列的好处呢？

使用 HTTP，你可以！

它是这样工作的：

建立 Web 服务器和所有处理服务器共享子网的一个网络。 让你的处理服务器侦听网络上的所有数据包，和被动嗅探网络流量。 当 Web 服务器收到 HTTP 流量，那些处理服务器可以简单地读取进来的请求（纯文本，因为 HTTP 不加密），并立即开始处理工作！

上述系统的工作原理就像一个分布式队列，快速，高效，简单。

使用 HTTPS，上述情况是不可能的，但是，通过使用 HTTP，可以大大加快您的应用程序同时去除（不必要的）基础设施–这是一个大的胜利。

不安全和自负

最后一个我建议使用 HTTP 而不是 HTTPS 的原因： 不安全 。

是的，HTTP 没有给你的用户提供安全，但是，安全真的有必要吗？

不仅大部分 ISP 监控网络通信，过去数年的很长一段时间里，很明显的是政府已经存储并解密了大量网络通信。

使用 HTTPS 的顾虑正好比将一个挂锁来放在一尺高的篱笆上，大致来说，你不可能保证应用的安全。所以，何必这么麻烦呢？

开发仅依靠 HTTP 的服务，这并没有给你的用户一种安全的错觉，或者欺骗用户认为自身很安全。事实上，他们很有可能认为是不安全的，

开发基于 HTTP 的程序，你的生活将得到简化，并增强和你用户的透明。

我喜欢你不会真的任务我会建议你不去使用 HTTPs !  我想要非常明确的告诉你 : 如果你要构建任何什么类型的 web 应用， 要使用 HTTPS 哦!

你要构建什么类型的应用程序或者服务并不重要，而如果它没有用到 HTTPS，你就做错了.

现在，让我们来聊聊 HTTPS 为什么很棒.

HTTPS 是安全的

HTTPS 是一个业绩优良的很棒的协议. 虽然这些年来有过几次针对其漏洞的利用事件发生， 但它们一直都是相对较为轻微的问题，而且也很快被修复了.

而诚然，NSA 确实在某个阴暗的角落收集着 SSL 流量， 但他们能够解密即使是很少量 SSL 流量的可能性都是极小的 — 这会需要快速的，功能齐全的量子计算机，并耗费数量惊人的钞票. 这玩意存在的可能性貌似不存在，因此你可以高枕无忧了，因为你知道你的站点上的 SSL 确实在为你的用户数据传输保驾护航.

HTTPS 速度是快的

上面我曾提到 HTTPS“遭罪似的慢” , 但事实则几乎完全相反.

HTTPS 确实需要更多的 CPU 来中断 SSL 连接 — 这需要的处理能力对于现代计算机而言是小菜一碟了.  你会遇到 SSL 性能瓶颈的可能性完全为 0.

目前你更有可能在你的应用程序或者 web 服务器性能上遇到瓶颈.

HTTPS 是一个重要的保障

虽然 HTTPS 并不放之四海而皆准的 web 安全方案，但是没有它你就不能以策万全.

所有的 web 安全都倚赖你拥有了 HTTPS.  如果你没有它， 那么不管你对你的密码做了多强的哈希加密，或者做了多少数据加密，攻击者都可以简单的模拟一个客户端的网络连接，读取它们的安全凭证——然后轰的一声——你的安全小把戏结束了.

因此 — 虽然你不能有赖于 HTTPS 解决所有的安全问题，你绝对 100% 需要将其应用于你构建的所有服务上 — 否则完全没有任何办法保证你的应用程序的安全.

此外，虽然证书签名很显然不是一个完美的实践，但每一种浏览器厂商针对认证机构都有相当严格和严谨的规则. 要成为一个受到信任的认证机构是非常难的，而且要保持自己良好的信誉也同样是困难的.

Mozilla (以及其其他厂商) 在将不良根认证机构踢出局这项工作方面表现相当出色，而且一般也真正是互联网安全的好管家.

HTTPS 流量拦截是可以避免的

先前我提到过，可以很容易的通过创建属于你自己的 SSL 证书、信任它们，从而在 SSL 通讯的中途拦截到流量.

虽然这绝对有可能，但也很容易可以通过 SSL 证书钢钉 来避免 .

本质上讲，依照上面链接的文章中给出的准则， 你可以是的你的客户只去信任真正可用的 SSL 证书，有效的阻挡所有类型的 SSL MITM 攻击，甚至在它们开始之前 =)

 

如果你是要把 SSL 服务部署到一个不受信任的位置(像是一个移动或者桌面应用)， 你最应该考虑使用 SSL 证书钢钉.

HTTPS（再也）不贵了

虽然历史上 HTTPS 曾经昂贵过，而这是事实 — 但再也不是这样了. 如今你能够从许许多多的 web 主机那里买到非常便宜的 SSL 证书.

此外， EFF (电子前沿基金会) 正要推出一个完全免费的 SSL 证书提供机构: https://letsencrypt.org/

它会在 2015 推出， 并必然将改变所有 web 开发者的游戏规则. 一旦让加密的方案上线，你就能够对你的网站和服务进行 100% 的加密，完全没有任何花费.

请一定要访问他们的网站，并订阅更新哦!

HTTP 在私有网络上并不是安全的

早些时候，我谈到 HTTP 的安全性怎么是不重要的，特别是如果你的网络被锁上（这里的意思是切断了同公共网络的联系） — 我是在骗你。

而网络安全是重要的，传输的加密也是！

如果一个攻击者获得了对你的任何内部服务的访问权限，所有的 HTTP 流量都将会被拦截和解读， 不管你的网络可能会有多“安全”. 这很不妙哦。

这就是为什么 HTTPS 不管是在公共网络还是私有网络都极其重要的原因。

额外的信息: 如果你是吧服务部署在 AWS 上面，就不要想让你的网络流量是私有的了!  AWS 网络就是公共的，这意味着其它的 AWS 用户都潜在的能够嗅探到你的网络流量 — 要非常小心了。

我早些时候有提到，HTTP 可以用来代替队列，是的，我没说错，但这是一个很可怕的主意！

由于安全原因，放大服务的规模，是一个很可怕的，糟糕的注意。请不要这么做。

（除非这是一个概念证据，只为了造一个很酷的演示产品而已）

总结

如果你正在做网页服务，毫无疑问，你应该使用 HTTPS。

它很容易、廉价，且能获得用户信任，没有理由不用它。作为码农，我们必须要承担起保护用户的重任，要做到那点，方法之一就是强制使用 HTTPS