@Lenciel

HTTPS WHAT?

最近 NSA 相关话题很火。很多 IT 从业者都知道,HTTPS 可以保护用户敏感的数据,但是说起 HTTPS 到底 是如何工作的,其实心里并不清楚。

使用 HTTPS 之后,数据是如何被保护的?Client 和 Server 之间如果有人在 hacking,HTTPS 建立的连接凭什么就是安全的?什么是安全证书?为什么有时候我们需要付钱才能买到一个?

A Series of Tubes

当你访问网页的时候,你发出的请求其实要翻越各种网关走很长的路,这一路上都可能有妖魔鬼怪在等着搞你,的数据。

Don't touch me

一般我们访问网页的时候,请求使用的是 HTTP,也就是 Client 和 Server 之间的数据是明文传送的。HTTP没有使用任何加密的原因有很多:

  • 加密会消耗更多的计算能力
  • 加密会消耗更多的带宽
  • 加密破坏了 Cache

当然,还有一个很多开发组织羞于承认的原因,加密增加了开发的难度。但是,只要是负责任的 Web 应用开发者,都不会让你的密码等关键信息以明文的方式传来传去。

Transport Layer Security (TLS)

TLS 作为 SSL 的前驱协议,常常被用来实现对 HTTP 连接的加密(比如用来实现 HTTPS)。TLS 是传输层的,因此在OSI模型里面比 HTTP 更底层,换句话说,在 HTTP 连接之前,先要进行 TLS 连接的建立。

TLS 是一种混合型的加密系统,也就是说它使用了多种加密技术体系,比如:

Public Key Cryptography

Symmetric Key Cryptography

Public Key Encryption

Public Key Encryption使用公钥私钥进行加密解密:通信中的各方都有一对公钥私钥。明文信息用公钥加密成密文,密文用私钥解密成明文。

这种加密系统理想之处在于,在一个公开的没有加密的连接中,可以迅速地为之前互不相干的通信双方建立起一个加密了的连接。

当一条消息被加密成密文之后,只能使用加密用的公钥对应的私钥才能解密。这些钥匙的命名也体现了它们的使用场景:公钥可以被公开,但是私钥一定要收好。

以 CS 架构的系统为例,Client 和 Server 都可以使用自己的私钥,只要在 session 中双方都认可所谓的shared secret key。这样即使有人监听了 Client 和 Server 之间的通信,他也没法知道 Client 或者 Server 的私钥,同时也不知道 session 的密钥。

这是怎么做到的? 数学!

Diffie-Hellman

这种交换通常使用所谓的Diffie-Hellman密钥交换流程。这套流程主要是让 Client 和 Server 之间生成一个shared secret key

假设 Alice 和 Bob 在做 DH 交换(不是 Desperate Housewife),他们会先明文共享一个 root值 (一般是 2、3 或者 5 这样的整数)和一个大质数 (300%2B 位整数)。

如前所述,Alice 和 Bob 还有自己的私钥(100%2B 位的整数),他们不能告诉对方私钥,而是通过双方共享的root和大质数计算出一个mixture

Alice的mixture = (root的Alice私钥值次方) % 大质数 Bob的mixture = (root的Bob私钥值次方) % 大质数

注意这里的%是模运算

计算出mixture之后,Alice 和 Bob 就把这个结果发送给对方,然后继续如下的计算:

Alice这边:(Bob的mixture的Alice私钥值次方) % 大质数 Bob这边:(Alice的Bob私钥值次方) % 大质数

这样在 Bob 和 Alice 两边独立计算,但得出的结果却是一致的:这就是shared secret了。可以看到这个流程的设计非常注意信息的保护:整个过程中双方没有交换自己的私钥,最后得到的shared secret也没在网络上发送。

对数学计算不感冒的同学,下面这张 Wikipedia 的配图非常直观:

Diffie-Hellman Key Exchange

从图里可以看到,双方一开始共享的黄色,在最后生成了共享的褐色,而这期间交换的只有被称为mixture的中间产物:即使有人监听并拿到,也无所谓。

Symmetric Key Encryption

前面说的这种流程每个 session 只用在初始化连接的时候发生一次。一旦生成了shared secret,Client 和 Server 之间就可以使用symmetric-key加密系统了。

这种使用shared secret的加密通信会涉及一系列的cipher suite,也就是一系列的加密算法。

认证

Diffie-Hellman 密钥交换流程没有解决认证的问题。这就好比我们拿起电话跟朋友打过去,先进行了 DH 交换,这样这次通话是其他人没法破解的。但是如果其实对方根本就不是朋友,那么还是白加密了。

为了解决认证的问题,我们需要 Public Key Infrastructure 来确保对方是我们要通信的对象。这些 infrastructure 用来创建,管理,发放和注销签名证书:没错,就是你花钱买了才能让你的网站可以使用 HTTPS 的可恶的证书。

证书是什么东西?为什么它可以让通信更安全?

证书

粗略地说,证书就是一个使用数字签名把机器的公钥和身份进行绑定的文件,来防止有人把自己的公钥亮出来冒充他人身份。在实际操作中,身份主要是通过域名来体现。

大多数的 web 浏览器都会检查证书有没有使用可信的Certificate Authority或者说CA授权的签名。CA 在授权之前,会进行人工检查,看证书申请者是否:

  1. 实际存在的人或者组织
  2. 对自己声称的身份,比如域名,有所有权

一旦授权签名,就说明认定证书所有者的身份和它提供的公钥是绑定的。

我们的浏览器都会添加一堆可信的 CA 证书,而如果访问的服务器不能返回可信的 CA 证书,浏览器就会提示用户。换句话说,即使一个恶意网站生成了绑定自己机器公钥的证书声称自己是 facebook.com,因为这个证书不是可信 CA 的,浏览器也不会相信它。

增强型证书

除开一般的X.509证书,还有一种增强型证书提供一种更强的身份校验。

要申请这种证书 CA 会进行更细致的检查,比如要求提供使用域名的账单等。一旦使用了这种证书,在有的浏览器工具栏上可以看到站点是绿色的。

一个服务器多个站点

一般如果多个网站使用同一个服务器来部署会使用named virtual hosts。但由于 TLS 握手发生在 HTTP 连接建立之前,所以可能会造出 问题

因此如果你的网站需要 HTTPS,空间提供者都会要求你租用独立 IP 的服务器。

最后,Wikipedia 是研究这种东西的好去处, 也可以看看 Coursera的这个课程