引言

HTTP（Hypertext Transfer Protocol，超文本传输协议[插图]）是在万维网上进行通信时所使用的协议方案。HTTP有很多应用，但最著名的是用于Web浏览器和Web服务器之间的双工通信。

《HTTP权威指南》一书将HTTP中一些互相关联且常被误解的规则梳理清楚，并编写了一系列基于各种主题的章节介绍HTTP各方面的特性。纵观全书，对HTTP“为什么”这样做进行了详细的解释，而不仅仅停留在它是“怎么做”的。此外，这本书还介绍了很多HTTP应用程序正常工作所必需且重要的非HTTP技术。

这本书主要包括以下内容：

• 第一部分描述了Web的基础构件与HTTP的核心技术
• 第二部分重点介绍了Web系统的结构构造块：HTTP服务器、代理、缓存、网关以及机器人应用程序。
• 第三部分提供了一套用于追踪身份、增强安全性以及控制内容访问的技术和技巧。
• 第四部分涵盖HTTP报文主体和Web标准，前者包含实际内容，后者描述并处理主体内容。
• 第五部分介绍了发布和传播Web内容的技巧。
• 第六部分是一些很有用的参考附录，以及相关技术的教程。

摘要认证

基本认证便捷灵活，但极不安全。用户名和密码都是以明文形式传送的，也没有采取任何措施防止对报文的篡改。安全使用基本认证的唯一方式就是将其与SSL配合使用。

摘要的计算

摘要算法的输入数据

摘要是根据以下三个组件计算出来的。

• 由单向散列函数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>))

与安全性相关的数据（A1）

被称为A1的数据块是密码和受保护信息的产物，它包含有用户名、密码、保护域和随机数等内容。A1只涉及安全信息，与底层报文自身无关。A1会与H、KD和A2一同用于摘要计算。

RFC 2617根据选择的算法定义了两种计算A1的方式。

• MD5：为每条请求运行单向散列函数。A1是由冒号连接起来的用户名、域以及密码三元组。
• MD5-sess：只在第一次WWW-Authenticate握手时运行一次散列函数。对用户名、域和密码进行一次CPU密集型散列，并将其放在当前随机数和客户端随机数（cnonce）的前面。

与报文有关的数据（A2）

数据块A2表示的是与报文自身有关的信息，比如URL、请求方法和报文实体的主体部分。A2有助于防止方法、资源或报文被篡改。A2会与H、KD和A1一起用于摘要的计算。

RFC 2617根据所选择的保护质量（qop），为A2定义了两种策略。

• 第一种策略只包含HTTP请求方法和URL。当qop="auth"时使用这种策略，这是默认的情况。
• 第二种策略添加了报文实体的主体部分，以提供一定程度的报文完整性检测。qop="auth-int"时使用。

request-method是HTTP的请求方法。uri-directive-value是请求行中的请求URI。可能是个"＊"、absoluteURL或者abs_path，但它必须与请求URI一致。尤其需要注意的是，如果请求URI是absoluteURL，它必须是个绝对URL。

摘要算法总述

RFC 2617定义了两种给定了H、KD、A1和A2之后，计算摘要的方式。

• 第一种方式要与老规范RFC 2069兼容，在没有qop选项的时候使用。它是用保密信息和随机报文数据的散列值来计算摘要的。
• 第二种方式是现在推荐使用的方式——这种方式包含了对随机数计算和对称认证的支持。只要qop为auth或auth-int，就要使用这种方式。它向摘要中添加了随机计数、qop和cnonce数据。

摘要认证会话

客户端响应对保护空间的WWW-Authenticate质询时，会启动一个此保护空间的认证会话（与受访问服务器的标准根结合在一起的域就定义了一个“保护空间”）。

在客户端收到另一条来自保护空间的任意一台服务器的WWW-Authenticate质询之前，认证会话会一直持续。客户端应该记住用户名、密码、随机数、随机数计数以及一些与认证会话有关的隐晦值，以便将来在此保护空间中构建请求的Authorization首部时使用。

随机数过期时，即便老的Authorization首部所包含的随机数不再新鲜了，服务器也可以选择接受其中的信息。服务器也可以返回一个带有新随机数的401响应，让客户端重试这条请求；指定这个响应为stale=true，表示服务器在告知客户端用新的随机数来重试，而不再重新提示输入新的用户名和密码了。

预授权

在普通的认证方式中，事务结束之前，每条请求都要有一次请求/质询的循环。

如果客户端事先知道下一个随机数是什么，就可以取消这个请求/质询循环，这样客户端就可以在服务器发出请求之前，生成正确的Authorization首部了。如果客户端能在服务器要求它计算Authorization首部之前将其计算出来，就可以预先将Authorization首部发送给服务器，而不用进行请求/质询了。图13-4b显示了这种方式对性能的影响。

预授权对基本认证来说并不重要（而且很常见）。浏览器通常会维护一些客户端数据库以存储用户名和密码。一旦用户与某站点进行了认证，浏览器通常会为后继对那个URL的请求发送正确的Authorization首部。

由于摘要认证使用了随机数技术来破坏重放攻击，所以对摘要认证来说，预授权要稍微复杂一些。服务器会产生任意的随机数，所以在客户端收到质询之前，不一定总能判定应该发送什么样的Authorization首部。

摘要认证在保留了很多安全特性的同时，还提供了几种预授权方式。这里列出了三种可选的方式，通过这些方式，客户端无需等待新的WWW-Authenticate质询，就可以获得正确的随机数：

• 服务器预先在Authentication-Info成功首部中发送下一个随机数；
• 服务器允许在一小段时间内使用同一个随机数；
• 客户端和服务器使用同步的、可预测的随机数生成算法。

随机数的选择

随机数的内容不透明，而且与实现有关。但性能、安全性和便捷性的优劣都取决于明智的选择。

RFC 2617建议采用这个假想的随机数公式：

BASE64(time-stamp H(time-stamp ":" ETag ":" private-key))

其中time-stamp是服务器产生的时间或其他不会重复的值，ETag是与所请求实体有关的HTTP ETag首部的值，private-key是只有服务器知道的数据。

有了这种形式的随机数，服务器就可以在收到客户端的认证首部之后重新计算散列部分，如果结果与那个首部的随机数不符，或者时间戳的值不够新，就拒绝请求。服务器可以通过这种方式来限制随机数的有效持续时间。

对称认证

RFC 2617扩展了摘要认证机制，允许客户端对服务器进行认证。这是通过提供客户端随机值来实现的，服务器会根据它对共享保密信息的正确了解生成正确的响应摘要。然后，服务器在Authorization-Info首部中将此摘要返回给客户端。

这种对称认证方式被标准化为RFC 2617。为了与原有RFC 2069标准后向兼容，它是可选的，但由于它提供了一些重要的安全提升机制，强烈推荐现今所有的客户端和服务器都要实现全部RFC 2617特性。特别是，只要提供了qop指令，就要求执行对称认证，而没有qop指令时则不要求执行对称认证。

总结

摘要认证的核心就是对公共信息、保密信息和有时限的随机值这个组合的单向摘要。现在我们来看看这些摘要是如何计算出来的。摘要计算通常都是简单易懂的。

作者介绍
非职业「传道授业解惑」的开发者叶一一。
《趣学前端》、《CSS畅想》等系列作者。华夏美食、国漫、古风重度爱好者，刑侦、无限流小说初级玩家。
如果看完文章有所收获，欢迎点赞👍 | 收藏⭐️ | 留言📝。