网络协议安全设计的现场指南

最新推荐文章于 2024-07-04 09:57:27 发布

amh

最新推荐文章于 2024-07-04 09:57:27 发布

阅读量4.7k

点赞数

分类专栏：精典文章文章标签：网络协议服务器 microsoft 加密 ssl cryptography

精典文章专栏收录该内容

154 篇文章 0 订阅

订阅专栏

本文将介绍以下内容：

•	安全通信的设计
•	中间人攻击
•	安全传输中的不当信任关系
•	版本控制和升级

此文章使用下列技术：

•	Windows 网络

本页内容

	构建前设计
	建立安全保证
	始终质疑假设
	中间人攻击
	不当信任关系
	准备版本控制
	结论

当您面对创建一个新的通信协议时，您将如何确保其安全可靠呢？全方位的解答会占满整个篇幅，所以，这里我们只着重说明最常见的情况和注意事项。

此处考虑的许多主题并不只针对于网络。它们适用于任何具有安全功能的软件，无论是加密文件还是进行访问控制决策。软件安全原则比技术更重要，而且往往通用性很强。

到底什么是协议？维基百科将它定义为“控制或实现两个计算端点间的连接、通信和数据传输的约定或标准。”协议的定义应包括对通信任意一端的状态计算机的描述、消息格式的具体规范、加密算法、字节顺序 (endianness)、端口号以及众多与语法、语义和同步相关的详细信息。并且，协议定义的每个部分都要经受恶意方的攻击。我们将研究一些攻击协议和规则的示例，这有助于设计和实现您自己的协议。

构建前设计

这显而易见，但在实际操作中却常常被违反。即使最严密的实现也掩盖不了设计缺陷。而且，虽然可快速解决实现问题，但是设计缺陷可能需要几乎从头再实现。即使对于独立应用程序，重新设计的代价也相当大。如果已分布应用程序，而且该应用程序具有必须采用相同设计的客户机和服务器部件，那么，这种代价绝对惊人。

如大多数软件一样，构建协议是为了在大范围内部署，但是，协议却受另一个重要的挑战所影响。协议的所有使用方同步进行升级几乎是不可能的。通常必须对协议进行“版本控制”，而且新的实现必须能够支持旧版本。这使得排除设计级别缺陷缓慢而冗长，从而使客户暴露时间比实现缺陷所导致的暴露时间长很多。若协议需与其他方编写的软件能够互操作，而又不能控制其软件的版本，那么情况将特别糟糕。NTLM 1.0 就是证明淘汰旧协议很困难的一个典型反面示例。虽然十多年前已经引入，并早知其有缺陷，然而它却仍然顽固地保持不变。尽管 Microsoft 一番好意，但事实证明，在历经数年并发布了几个 OS 版本后，才最终将 NTLM 1.0 淘汰。Windows Vista™ 将是由 Microsoft 推出的第一个在默认情况下设置为禁用的 OS。本文的稍后部分将详细介绍对协议进行版本控制时应采取的步骤。

返回页首

建立安全保证

安全软件其实就是安全保证工作。最终产品将提供什么安全保护承诺？这个问题可能显得微不足道或过于泛泛，但是全面且正确地回答此问题，会直接有助于使设计更加可靠，最终产品的测试目标也将更明确。有一点同样重要，如果公司正在开发商业产品，过分夸大产品功能必定会在安全性方面名声狼籍。了解安全保证可帮助您避免做出根本不可能实现的决定。

今天，软件供应商在说明其安全保证方面做得相当糟糕。试想您正面临着评估数据备份软件的安全性。要求之一就是保证备份不被他人盗用。承诺有“密码保护数据”的应用程序是否起作用？它是如何对密码进行保护的？它是否对数据进行加密？如果是，加密算法的强度如何？在对客户说明安全保证之前，您必须十分清楚您提供什么样的承诺。正如之前所述，一个到位的安全保护应是“如果您选择了强密码，使用密码保护数据会确保在不知道密码的情况下，在任何合理的时间跨度内都不能够恢复数据”。遗憾的是，现在将很难看到像这样的陈述了。

甚至经过精心设计协议的安全保证也可能而且应该受到质疑。以 Kerberos 为例。Kerberos 的安全性部分基于客户和 Kerberos 密钥分配中心 (KDC) 协商的密码套件的强度。如果您不是 Kerberos 专家，您可能不了解整个运作过程。您可能（正确地）猜到客户和 KDC 可能支持不同的、重叠的加密协议套件。鉴于此，您期望由此协商所得到的安全保证应描述如下：“双方将协商可能得到的最强大的密码套件。”因此，如果客户和 KDC 都支持 40 位 RC4 和 168 位 3DES，那么将选择更强的 3DES 密码。

我们来看一下实际的情况。首先，客户将所了解的密码套件列表传送到 KDC。KDC 浏览此列表，选出其认为最强的密码套件并进行使用。

表面上已经达到目的了。但根据更进一步的检查，就会发现问题：设计者忘记考虑活动中间人攻击者可能更改由客户传送到 KDC 的数据。因此，没有做任何抵御篡改的防护，就将密码套件列表传送到 KDC。这可使攻击者可从列表中删除最弱密码套件之外的所有密码套件。最弱算法可能是 40 位的 RC4 - 该密码可在 24 - 48 小时之内，使用当前的台式机硬件配置强力破解。

因此，Kerberos 中密码套件协商的正确安全保证与之前猜想的不同。它应该是：“双方将协商不弱于由客户提供给 KDC 的最弱选择的密码套件。”这种方式描述的安全保证会让我们对客户机采取预防措施。无需更改协议，我们可以作为一项策略，使其只请求足够强的密码。

以下是可作为最佳设计协议特点的安全保证：

•	通信的参与者应无法负面影响（或攻击）其他参与者 - 服务器、客户机、中间节点等等。
•	中间人攻击者应无法偷听会话或以具有安全意义的方式更改会话内容。
•	经身份验证的参与者的访问必须仅限于此参与者的授权范围内。
•	这些是非常高级别的保护，实际情况中会将它们进一步细化，通常会覆盖通信的每个细小的方面。

正如您所见，建立安全保证是一个复杂而又漫长的过程。但是，也可做一些简化处理。例如，为进行安全性分析，不应区分主动恶意、受侵害、错误配置或故障节点。事实上，所有类型的异常行为都可能由攻击者引起，因此不应区分。经常会见到多个关联的安全保证，可大量减少它们。

返回页首

始终质疑假设

软件任何部分的设计级别安全性分析都从质疑其设计者所做的假设开始。黑客尤其擅长于此。如果您想使自己的设计经得住推敲，就必须亲自做这种分析。若在设计阶段质疑假设，就可享有暴露和重新设计不安全部分的自由，而不需要担心向后兼容性或败坏您的名声。实现开始时，您就失去了这个有利时机。一旦产品出厂，就已经失去有效性。

以下是软件设计者经常做出的一些假设，由此带来的风险由设计者自负。第一，在没有了解其他技术或协议所做的安全保护的情况下，就将新安全技术构建在它们之上。您可能不会从头开始设计协议。相反地，您很有可能从各种构造块中组合出一个解决方案。通信传输、加密原型、验证算法等等。定义安全保护的前提是要了解设计所依赖的技术的安全保护。若不全方面了解此领域，容易给您的保护带来破坏或限制。地基不稳就建不了高楼。

应用程序用以做出信任决策的所有信息资源都需要认真研究和全面理解。DNS 协议就是其中一例，它用于网络名称解析。DNS 不具有安全功能并对名称解析期间返回的 IP 地址不作任何安全声明。IP 地址可能是目标主机的地址，也可能是等待进行破坏的攻击者的地址。利用 DNS 设计时必须要考虑到这方面缺乏保证。这种设计的一种途径是使用已解析的地址建立 TLS/SSL 会话。这样，就强制已解析地址的计算机提供由传送者信赖的根域中的某人签署的证明。这通常可以确保服务器的身份已由受信任的证书机构验证。

作为更高级的示例，要考虑使用身份验证协议时所依赖的安全保证。每个身份验证协议都包括客户机和服务器间的消息交换。除了向服务器提供客户机身份这一明显属性外，一个全面的身份验证协议至少还包括三个属性。第一，不会对客户机所验证的服务器或会话期间的偷听者泄漏客户机的凭据。第二，交换的消息不会被重放（因此，攻击者不能使用录制的交换在随后的交换中欺骗客户机）。第三，协议允许客户机和服务器建立一个秘密会话密钥，它可用于签署和加密之后的通信（以及稍后通过该密钥的更多通信）。这个会话密钥一定不能由攻击者通过完全访问客户机和服务器之间发送的每个消息就可派生出。

通常使用的 Windows® 身份验证协议 - Digest、NTLM 和 Kerberos - 满足这三个属性（参见图 1）。这就足够了吗？答案并不那么简单。

对于稍微复杂的示例，应考虑 NTLM 身份验证协议。NTLM 的设计旨在向服务器验证客户机身份的真实性。它不提供返回到客户机的任何服务器真实性的验证。就安全性来说，NTLM 由于缺乏相互身份验证而不是很完美；图 1 最后一行显示了该情况。如果客户机的设计未考虑缺乏安全保证这一项，那么，缺失保证可能导致灾难性的结果。

由缺乏相互身份验证而造成的弱点举不胜举。如果客户机运行由服务器发送的可执行文件会怎么样呢？如果服务器的身份验证成功，客户机将机密信息（如信用卡号或各种形式的个人识别信息 (PII)）发送到服务器，会有什么结果呢？一般来说，可利用安全传输（如 SSL）来解决此类问题，这是一个可保护传送到客户机的服务器真实性和防止偷听或篡改所有通信的传输机制。

在将设计所使用的每个协议、技术和功能的安全保证考虑在内后，才能构成您设计的整套安全保证，清楚这一点很重要。

返回页首

中间人攻击

认为通信流不会受中间人攻击的这种假设是非常危险的，因为攻击者有多种途径进入到您的通信通道中。后果可能非常严重。您已经了解中间人攻击如何能使 Kerberos 协商危险的弱密码套件。由于早期的互联网工程任务组（Internet Engineering Task Force，IETF）协议的设计不安全，地址解析协议（Address Resolution Protocol，ARP）布毒或 DNS 欺骗很完善，易于执行并且在多种环境中都非常有效。另外，网络可能包括恶意 DHCP 服务器，它可将所有可用客户机的默认网关设置到恶意路由器。即使在本地子网中没有攻击者，也很难确定所有处理两计算机间通信的路由器可抵御攻击，并以最有利于用户的方式运作。当这些路由器中的一些由不同公司或政府拥有并操作时，情况尤其如此。结果，大多数网络无法抵御简单的物理改变 - 机器背面的以太网电缆可能将您连接到目标位置以外的其他位置，而您还以为就是要找的位置。以上远未列出所有情况。

对于未对验证后的通信签署或加密的协议，此假设通常很明显。在这些条件下，攻击者可等到身份验证完成之后监视或更改之后的数据。多数情况下，这可使攻击者伪装为已通过身份验证的用户。

许多协议在身份验证之后不安全地发送出所有通信：电子邮件协议（如 IMAP 和 POP3 ）就是最典型的示例。通常的解决方案是通过安全传输（IPsec 或 SSL/TLS）发送所有通信。这样，中间人不能监视通信，并且接收人可检测到任何想改变通信的企图。

在阻止攻击方面，还能做些什么呢？一个强大的身份验证协议（如 Kerberos，至少是 NTLM）可使双方协商一个共享会话密钥作为验证的一部分。此共享密钥可用于两种用途：完整性 - 签署消息从而防止篡改；隐私 - 加密通信从而防止偷听。如前所述，设计得当的身份验证协议可通过其自己的安全保证实现以下目标：即中间人将无法获得共享会话密钥。此密钥的秘密就在于保护整个通信 - 使用它吧！

实现完整性和隐私性并不一定很困难。如果使用安全服务提供程序接口 (SSPI) 进行验证，仅几步便可引入完整性和隐私。

第 1 步是配置请求完整性和隐私的客户机和服务器。在客户端，通改在调用 InitializeSecurityContext 时添加两个标记即可完成该步。ISC_REQ_INTEGRITY 和 ISC_REQ_CONFIDENTIALITY 应添加给 fContextReq 参数。在服务器端需要添加两个标记。参数依然是 fContextReq，但在本例中，函数为 AcceptSecurityContext。此处的两个标记是 ASC_REQ_INTEGRITY 和 ASC_REQ_CONFIDENTIALITY。在客户机和服务器都使用这些标记很重要。SSPI 是一种与传输不相关的验证机制，因此它在验证和执行该验证的协议之间不进行关联。

现在考虑两种既使用 SSPI 又协商隐私的独特协议。对于协议 A，客户机要求隐私，而服务器则不要求。对于协议 B 则相反；服务器要求隐私，而客户机却不要求。表面上看，一切都挺好；所有连接应至少有一端要求隐私。不幸的是，攻击者实际上却可通过跨协议攻击利用此状况。

攻击者会建立两个连接：一个与协议 B 客户机相连，另一个与协议 A 服务器相连。建立连接后，每个连接均将通过中间人尝试 SSPI 验证。攻击者对两个验证都不必担忧，因为 SSPI 未绑定到特定协议。攻击者可从一个协议提取 SSPI 数据，然后将其插入另一个协议中。这样做几次后，攻击者将使这两个连接的验证取得成功。此攻击如图 2 所示。

图 2 跨协议攻击

糟糕的是，此种验证中的客户机或服务器均不要求隐私。这意味着攻击者现在可随意攻击两个未加密的连接。通过使客户机和服务器都要求隐私，两个协议均可防止此类情况。虽然两种协议都难免出错，但也很难保证所有其他协议的安全性。最好确保自己的安全性。

实现完整性和隐私的第 2 步，是验证已成功协商了完整性/隐私。无法保证在上步中所请求的属性在验证期间已成功处理。要查看协商是否成功，必须检查 InitializeSecurityContext 和 AcceptSecurityContext 所返回的 pfContextAttr 参数。检查内容包括，确保在 fContextReq 参数中所设置的标记在 pfContextAttr 参数中仍保持设置。如果丢失了某些内容，则相应的标记将不会得到成功协商。除非每一方均收到了所请求的“保护质量”，否则不会进行通信。

第 3 步是签署并加密您的数据。即使成功协商了完整性和隐私，数据也不会自动受保护。为此，必须将需要保护的数据通过两种函数中的其中一种显式传递。用于签署的函数是 MakeSignature。用于加密的是 EncryptMessage。无论使用哪种函数，对 fQOP 参数要尤为注意，它用于指定所需的保护质量。可接受的值会基于底层验证协议的不同而不同。某些情况下，可选择根本就不提供任何保护的值。Kerberos 验证期间通过 EncryptMessage 函数提供的 SECQOP_WRAP_NO_ENCRYPT 标记便是这样的一个示例。在使用它时，此标记不会加密通过 EncryptMessage 传递的数据。

使用经协商的会话密钥来保护消息安全可缓解所关注的对 NTLM 验证协议的攻击。由于缺乏相互验证，通过 NTLM 进行验证是不安全的，当试图对恶意服务器进行验证时，该服务器会像代理服务器一样，转发验证消息并对另一服务器做出响应 - 这种现象称为转发攻击。如果未使用会话密钥保护验证后的消息，恶意服务器会充当目标服务器的客户机。

在人们愿意使用同事发给他们的 Intranet 文件链接的企业环境中，此攻击（如图 3 所示）最可能得逞。此攻击开始时，攻击者（恶意服务器）先发送引诱消息给客户机，例如邀请客户机下载恶意服务器中共享的某个感兴趣的文件。为了获得文件，客户机必须对声称仅支持 NTLM 的恶意服务器进行验证。恶意服务器就会代理由客户机发送给目标服务器（恶意服务器要充当其客户机的服务器）的所有消息。所有目标服务器的验证消息均发回客户机。验证完成后，目标服务器相信与客户机具有合法会话，但实际上却在与恶意服务器进行对话。同时，客户机完全不知道它已向目标服务器验证了自身！

图 3 验证重定向

转发攻击对 Kerberos 将不起作用，因为 Kerberos 验证消息仅可由它们所适用的服务器所理解。即使在使用 NTLM 时，成功的验证也意味着客户机和目标服务器拥有恶意服务器无法获得的秘密会话密钥。这样，如果目标服务器一定要使用此共享会话密钥将发送给它的消息进行签署和加密，则恶意服务器将无法向目标服务器伪装有效信息，并且也将无法理解或更改客户机发送给目标服务器的任何消息，或目标服务器响应的任何消息。不过，别忘了，即使在使用 Kerberos 时，也必须签署和加密通信，除非在使用安全传输（例如 SSL），因为这样做将保护不受您和服务器之间的任何中间人的影响

返回页首

不当信任关系

人们很容易认为利用安全传输将立即使中间人攻击无效。不一定。让我们来看看由安全传输所提供的安全保证。

对于常见问题，可考虑 SSL 及其提供的安全保证。如通常部署的那样，它将确保连接加密，并且客户机与所请求的同一服务器会话。有什么可确保客户机请求正确的服务器？前面已经谈到几种情况，都是请求基于先前的明文通信。在这种情况下，中间人攻击者可获得合法的 SSL 证书，然后只需篡改纯文本协议即可重定向 SSL 连接。通过到客户机的合法 SSL 连接，攻击者可随意利用客户机对 SSL 连接的任何信任。

当 SSL 连接保护不安全的验证协议时，另一常见问题出现了。不安全验证协议时常会不限制到 SSL 连接所在的同一台机器。假设合法 SSL 连接端的服务器实际上是恶意的。这种情况下，恶意服务器可选择通过其他 SSL 连接将不安全的验证协议重定向到其他服务器（如图 4 所示）。如果客户机无法将验证限制到与之具有 SSL 连接的服务器，则它可能实际上正对任意服务器进行验证。根据不安全验证协议的不同，这可能会使恶意服务器伪装为客户机。

图 4 验证重定向

IPsec 也不会免予受此类问题的影响。采用每次使用某一协议时要求使用 IPsec 隧道的安全策略。如果正确实现，这将有助于确保所有参与者具有有效的 IPsec 凭据。不过，在参与者的 IPsec 凭据和要在隧道上使用的协议之间通常将不会有任何链接。这样，具有有效凭据的任何人均可随意攻击此协议。虽然许多尝试攻击者不具有有效凭据，但此策略真正提供预期的防护级别了吗？供应商、顾问和不满的员工可能均具有有效的凭据。他们是否可以信任？他们机器的安全性如何？

无论是否使用安全传输，了解底层协议的弱点以及该传输将如何抵御攻击者利用这些弱点都非常重要。以极差的纯文本验证协议为例。使用安全传输无疑将有助于保护密码不暴露，但它可能无法始终提供足够的保护。假设客户机凭据在多个服务器上均有效。如果客户机使用该纯文本协议登录某一服务器，该服务器将能够在其他任何服务器上重用此客户机凭据。如果其中一个服务器是恶意服务器或已经受侵害时，这可能会十分糟糕。在此类情况下，没有安全传输可提供完全保护。发生这种情况时，要获得足够的保护，就必须创建新版的弱协议或用其他协议替换该协议。在此，可使用 SSPI 验证替换纯文本验证。

安全漏洞所致的多数经济损失并非由 Internet 范围的灾难（例如，Blaster 蠕虫）所引起，而是因为内部攻击。对被验证方的不当信任就是造成最大一部分此类攻击得逞的原因。

会话的已验证方通常比匿名方更值得信任。不过，此附加信任必须严格限制在系统访问控制策略所允许的操作和数据范围内。我们经常看见的是，在会话中，验证方更多时候会被认为是比匿名方更值得信任的好成员：输入检查被放松、访问控制被放松等等。

我们所指的“已验证方”，不仅仅指客户机，也指服务器。正确设计的系统将不仅保护服务器不受恶意客户机的影响，而且也将保护客户机不受恶意服务器的影响。这一点经常被忽视。请考虑图 5 所示的客户机和服务器之间的交换。客户机请求某些数据，并分配服务器所指定的内存量。服务器将额外发送一千字节数据。客户机复制全部 101KB 数据，但不检查所发送数据的实际大小，结果将溢出缓冲并允许服务器在客户机上运行任意代码。

图 5 恶意客户机-服务器交换

服务器竟然尝试攻击客户机，这可能显得很奇怪，但它确实会发生。托管服务器的机器可能已受攻击者的侵害。在其他情况下，服务器管理员可能已变得怀有恶意。还有一种可能，就是此攻击由中间人而非服务器进行。无论原因如何，客户机都要负责留意其自身的安全。客户机必须验证服务器所提供的输入，并且不假设后续响应之间连贯一致。

此类安全考虑事项远远超出了仅担心实现缺陷的范畴。假设合法服务器数据被窃，或管理员变得不满起来。这会给服务器的客户机造成什么风险？尽管理想答案是没有风险，但实际情况可不总是这样。例如，假设协议传送 PII。如果服务器角色是处理此 PII，则受侵害的服务器或恶意服务器几乎始终会对客户机造成风险。实际上，应将客户机的暴露限制为服务器所需的最小功能。此最小功能并不总是明显的。

考虑一个具有自更新功能的协议。作为更新过程的一部分，服务器可能需要向客户机发送更新的可执行程序。乍一看，好像此功能的最小功能会使受侵害的服务器通过给服务器的所有客户机发送恶意更新可执行程序使它们受到侵害。但是不一定会这样。该功能所需的最小功能实际上仅涉及分发受信任的可执行程序，而非任意可执行程序。假设对客户机进行如下设计：它们仅运行由特定私有密钥签署的可执行程序，且此私有密钥从不存储在服务器上。服务器马上就不会将客户机立即置于危险中。现在，用于签署可执行程序的私有密钥一定也会受到攻击者或恶意管理员的侵害。

我们时常会发现客户机比最小服务器功能多暴露很多。对于服务器应注意的最后一点便是，牢记连接许多客户机的服务器是传播蠕虫的主要目标。

返回页首

准备版本控制

安全科学并非停滞不前。今天的强大加密或验证协议可能明天就会用来对付黑客冲击。您可能发现自己创建的协议含有设计级缺陷或实现错误，其修复将会打破旧版本和新版本之间的兼容性。出于所有这些原因，必须准备对您的协议进行版本控制。可按以下方式设计协议：在消息交换过程的初期确定连接方的版本。准备在较新的设计中支持多个验证方案、附加密码和较早的客户机或服务器。以下是对这些版本控制形式中每一个的建议。

添加验证方案 SSPI 减轻了终端协议处理验证机制详细信息的需要。它还为验证协议创建中央位置。如果这些协议的其中一个出现设计缺陷，此中央位置将使更新所有受影响的协议容易很多。通常，Microsoft 建议使用 Negotiate 软件包进行验证。此软件包将全力协商使用更强的 Kerberos 协议，但如果无法实现，则将会退回使用 NTLM。通常，如果不使用 Negotiate 软件包，将无法更为成功地完成此项任务。此外，Negotiate 软件包将来会进行更新，以使用更强的验证协议（如果有）。

规划加密灵活性如果您的协议依赖于特定密码的长度，比方说 3DES，您可能要自己做好准备，以防此密码将来被证实较弱。前面您看见了处理密码套件协议的示例。如果在您的设计中包括类似的条件，您将有机会将已安装的库升级到更强大的加密算法，而不会打破兼容性。为 Windows Vista 规划的 Cryptography Next Generation (CNG) API 将使您可将自己的加密协议与 Windows 无缝集成。

逐步淘汰过时的协议协议版本控制往往遵循进阶过程。当引入新版本的协议时，一段时间往往会同时支持两个版本。当参与者最倾向于轻视攻击时 - 任何客户机或服务器均可要求处于较低版本，以期在设计中或另一方或协议本身的实现过程中利用某一安全漏洞。版本控制策略中必须包含部署已达到某一关键阶段后，停止对降级客户机或服务器支持的条件。

返回页首