HTTPS详解

文章同步于 Github/blog

人们会用 Web 事务来处理一些很重要的事情。若是没有强有力的安全保证，人们就 没法安心地进行网络购物或使用银行业务。若是没法严格限制访问权限，公司就不 能将重要的文档放在 Web 服务器上。Web 须要一种安全的 HTTP 形式。

目前已存在一些提供认证(基本认证和 摘要认证 )和报文完整性检查(摘要 qop="auth-int")的轻量级方法。对不少网络事务来讲，这些方法都是很好用的， 但对大规模的购物、银行事务，或者对访问机密数据来讲，并不足够强大。这些更 为重要的事务须要将 HTTP 和数字加密技术结合起来使用，才能确保安全。

HTTP 的安全版本要高效、可移植且易于管理，不但可以适应不断变化的状况并且还应 该能知足社会和政府的各项要求。咱们须要一种可以提供下列功能的 HTTP 安全技术。

• 服务器认证 (客户端知道它们是在与真正的而不是伪造的服务器通话)。
• 客户端认证 (服务器知道它们是在与真正的而不是伪造的客户端通话)。
• 完整性 (客户端和服务器的数据不会被修改)。
• 加密 (客户端和服务器的对话是私密的，无需担忧被窃听)。
• 效率 (一个运行的足够快的算法，以便低端的客户端和服务器使用)。
• 普适性 (基本上全部的客户端和服务器都支持这些协议)。
• 管理的可扩展性 (在任何地方的任何人均可以当即进行安全通讯)。
• 适应性 (可以支持当前最知名的安全方法)。
• 在社会上的可行性 (知足社会的政治文化须要)。

数字加密

术语

在这个数字加密技术的入门介绍中，咱们会讨论如下内容。

• 密钥：改变密码行为的数字化参数。
• 对称密钥加密系统：编 / 解码使用相同密钥的算法。
• 不对称密钥加密系统：编 / 解码使用不一样密钥的算法。
• 公开密钥加密系统：一种可以使数百万计算机便捷地发送机密报文的系统。
• 数字签名：用来验证报文未被伪造或篡改的校验和。
• 数字证书：由一个可信的组织验证和签发的识别信息。

密码

密码学基于一种名为密码(cipher)的秘密代码。密码是一套编码方案——一种特 殊的报文编码方式和一种稍后使用的相应解码方式的结合体。加密以前的原始报文一般被称为 明文(plaintext 或 cleartext)。使用了密码以后的编码报文一般被称做 密文(ciphertext)。

用密码来生成保密信息已经有数千年了。传说 尤利乌斯·凯撒(Julius Caesar) 曾使用过一种三字符循环移位密码，报文中的每一个字符都由字母表中三个位置以后的字符来取代。在现代的字母表中，“A”就应该由“D”来取代，“B”就应该由“E” 来取代，以此类推。

密钥

随着技术的进步，人们开始制造一些机器，这些机器能够用复杂得多的密码来快速、 精确地对报文进行编解码。这些密码机不只能作一些简单的旋转，它们还能够替换 字符、改变字符顺序，将报文切片切块，使代码的破解更加困难。

每每在现实中，编码算法和编码机均可能会落入敌人的手中，因此大部分机器上都有一些号盘，能够将其设置为大量不一样的值以改变密码的工做方式。即便机器被盗，没有正确的号盘设置(密钥值)，解码器也没法工做。

这些密码参数被称为 密钥(key)。要在密码机中输入正确的密钥，解密过程才能正确进行。密码密钥会让一个密码机看起来好像是多个虚拟密码机同样，每一个密码机 都有不一样的密钥值，所以其行为都会有所不一样。

给定一段明文报文 P、一个编码函数 E 和一个数字编码密钥 e，就能够生成一段经 过编码的密文 C。经过解码函数 D 和解码密钥 d，能够将密文 C 解 码为原始的明文 P。固然，编 / 解码函数都是互为反函数的，对 P 的编码进行解码 就会回到原始报文 P 上去。

对称密钥加密技术

不少数字加密算法都被称为 对称密钥(symmetric-key) 加密技术，这是由于它们在编码时使用的密钥值和解码时 同样(e=d)。咱们就将其统称为密钥 k。

流行的对称密钥加密算法包括：DES、Triple-DES、RC2 和 RC4。

保持密钥的机密状态是很重要的。在不少状况下，编 / 解码算法都是众所周知的，所以密钥就是惟一保密的东西了。好的加密算法会迫使攻击者试遍每个可能的密钥，才能破解代码。用暴力去尝试 全部的密钥值称为 枚举攻击(enumeration attack)。

缺点

对称密钥加密技术的缺点之一就是发送者和接收者在互相对话以前，必定要有一个共享的保密密钥。

好比 Alice(A)、Bob(B)和 Chris(C)都想与 Joe 的 五金商店(J) 对话。A、B 和 C 都要创建本身与 J 之间的保密密钥。A 可能须要密钥 KAJ，B 可能须要密钥 KBJ，C 可能须要密钥 KCJ。每对通讯实体都须要本身的私有密钥。若是有 N 个节点， 每一个节点都要和其余全部 N-1 个节点进行安全对话，总共大概会有 N2 个保密密钥: 这将是一个管理噩梦。

公开密钥加密技术

公开密钥加密技术没有为每对主机使用单独的加密 / 解密密钥，而是使用了两个非对称密钥：一个用来对主机报文编码，另外一个用来对主机报文解码。

RSA

全部公开密钥非对称加密系统所面临的共同挑战是，要确保即使有人拥有了下面全部的线索，也没法计算出保密的私有密钥:

• 公开密钥 (是公有的，全部人均可以得到);
• 一小片拦截下来的密文 (可经过对网络的嗅探获取);
• 一条报文及与之相关的密文 (对任意一段文本运行加密器就能够获得)。

RSA算法 就是一个知足了全部这些条件的流行的公开密钥加密系统，它是在 MIT 发明的，后来由 RSA 数据安全公司将其商业化。即便有了公共密钥、任意一段明文、用公共密钥对明文编码以后获得的相关密文、RSA 算法自身，甚至 RSA 实现 的源代码，破解代码找到相应的私有密钥的难度仍至关于对一个极大的数进行质因数分解的困难程度，这种计算被认为是全部计算机科学中最难的问题之一。所以， 若是你发现了一种可以快速地将一个极大的数字分解为质因数的方法，就不只可以入侵瑞士银行的帐户系统，并且还能够得到图灵奖了。

混合加密系统和会话密钥

任何人只要知道了其公开密钥，就能够向一台公共服务器发送安全报文，因此非对称的公开密钥加密系统是很好用的。两个节点无须为了进行安全的通讯而先交换私有密钥。

但公开密钥加密算法的计算可能会很慢。实际上它混合使用了对称和非对称策略。 好比，比较常见的作法是在两节点间经过便捷的公开密钥加密技术创建起安全通讯， 而后再用那条安全的通道产生并发送临时的随机对称密钥，经过更快的对称加密技 术对其他的数据进行加密。（SSH和HTTPS都是这样的）

数字签名

除了加 / 解密报文以外，还能够用加密系统对报文进行签名(sign)，以说明是谁编写的报文，同时证实报文未被篡改过。这种技术被称为数字签名(digital signing)。

数字签名是附加在报文上的特殊加密校验码。数字签名一般是用 非对称公开密钥技术产生的。由于只有全部者才知道其私有密钥， 因此能够将做者的私有密钥看成一种“指纹”使用。

RSA 加密系统将解码函数 D 做为签名函数使用，是由于 D 已经将私有密钥做为输入使用了。注意， 解码函数只是一个函数，所以，能够将其用于任意的输入。一样，在 RSA 加密系统中，以任意顺序 应用 D 和 E 函数时，二者都会相互抵消。所以 E(D(stuff)) = stuff，就像 D(E(stuff)) = stuff 同样。

注意

私钥和公钥是一对，均可以加解密，配对使用。RSA 的原理，两个大质数(p,q)乘积(n)难以逆向求解，因此 pq 是对等的，公钥和私钥也是对等的。

1. 私钥加密公钥解密，能证实“私钥拥有者” 的惟一身份，用于签名。
2. 公钥加密私钥解密，确保发送的信息，只有有“私钥拥有者” 可以解密，（若是用私钥加密，传递数据，则会被公钥持有者（可能有不少持有者） 解密，失去对信息的保护）

数字证书

因特网上的“ID 卡”——数字证书。数字证书(一般被称做“certs”，有点像 certs 牌薄荷糖)中包含了由某个受信任组织担保的用户或公司的相关信息。

数字证书中还包含一组信息，全部这些信息都是由一个官方的 证书颁发机构(CA) 以数字方式签发的。

并且，数字证书一般还包括对象的公开密钥，以及对象和所用签名算法的描述性信息。任何人均可以建立一个数字证书，但并非全部人都可以得到受人尊敬的签发 权，从而为证书信息担保，并用其私有密钥签发证书。典型的证书结构如图所示。

X.509 v3证书

不幸的是，数字证书没有单一的全球标准。就像不是全部印刷版 ID 卡都在一样的位 置包含了一样的信息同样，数字证书也有不少略有不一样的形式。 不过好消息就是现 在使用的大多数证书都以一种标准格式—— X.509 v3，来存储它们的信息。X.509 v3 证书提供了一种标准的方式，将证书信息规范至一些可解析字段中。不一样类型的证 书有不一样的字段值，但大部分都遵循X.509 v3结构。

基于 X.509 证书的签名有好几种，(其中)包括 Web 服务器证书、客户端电子邮件 证书、软件代码签名证书和证书颁发机构证书。

用证书对服务器进行认证

经过 HTTPS 创建了一个安全 Web 事务以后，现代的浏览器都会自动获取所链接服 务器的数字证书。若是服务器没有证书，安全链接就会失败。

浏览器收到证书时会对签名颁发机构进行检查。若是这个机构是个颇有权威的公共签名机构，浏览器可能已经知道其公开密钥了(浏览器会预先安装不少签名颁发机构的证书)。

若是对签名颁发机构一无所知，浏览器就没法肯定是否应该信任这个签名颁发机构， 它一般会向用户显示一个对话框，看看他是否相信这个签名发布者。签名发布者可 能是本地的 IT 部门或软件厂商。

HTTPS

HTTPS 是最流行的 HTTP 安全形式。它是由网景公司独创的，全部主要的浏览器和 服务器都支持此协议。

使用 HTTPS 时，全部的 HTTP 请求和响应数据在发送到网络以前，都要进行加密。 HTTPS 在 HTTP 下面提供了一个传输级的密码安全层——可使用 SSL，也可使用其后继者—— 传输层安全(Transport Layer Security，TLS)。因为 SSL 和 TLS 很是相似，因此咱们不太严格地用术语 SSL 来表示 SSL 和 TLS。

SSL/TLS

不使用SSL/TLS的HTTP通讯，就是不加密的通讯。全部信息明文传播，带来了三大风险。

• 窃听风险（eavesdropping）：第三方能够获知通讯内容。
• 篡改风险（tampering）：第三方能够修改通讯内容。
• 冒充风险（pretending）：第三方能够冒充他人身份参与通讯。

SSL/TLS协议是为了解决这三大风险而设计的，但愿达到：

• 全部信息都是加密传播，第三方没法窃听。
• 具备校验机制，一旦被篡改，通讯双方会马上发现。
• 配备身份证书，防止身份被冒充。

SSL（Secure Socket Layer）是安全套接层，TLS（Transport Layer Security）是传输层安全协议，创建在SSL3.0协议规范，是 SSL3.0 的后续版本。SSL 直到 3.0版本才大规模的部署和应用。 TLS 版本相比于 SSL 变化明显的是支持的加密算法不一样。当前最新使用的是TLS1.2协议。1.3版本还在草案阶段。

HTTPS方案

如今，安全 HTTP 是可选的。请求一个客户端(好比 Web 浏览器)对某 Web 资源执行某事务时，它会去检查 URL 的方案：

• 若是URL的方案为http，客户端就会打开一条到服务器端口80(默认状况下) 的链接，并向其发送老的 HTTP 命令。
• 若是URL的方案为https，客户端就会打开一条到服务器端口443(默认状况下) 的链接，而后与服务器“握手”，以二进制格式与服务器交换一些 SSL 安全参数， 附上加密的 HTTP 命令。

SSL 是个二进制协议，与 HTTP 彻底不一样，其流量是承载在另外一个端口上的(SSL 一般是由端口 443 承载的)。若是 SSL 和 HTTP 流量都从端口 80 到达，大部分 Web 服务器会将二进制 SSL 流量理解为错误的 HTTP 并关闭链接。将安全服务进一步整 合到 HTTP 层中去就无需使用多个目的端口了，在实际中这样不会引起严重的问题。

SSL握手

开始加密通讯以前，客户端和服务器首先必须创建链接和交换参数，这个过程叫作握手（handshake）。假定客户端叫作爱丽丝，服务器叫作鲍勃，整个握手过程能够用下图说明。

握手阶段分红五步：

1. 爱丽丝给出协议版本号、一个客户端生成的 随机数（Client random），以及客户端支持的加密方法。
2. 鲍勃确认双方使用的加密方法，并给出数字证书、以及一个 服务器生成的随机数（Server random）。
3. 爱丽丝确认数字证书有效，而后生成一个新的 随机数（Premaster secret），并使用数字证书中的公钥，加密这个随机数，发给鲍勃。
4. 鲍勃使用本身的私钥，获取爱丽丝发来的随机数（即Premaster secret）。
5. 爱丽丝和鲍勃根据约定的加密方法，使用前面的三个随机数，生成 对话密钥（session key），用来加密接下来的整个对话过程。

上面的五步，画成一张图，就是下面这样：

握手阶段有三点须要注意：

1. 生成对话密钥一共须要三个随机数。
2. 握手以后的对话使用 对话密钥（session key） 加密（对称加密），服务器的公钥和私钥只用于加密和解密 对话密钥（session key）（非对称加密），无其余做用。
3. 服务器公钥放在服务器的数字证书之中。

DH算法的握手阶段

整个握手阶段都不加密（也无法加密），都是明文的。所以，若是有人窃听通讯，他能够知道双方选择的加密方法，以及三个随机数中的两个。整个通话的安全，只取决于 第三个随机数（Premaster secret）能不能被破解。

虽然理论上，只要服务器的公钥足够长（好比2048位），那么 Premaster secret 能够保证不被破解。可是为了足够安全，咱们能够考虑把握手阶段的算法从默认的 RSA算法，改成 Diffie-Hellman算法（简称DH算法）。

采用 DH算法 后，Premaster secret 不须要传递，双方只要交换各自的参数，就能够算出这个随机数。

上图中，第三步和第四步由传递 Premaster secret 变成了传递 DH算法 所需的参数，而后双方各自算出 Premaster secret。这样就提升了安全性。

服务器证书

SSL 支持双向认证，将服务器证书承载回客户端，再将客户端的证书回送给服务器。 而如今，浏览时并不常用客户端证书。大部分用户甚至都没有本身的客户端证书。服务器能够要求使用客户端证书，但实际中不多出现这种状况。

站点证书的有效性

SSL 自身不要求用户检查 Web 服务器证书，但大部分现代浏览器都会对证书进行简 单的完整性检查，并为用户提供进行进一步彻查的手段。网景公司提出的一种 Web 服务器证书有效性算法是大部分浏览器有效性验证技术的基础。验证步骤以下所述：

• 日期检测 首先，浏览器检查证书的起始日期和结束日期，以确保证书仍然有效。若是证书 过时了，或者还未被激活，则证书有效性验证失败，浏览器显示一条错误信息。
• 签名颁发者可信度检测 每一个证书都是由某些 证书颁发机构(CA) 签发的，它们负责为服务器担保。证书有不一样的等级，每种证书都要求不一样级别的背景验证。好比，若是申请某个电 子商务服务器证书，一般须要提供一个营业的合法证实。
  任何人均可以生成证书，但有些 CA 是很是著名的组织，它们经过很是清晰的流 程来验证证书申请人的身份及商业行为的合法性。所以，浏览器会附带一个签名颁发机构的受信列表。若是浏览器收到了某未知(多是恶意的)颁发机构签发的证书，那它一般会显示一条警告信息。
• 签名检测 一旦断定签名受权是可信的，浏览器就要对签名使用签名颁发机构的公开密钥， 并将其与校验码进行比较，以查看证书的完整性。
• 站点身份检测 为防止服务器复制其余人的证书，或拦截其余人的流量，大部分浏览器都会试着 去验证证书中的域名与它们所对话的服务器的域名是否匹配。服务器证书中一般 都包含一个域名，但有些 CA 会为一组或一群服务器建立一些包含了服务器名称 列表或通配域名的证书。若是主机名与证书中的标识符不匹配，面向用户的客户 端要么就去通知用户，要么就以表示证书不正确的差错报文来终止链接。

HTTPS客户端

SSL 是个复杂的二进制协议。除非你是密码专家，不然就不该该直接发送原始的 SSL 流量。幸运的是，借助一些商业或开源的库，编写 SSL 客户端和服务器并不十 分困难。

OpenSSL 是 SSL 和 TLS 最多见的开源实现。OpenSSL 项目由一些志愿者合做开发， 目标是开发一个强壮的、具备完备功能的商业级工具集，以实现 SSL 和 TLS 协议以 及一个全功能的通用加密库。能够从 http://www.openssl.org 上得到 OpenSSL 的相 关信息，并下载相应软件。

后记

强烈推荐一本书：HTTP 权威指南

参考

• 超详解析 | CDN HTTPS优化实践，全网一分钟生效
• 图解SSL/TLS协议
• HTTP 权威指南