聊聊HTTPS和SSL/TLS协议

聊聊HTTPS和SSL/TLS协议

 要说清楚 HTTPS 协议的实现原理，至少须要以下几个背景知识。

1. 大体了解几个基本术语（HTTPS、SSL、TLS）的含义
2. 大体了解 HTTP 和 TCP 的关系（尤为是“短链接”VS“长链接”）
3. 大体了解加密算法的概念（尤为是“对称加密与非对称加密”的区别）
4. 大体了解 CA 证书的用途

考虑到不少技术菜鸟可能不了解上述背景，俺先用最简短的文字描述一下。若是你自认为不是菜鸟，请略过本章节，直接去看“HTTPS 协议的需求”。

先澄清几个术语——HTTPS、SSL、TLS

1. “HTTP”是干吗用滴？

首先，HTTP 是一个网络协议，是专门用来帮你传输 Web 内容滴。关于这个协议，就算你不了解，至少也据说过吧？好比你访问俺的博客的主页，浏览器地址栏会出现以下的网址

http://www.techug.com/

俺加了粗体的部分就是指 HTTP 协议。大部分网站都是经过 HTTP 协议来传输 Web 页面、以及 Web 页面上包含的各类东东（图片、CSS 样式、JS 脚本）。

2. “SSL/TLS”是干吗用滴？

SSL 是洋文“Secure Sockets Layer”的缩写，中文叫作“安全套接层”。它是在上世纪90年代中期，由网景公司设计的。（顺便插一句，网景公司不光发明了 SSL，还发明了不少 Web 的基础设施——好比“CSS 样式表”和“JS 脚本”）
为啥要发明 SSL 这个协议捏？由于原先互联网上使用的 HTTP 协议是明文的，存在不少缺点——好比传输内容会被偷窥（嗅探）和篡改。发明 SSL 协议，就是为了解决这些问题。
到了1999年，SSL 由于应用普遍，已经成为互联网上的事实标准。IETF 就在那年把 SSL 标准化。标准化以后的名称改成 TLS（是“Transport Layer Security”的缩写），中文叫作“传输层安全协议”。
不少相关的文章都把这二者并列称呼（SSL/TLS），由于这二者能够视做同一个东西的不一样阶段。

3. “HTTPS”是啥意思？

解释完 HTTP 和 SSL/TLS，如今就能够来解释 HTTPS 啦。我们一般所说的 HTTPS 协议，说白了就是“HTTP 协议”和“SSL/TLS 协议”的组合。你能够把 HTTPS 大体理解为——“HTTP over SSL”或“HTTP over TLS”（反正 SSL 和 TLS 差很少）。

再来讲说 HTTP 协议的特色

做为背景知识介绍，还须要再稍微谈一下 HTTP 协议自己的特色。HTTP 自己有不少特色，考虑到篇幅有限，俺只谈那些和 HTTPS 相关的特色。

1. HTTP 的版本和历史

现在我们用的 HTTP 协议，版本号是 1.1（也就是 HTTP 1.1）。这个 1.1 版本是1995年末开始起草的（技术文档是 RFC2068），并在1999年正式发布（技术文档是 RFC2616）。
在 1.1 以前，还有曾经出现过两个版本“0.9 和 1.0”，其中的 HTTP 0.9 【没有】被普遍使用，而 HTTP 1.0 被普遍使用过。
另外，听说明年（2015）IETF 就要发布 HTTP 2.0 的标准了。俺拭目以待。

2. HTTP 和 TCP 之间的关系

简单地说，TCP 协议是 HTTP 协议的基石——HTTP 协议须要依靠 TCP 协议来传输数据。

在网络分层模型中，TCP 被称为“传输层协议”，而 HTTP 被称为“应用层协议”。

有不少常见的应用层协议是以 TCP 为基础的，好比“FTP、SMTP、POP、IMAP”等。
TCP 被称为“面向链接”的传输层协议。关于它的具体细节，俺就不展开了（不然篇幅又失控了）。你只需知道：传输层主要有两个协议，分别是 TCP 和 UDP。TCP 比 UDP 更可靠。你能够把 TCP 协议想象成某个水管，发送端这头进水，接收端那头就出水。而且 TCP 协议可以确保，先发送的数据先到达（与之相反，UDP 不保证这点）。

3. HTTP 协议如何使用 TCP 链接？

HTTP 对 TCP 链接的使用，分为两种方式：俗称“短链接”和“长链接”（“长链接”又称“持久链接”，洋文叫作“Keep-Alive”或“Persistent Connection”）
假设有一个网页，里面包含好多图片，还包含好多【外部的】CSS 文件和 JS 文件。在“短链接”的模式下，浏览器会先发起一个 TCP 链接，拿到该网页的 HTML 源代码（拿到 HTML 以后，这个 TCP 链接就关闭了）。而后，浏览器开始分析这个网页的源码，知道这个页面包含不少外部资源（图片、CSS、JS）。而后针对【每个】外部资源，再分别发起一个个 TCP 链接，把这些文件获取到本地（一样的，每抓取一个外部资源后，相应的 TCP 就断开）
相反，若是是“长链接”的方式，浏览器也会先发起一个 TCP 链接去抓取页面。可是抓取页面以后，该 TCP 链接并不会当即关闭，而是暂时先保持着（所谓的“Keep-Alive”）。而后浏览器分析 HTML 源码以后，发现有不少外部资源，就用刚才那个 TCP 链接去抓取此页面的外部资源。

在 HTTP 1.0 版本，【默认】使用的是“短链接”（那时候是 Web 诞生初期，网页相对简单，“短链接”的问题不大）；
到了1995年末开始制定 HTTP 1.1 草案的时候，网页已经开始变得复杂（网页内的图片、脚本愈来愈多了）。这时候再用短链接的方式，效率过低下了（由于创建 TCP 链接是有“时间成本”和“CPU 成本”滴）。因此，在 HTTP 1.1 中，【默认】采用的是“Keep-Alive”的方式。
关于“Keep-Alive”的更多介绍，能够参见维基百科词条（在“这里”）

谈谈“对称加密”和“非对称加密”的概念

1. 啥是“加密”和“解密”？

通俗而言，你能够把“加密”和“解密”理解为某种【互逆的】数学运算。就比如“加法和减法”互为逆运算、“乘法和除法”互为逆运算。
“加密”的过程，就是把“明文”变成“密文”的过程；反之，“解密”的过程，就是把“密文”变为“明文”。在这两个过程当中，都须要一个关键的东东——叫作“密钥”——来参与数学运算。

2. 啥是“对称加密”？

所谓的“对称加密技术”，意思就是说：“加密”和“解密”使用【相同的】密钥。这个比较好理解。就比如你用 7zip 或 WinRAR 建立一个带密码（口令）的加密压缩包。当你下次要把这个压缩文件解开的时候，你须要输入【一样的】密码。在这个例子中，密码/口令就如同刚才说的“密钥”。

3. 啥是“非对称加密”？

所谓的“非对称加密技术”，意思就是说：“加密”和“解密”使用【不一样的】密钥。这玩意儿比较难理解，也比较难想到。当年“非对称加密”的发明，还被誉为“密码学”历史上的一次革命。
因为篇幅有限，对“非对称加密”这个话题，俺就不展开了。有空的话，再单独写一篇扫盲。

4. 各自有啥优缺点？

看完刚才的定义，很显然：（从功能角度而言）“非对称加密”能干的事情比“对称加密”要多。这是“非对称加密”的优势。可是“非对称加密”的实现，一般须要涉及到“复杂数学问题”。因此，“非对称加密”的性能一般要差不少（相对于“对称加密”而言）。
这二者的优缺点，也影响到了 SSL 协议的设计。

CA 证书的原理及用途

关于这方面，请看俺4年前写的《数字证书及CA的扫盲介绍》。这里就再也不重复唠叨了，省得篇幅太长。

HTTPS 协议的需求是啥？

花了好多口水，终于把背景知识说完了。下面正式进入正题。先来讲说当初设计 HTTPS 是为了知足哪些需求？
不少介绍 HTTPS 的文章一上来就给你讲实现细节。我的以为：这是很差的作法。早在2009年开博的时候，发过一篇《学习技术的三部曲：WHAT、HOW、WHY》，其中谈到“WHY 型问题”的重要性。一上来就给你讲协议细节，你充其量只能知道 WHAT 和 HOW，没法理解 WHY。俺在前一个章节讲了“背景知识”，在这个章节讲了“需求”，这就有助于你理解：当初

为何

要设计成这样？——这就是 WHY 型的问题。

兼容性

由于是先有 HTTP 再有 HTTPS。因此，HTTPS 的设计者确定要考虑到对原有 HTTP 的兼容性。
这里所说的兼容性包括不少方面。好比已有的 Web 应用要尽量无缝地迁移到 HTTPS；好比对浏览器厂商而言，改动要尽量小；……
基于“兼容性”方面的考虑，很容易得出以下几个结论：
1. HTTPS 仍是要基于 TCP 来传输
（若是改成 UDP 做传输层，不管是 Web 服务端仍是浏览器客户端，都要大改，动静太大了）
2. 单独使用一个新的协议，把 HTTP 协议包裹起来
（所谓的“HTTP over SSL”，其实是在原有的 HTTP 数据外面加了一层 SSL 的封装。HTTP 协议原有的 GET、POST 之类的机制，基本上原封不动）

打个比方：若是原来的 HTTP 是塑料水管，容易被戳破；那么现在新设计的 HTTPS 就像是在原有的塑料水管以外，再包一层金属水管。一来，原有的塑料水管照样运行；二来，用金属加固了以后，不容易被戳破。

可扩展性

前面说了，HTTPS 至关因而“HTTP over SSL”。
若是 SSL 这个协议在“可扩展性”方面的设计足够牛逼，那么它除了能跟 HTTP 搭配，还可以跟其它的应用层协议搭配。岂不美哉？
如今看来，当初设计 SSL 的人确实比较牛。现在的 SSL/TLS 能够跟不少经常使用的应用层协议（好比：FTP、SMTP、POP、Telnet）搭配，来强化这些应用层协议的安全性。

接着刚才打的比方：若是把 SSL/TLS 视做一根用来加固的金属管，它不只能够用来加固输水的管道，还能够用来加固输煤气的管道。

保密性（防泄密）

HTTPS 须要作到足够好的保密性。
说到保密性，首先要可以对抗嗅探（行话叫 Sniffer）。所谓的“嗅探”，通俗而言就是监视你的网络传输流量。若是你使用明文的 HTTP 上网，那么监视者经过嗅探，就知道你在访问哪些网站的哪些页面。
嗅探是最低级的攻击手法。除了嗅探，HTTPS 还须要能对抗其它一些稍微高级的攻击手法——好比“重放攻击”（后面讲协议原理的时候，会再聊）。

完整性（防篡改）

除了“保密性”，还有一个一样重要的目标是“确保完整性”。关于“完整性”这个概念，在以前的博文《扫盲文件完整性校验——关于散列值和数字签名》中大体提过。健忘的同窗再去温习一下。
在发明 HTTPS 以前，因为 HTTP 是明文的，不但容易被嗅探，还容易被篡改。
举个例子：
好比我们天朝的网络运营商（ISP）都比较流氓，常常有网友抱怨说访问某网站（原本是没有广告的），居然会跳出不少中国电信的广告。为啥会这样捏？由于你的网络流量须要通过 ISP 的线路才能到达公网。若是你使用的是明文的 HTTP，ISP 很容易就能够在你访问的页面中植入广告。
因此，当初设计 HTTPS 的时候，还有一个需求是“确保 HTTP 协议的内容不被篡改”。

真实性（防假冒）

在谈到 HTTPS 的需求时，“真实性”常常被忽略。其实“真实性”的重要程度不亚于前面的“保密性”和“完整性”。
举个例子：
你由于使用网银，须要访问该网银的 Web 站点。那么，你如何确保你访问的网站确实是你想访问的网站？（这话有点绕口令）
有些天真的同窗会说：经过看网址里面的域名，来确保。为啥说这样的同窗是“天真的”？由于 DNS 系统自己是不可靠的（尤为是在设计 SSL 的那个年代，连 DNSSEC 都还没发明）。因为 DNS 的不可靠（存在“域名欺骗”和“域名劫持”），你看到的网址里面的域名【未必】是真实滴！
（不了解“域名欺骗”和“域名劫持”的同窗，能够参见俺以前写的《扫盲 DNS 原理，兼谈“域名劫持”和“域名欺骗/域名污染”》）
因此，HTTPS 协议必须有某种机制来确保“真实性”的需求（至于如何确保，后面会细聊）。

性能

再来讲最后一个需求——性能。引入 HTTPS 以后，【不能】致使性能变得太差。不然的话，谁还愿意用？为了确保性能，SSL 的设计者至少要考虑以下几点：1. 如何选择加密算法（“对称”or“非对称”）？2. 如何兼顾 HTTP 采用的“短链接”TCP 方式？（SSL 是在1995年以前开始设计的，那时候的 HTTP 版本仍是 1.0，默认使用的是“短链接”的 TCP 方式——默认不启用 Keep-Alive）