HTTP学习（四）认证

超、凢脫俗 2022-06-16 00:48 154阅读 0赞

HTTP作为现在非常重要的协议，需要仔细梳理一下。本次学习知识点来自于《HTTP权威指南》，只是文中知识点罗列，算是读书笔记，请有兴趣的读者购买《HTTP权威指南》完整阅读

一、认证机制

1、认证

认证就是要给出一些身份证明。 当出示像护照或驾照那样有照片的身份证件时， 就给出了一些证据， 说明你就是你所声称的那个人。 在自动取款机上输入 PIN 码， 或在计算机系统的对话框中输入了密码时， 也是在证明你就是你所声称的那个人。

2、HTTP的质询 / 响应 框架

HTTP 提供了一个原生的质询  / 响应（challenge/response） 框架， 简化了对用户的认证过程。 HTTP 的认证模型如图  12-1 中所示。  
Web 应用程序收到一条  HTTP 请求报文时， 服务器没有按照请求执行动作， 而是以一个“认证质询” 进行响应， 要求用户提供一些保密信息来说明他是谁， 从而对其进行质询。  
用户再次发起请求时， 要附上保密证书（用户名和密码）。 如果证书不匹配， 服务器可以再次质询客户端， 或产生一条错误信息。 如果证书匹配， 就可以正常完成请

![Center][]

3、基本认证过程

HTTP 定义了两个官方的认证协议： 基本认证和摘要认证。 今后人们可以随意设计一些使用 HTTP 质询 / 响应框架的新协议。

服务器对用户进行质询时， 会返回一条 401 Unauthorized 响应， 并在 WWW-Authenticate首部说明如何以及在哪里进行认证（参见图 12-2b）。  
当客户端授权服务器继续处理时， 会重新发送请求， 但会在 Authorization  首部附上加密的密码和其他一些认证参数（参见图 12-2c）。授权请求成功完成时， 服务器会返回一个正常的状态码（比如， 200 OK） ； 对高级认证算法来说， 可能还会在 Authentication-Info 首部附加一些额外的信息（参  
见图 12-2d）。

![Center 1][]

• 在图 12-2a 中， 用户请求了私人家庭相片 /family/jeff.jpg。  
• 在图 12-2b 中， 服务器回送一条 401 Authorization Required， 对私人家庭相片  
进行密码质询， 同时回送的还有 WWW-Authenticate 首部。 这个首部请求对  
Family 域进行基本认证。  
• 在图 12-2c 中， 浏 览 器 收 到 了 401 质 询， 弹 出 对 话 框， 询 问 Family 域 的 用  
户名和密码。 用户输入用户名和密码时， 浏览器会用一个冒号将其连接起  
来， 编码成“经过扰码的” Base-64 表示形式（下节介绍）， 然后将其放在  
Authorization 首部中回送。  
• 在图 12-2d 中， 服务器对用户名和密码进行解码， 验证它们的正确性， 然后用一  
条 HTTP 200 OK 报文返回所请求的报文。

WWWAuthenticate  质询中包含了一个  realm  指令。  Web  服务器会将受保护的文档组织成一个 安全域 （ security realm ）。 每个安全域都可以有不同的授权用户集。

5、 Base-64  用户名 / 密码编码

HTTP 基本认证将（由冒号分隔的） 用户名和密码打包在一起， 并用 Base-64 编码方式对其进行编码。

6、 基本认证的安全缺陷

基本认证简单便捷， 但并不安全。 只能用它来防止非恶意用户无意间进行的访问，或将其与 SSL 这样的加密技术配合使用。  
基本认证存在下列安全缺陷。  
(1) 基本认证会通过网络发送用户名和密码， 这些用户名和密码都是以一种很容易解码的形式表示的。 实际上， 密码是以明文形式传输的， 任何人都可以读取并将其捕获。 虽然 Base-64 编码通过隐藏用户名和密码， 致使友好的用户不太可能在进行网络观测时无意中看到密码， 但 Base-64 编码的用户名和密码可以很轻易地通过反向编码过程进行解码， 甚至可以用纸笔在几秒钟内手工对其进行解码！ 所以经过 Base-64 编码的密码实际上就是“明文” 传送的。 如果有动机的第三方用户有可能会去拦截基本认证发送的用户名和密码， 就要通过 SSL 加密信道发送所有的  HTTP 事务， 或者使用更安全的认证协议， 比如摘要认证。  
(2) 即使密码是以更难解码的方式加密的， 第三方用户仍然可以捕获被修改过的用户名和密码， 并将修改过的用户名和密码一次一次地重放给原始服务器， 以获得对服务器的访问权。 没有什么措施可用来防止这些重放攻击。

(3) 即使将基本认证用于一些不太重要的应用程序， 比如公司内部网络的访问控制或个性化内容的访问， 一些不良习惯也会让它变得很危险。 很多用户由于受不了大量密码保护的服务， 会在这些服务间使用相同的用户名和密码。 比如说， 某个狡猾的恶徒会从免费的因特网邮件网站捕获明文形式的用户名和密码， 然后会发现用同样的用户名和密码还可以访问重要的在线银行网站

(4) 基本认证没有提供任何针对代理和作为中间人的中间节点的防护措施， 它们没有修改认证首部， 但却修改了报文的其余部分， 这样就严重地改变了事务的本质。  
(5) 假冒服务器很容易骗过基本认证。 如果在用户实际连接到一台恶意服务器或网关的时候， 能够让用户相信他连接的是一个受基本认证保护的合法主机， 攻击者就可以请求用户输入密码， 将其存储起来以备未来使用， 然后捏造一条错误信息传送给用户。

二、摘要认证

1、摘要认证的改进

摘要认证是另一种 HTTP 认证协议， 它试图修复基本认证协议的严重缺陷。 具体来说， 摘要认证进行了如下改进。  
• 永远不会以明文方式在网络上发送密码。  
• 可以防止恶意用户捕获并重放认证的握手过程。  
• 可以有选择地防止对报文内容的篡改。  
• 防范其他几种常见的攻击方式。  
2、用摘要保护密码

摘要认证遵循的箴言是“绝不通过网络发送密码”。 客户端不会发送密码， 而是会发送一个“指纹” 或密码的“摘要”， 这是密码的不可逆扰码。 客户端和服务器都知道这个密码， 因此服务器可以验证所提供的摘要是否与密码相匹配。 只拿到摘要的话， 除了将所有的密码都拿来试试之外， 没有其他方法可以找出摘要是来自哪个密码

![Center 2][]

• 在图 13-1a 中， 客户端请求了某个受保护文档。  
• 在图 13-1b 中， 在客户端能够证明其知道密码从而确认其身份之前， 服务器拒绝提供文档。 服务器向客户端发起质询， 询问用户名和摘要形式的密码。  
• 在图 13-1c 中， 客户端传递了密码的摘要， 证明它是知道密码的。 服务器知道所有用户的密码， 5 因此可以将客户提供的摘要与服务器自己计算得到的摘要进行比较， 以验证用户是否知道密码。 另一方在不知道密码的情况下， 很难伪造出正确的摘要。  
• 在图 13-1d 中， 服务器将客户端提供的摘要与服务器内部计算出的摘要进行对比。如果匹配， 就说明客户端知道密码（或者很幸运地猜中了！ ）。 可以设置摘要函数， 使其产生很多数字， 让人不可能幸运地猜中摘要。 服务器进行了匹配验证之后， 会将文档提供给客户端——整个过程都没有在网络上发送密码。  
3、单向摘要

摘要是“对信息主体的浓缩”。 6 摘要是一种单向函数， 主要用于将无限的输入值转换为有限的浓缩输出值。 7 常见的摘要函数  MD5， 8 会将任意长度的字节序列转换为一个 128 位的摘要。  
128 位 = 2128， 或者大约1 000 000 000 000 000 000 000 000 000 000 000 000 000 种不同的输出值。  
对这些摘要来说， 最重要的是如果不知道密码的话， 要想正确地猜出发送给服务器的摘要将是非常困难的。 同样， 如果有摘要， 想要判断出它是由无数输入值中的哪一个产生的， 也是非常困难的。

4、摘要认证的握手机制  
![Center 3][]

• 在第（1） 步中， 服务器会计算出一个随机数。 在第（2） 步中， 服务器将这个随机数放在 WWW-Authenticate 质询报文中， 与服务器所支持的算法列表一同发往客户端。  
• 在第（3） 步中， 客户端选择一个算法， 计算出密码和其他数据的摘要。 在第（4）步中， 将摘要放在一条 Authorization 报文中发回服务器。 如果客户端要对服务器进行认证， 可以发送客户端随机数。  
• 在第（5） 步中， 服务器接收摘要、 选中的算法以及支撑数据， 计算出与客户端相同的摘要。 然后服务器将本地生成的摘要与网络传送过来的摘要进行比较， 验证其是否匹配。 如果客户端反过来用客户端随机数  
5、摘要的计算  
摘要是根据以下三个组件计算出来的。  
• 由单向散列函数  H(d) 和摘要 KD(s,d) 组成的一对函数， 其中 s  表示密码， d 表示数据。  
• 一个包含了安全信息的数据块， 包括密码， 称为 A1。  
• 一个包含了请求报文中非保密属性的数据块， 称为 A2。  
H 和 KD 处理两块数据 A1  和 A2， 产生摘要。  
算法H(d)和KD(s,d)  
摘要认证支持对各种摘要算法的选择。 RFC 2617 建议的两种算法为 MD5  和 MD5-sess（“sess” 表示会话）， 如果没有指定其他算法， 默认算法为 MD5。不管使用的是  MD5 还是 MD5-sess， 都会用函数 H 来计算数据的 MD5， 用摘要函数 KD 来计算以冒号连接的密码和非保密数据的 MD5。 例如：  
H(<data>) = MD5(<data>)  
KD(<secret>,<data>) = H(concatenate(<secret>:<data>))  
6、与安全性相关的数据（A1）  
被称为 A1 的数据块是密码和受保护信息的产物， 它包含有用户名、 密码、 保护域和随机数等内容。 A1 只涉及安全信息， 与底层报文自身无关。 A1 会与 H、 KD 和A2 一同用于摘要计算。RFC 2617 根据选择的算法定义了两种计算 A1 的方式。  
• MD5  
为每条请求运行单向散列函数。 A1 是由冒号连接起来的用户名、 域以及密码三元组。  
• MD5-sess  
只在第一次 WWW-Authenticate 握手时运行一次散列函数。 对用户名、 域和密码进行一次 CPU 密集型散列， 并将其放在当前随机数和客户端随机数（cnonce） 的前面。

MD5 A1 = <user>:<realm>:<password>  
MD5-sess A1 = MD5(<user>:<realm>:<password>):<nonce>:<cnonce>  
7、与报文有关的数据（A2）

数据块 A2 表示的是与报文自身有关的信息， 比如 URL、 请求方法和报文实体的主体部分。 A2 有助于防止方法、 资源或报文被篡改。 A2 会与 H、 KD 和 A1 一起用于摘要的计算。  
RFC 2617 根据所选择的保护质量（qop）， 为 A2 定义了两种策略。  
• 第一种策略只包含  HTTP 请求方法和 URL。 当 qop="auth" 时使用这种策略，这是默认的情况。  
• 第二种策略添加了报文实体的主体部分， 以提供一定程度的报文完整性检测。qop="auth-int" 时使用。

未定义 <request-method>:<uri-directive-value>  
auth <request-method>:<uri-directive-value>  
auth-int <request-method>:<uri-directive-value>:H(<request-entitybody>)  
8、预授权

![Center 4][]

8、摘要认证首部

![Center 5][]

三、安全HTTP

1、HTTPS

HTTPS 是最流行的 HTTP  安全形式。 它是由网景公司首创的， 所有主要的浏览器和服务器都支持此协议。  
HTTPS 方案的  URL 以 https://， 而不是 http:// 开头， 据此就可以分辨某个 Web 页面是通过  HTTPS 而不是 HTTP 访问的（有些浏览器还会显示一些标志性的安全提示）。

2、HTTPS协议栈

使用 HTTPS 时， 所有的  HTTP 请求和响应数据在发送到网络之前， 都要进行加密HTTPS 在 HTTP 下面提供了一个传输级的密码安全层（参见图 14-2） ——可以使用SSL， 也可以使用其后继者——传输层安全（Transport Layer Security， TLS）。 由于SSL 和 TLS 非常类似，所以在本书中我们不太严格地用术语 SSL 来表示 SSL 和 TLS。  
![Center 6][]

3、数字加密

• 密码  
对文本进行编码， 使偷窥者无法识别的算法。  
• 密钥  
改变密码行为的数字化参数。  
• 对称密钥加密系统  
编 / 解码使用相同密钥的算法。  
• 不对称密钥加密系统  
编 / 解码使用不同密钥的算法。  
• 公开密钥加密系统  
一种能够使数百万计算机便捷地发送机密报文的系统。  
• 数字签名  
用来验证报文未被伪造或篡改的校验和。  
• 数字证书  
由一个可信的组织验证和签发的识别信息。  
4、RSA  
所有公开密钥非对称加密系统所面临的共同挑战是， 要确保即便有人拥有了下面所有的线索， 也无法计算出保密的私有密钥：

• 公开密钥（是公有的， 所有人都可以获得） ；  
• 一小片拦截下来的密文（可通过对网络的嗅探获取） ；  
• 一条报文及与之相关的密文（对任意一段文本运行加密器就可以得到）。  
RSA 算法就是一个满足了所有这些条件的流行的公开密钥加密系统， 它是在 MIT发明的， 后来由  RSA 数据安全公司将其商业化。 即使有了公共密钥、 任意一段明文、 用公共密钥对明文编码之后得到的相关密文、 RSA 算法自身， 甚至  RSA 实现的源代码， 破解代码找到相应的私有密钥的难度仍相当于对一个极大的数进行质因数分解的困难程度， 这种计算被认为是所有计算机科学中最难的问题之一。

5、数字签名

数字签名是附加在报文上的特殊加密校验码。 使用数字签名有以下两个好处。  
• 签名可以证明是作者编写了这条报文。 只有作者才会有最机密的私有密钥， 因此，只有作者才能计算出这些校验和。 校验和就像来自作者的个人“签名” 一样。  
• 签名可以防止报文被篡改。 如果有恶意攻击者在报文传输过程中对其进行了修改，校验和就不再匹配了。 由于校验和只有作者保密的私有密钥才能产生， 所以攻击者无法为篡改了的报文伪造出正确的校验码。  
数字签名通常是用非对称公开密钥技术产生的。 因为只有所有者才知道其私有密钥，所以可以将作者的私有密钥当作一种“指纹” 使用。

6、数字证书

本节将介绍因特网上的“ID 卡” ——数字证书。 数字证书（通常被称作“certs”，有点像 certs 牌薄荷糖） 中包含了由某个受信任组织担保的用户或公司的相关信息。我们每个人都有很多形式的身份证明。 有些 ID， 比如护照和驾照， 都足以在很多场合证明某人的身份。 例如， 你可以用美国的驾照在新年前夜搭乘前往纽约的航班，在你到那儿之后， 接着用它来证明你的年龄， 这样你就能和朋友们一起喝酒了。受信程度更高的身份证明， 比如护照， 是由政府在特殊的纸上签发并盖章的。 很难伪造， 因此可以承载较高的信任度。 有些公司的徽章和智能卡中包含有电子信息，以强化使用者的身份证明。 有些绝密的政府组织甚至会对你的指纹或视网膜毛细血管模式进行匹配以便确认你的 ID ！有些形式的  ID， 比如名片， 相对来说更容易伪造， 因此人们不太信任这些信息。 虽然足以应付职场交流， 但申请住房贷款时， 可能就不足以证明你的就业情况了。

![Center 7][]

7、X.509 v3证书

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

8、建立安全传输

在未加密 HTTP 中， 客户端会打开一条到 Web 服务器端口  80 的 TCP 连接， 发送一条请求报文， 接收一条响应报文， 关闭连接。 图 14-15a 对此序列进行了说明。由于 SSL  安全层的存在， HTTPS 中这个过程会略微复杂一些。 在 HTTPS 中， 客户端首先打开一条到 Web 服务器端口  443（安全 HTTP 的默认端口） 的连接。 一旦建立了 TCP 连接， 客户端和服务器就会初始化 SSL 层， 对加密参数进行沟通， 并交换密钥。 握手完成之后， SSL 初始化就完成了， 客户端就可以将请求报文发送给安全层了。 在将这些报文发送给 TCP 之前， 要先对其进行加密。 图 14-15b 对此过程  
进行了说明。  
![Center 9][]

9、SSL握手

在发送已加密的 HTTP 报文之前， 客户端和服务器要进行一次 SSL 握手， 在这个握手过程中， 它们要完成以下工作：  
• 交换协议版本号；  
• 选择一个两端都了解的密码；  
• 对两端的身份进行认证；  
• 生成临时的会话密钥， 以便加密信道。  
![Center 10][]

10、OpenSSL

OpenSSL 是 SSL 和 TLS 最常见的开源实现。  OpenSSL 项目由一些志愿者合作开发，目标是开发一个强壮的、 具有完备功能的商业级工具集， 以实现 SSL 和 TLS 协议以及一个全功能的通用加密库。

[Center]: /images/20220616/5c2f1ab98f3c4e0f847f123d4ec1d26b.png
[Center 1]: /images/20220616/eff9ddc5ca31470d8e74388b6dc4d2f1.png
[Center 2]: /images/20220616/d656a54845ed4769ae3a6eae23dedda3.png
[Center 3]: /images/20220616/f58508cf522441f9a218ab9d4e33a068.png
[Center 4]: /images/20220616/dc17886f8146463c984a6bc1c1fd5e6b.png
[Center 5]: /images/20220616/4f3d8aaf00a742939d86f84cca6e23e0.png
[Center 6]: /images/20220616/bef06a69d2a540faa7ad186858ec9618.png
[Center 7]: /images/20220616/988284304fb94746bc9f4b922a1e7177.png
[Center 8]: /images/20220616/96c6b12c1273454db9bbd29ef1a6c55b.png
[Center 9]: /images/20220616/f5ad3096d47f4ebdb4e2882642c8d97f.png
[Center 10]: /images/20220616/a6b6f85feb8a4fa1b0315a40a4299c19.png