Windows2000 服务器端应用程序开发设计指南－安全连接(3)

重新协商的处理
　

假如客户端对一个被保护的资源提出请求，此时您的服务器可能会想要把匿名的客户端验证提升为具有凭证的验证。如此一来，您的服务器就必须初始一个重新协商的程序。

通常SSL的通讯中，客户端及服务器会经由传送及接收加密的资料缓冲器而互相通讯。然而，当服务器想要初始一个重新协商的程序而非加密及传送资讯时，服务器便会呼叫AcceptSecurityContext函数。在这种情况下，服务器没有传递输入缓冲器到函数中，而且函数会传回应该传送到客户端的Blob值。客户端会了解此Blob表示它应该开始一个重新协商的程序。以下的范例函数显示服务器实作这个程序代码的方法：

BOOL SSLServerInitReneg( 

 CredHandle* phCredentials, 

 CtxtHandle* phContext) 

{ 

 BOOL fSuccess = FALSE; 

 __try 

 { 

  // 宣告输出缓冲器 

  SecBuffer secBufferOut; 

  SecBufferDesc secBufDescriptorOut; 

  // 设定输出缓冲器（经由SSPI分配） 

  secBufferOut.BufferType = SECBUFFER_TOKEN; 

  secBufferOut.cbBuffer = 0; 

  secBufferOut.pvBuffer = NULL; 

  // 设定输出缓冲器描述项 

  secBufDescriptorOut.cBuffers = 1; 

  secBufDescriptorOut.pBuffers = &secBufferOut; 

  secBufDescriptorOut.ulVersion = SECBUFFER_VERSION; 

  ULONG lAttrOut = 0; 

  SECURITY_STATUS ss = 

   AcceptSecurityContext( 

    phCredentials, 

    phContext, 

    NULL, 

    ASC_REQ_ALLOCATE_MEMORY|ASC_REQ_STREAM|ASC_REQ_MUTUAL_AUTH, 

    SECURITY_NATIVE_DREP, 

    phContext, 

    &secBufDescriptorOut, 

    &lAttrOut, 

    NULL); 

  if (ss != SEC_E_OK) 

   __leave; 

  // 有资料要传送吗？ 

  if (secBufferOut.cbBuffer!=0){ 

   // 传送它 

   ULONG lOut = secBufferOut.cbBuffer; 

   SendData(secBufferOut.pvBuffer, lOut); 

   // 然后释放输出缓冲器 

   FreeContextBuffer(secBufferOut.pvBuffer ); 

  } 

  fSuccess = TRUE; 

 }__finally{} 

 return (fSuccess); 

}

如同我们在DecryptMessage函数讨论中提到的，当DecryptMessage传回SEC_I_RENEGOTIATE值时，客户端首先会知道服务器要求重新协商的程序。这个时候，假如客户端同意重新协商，则它应该带着适当的凭证handle进入验证回圈的程序中。

服务器也应该在要求重新协商后进入自己的重新协商验证程序。服务器的责任即是检验客户端是否已经提供适当的凭证。客户端很有可能只重新传送它的匿名凭证。

以下列出的程序代码片段表示服务器在重新协商程序中所扮演的角色。

// 服务器需要与客户端重新协商 

if(!SSLServerInitReneg( 

 &hCredentials, 

 &hContext)){ 

 // 错误情况 

} 

// 设定验证交握的标记 

dwSSPIFlags = ASC_REQ_SEQUENCE_DETECT   | 

              ASC_REQ_REPLAY_DETECT     | 

              ASC_REQ_CONFIDENTIALITY   | 

              /* 指出要求客户端凭证 */ 

              ASC_REQ_MUTUAL_AUTH       | 

              ASC_RET_EXTENDED_ERROR; 

cbExtra = 0; 

// 再进入验证回圈 

ss = SSLServerHandshakeAuth(&hCredentials, 

 &dwSSPIFlags, &hContext, pIOBuff, &cbExtra, lIOBuffSize); 

if (ss == SEC_E_OK){ 

 // 重新协商成功 

}

同样的，以下列出的程序代码片段显示在重新协商程序中客户端所扮演的角色（假设客户端拥有一个重新协商的凭证）：

// 照惯例取得解密讯息 

cbMsg = 0; 

cbExtra = 0; 

pMsg = 

 GetEncryptedMessage( 

  &hContext, 

  &cbMsg, 

  &pIOBuff, 

  &cbExtra, 

  lIOBuffSize, 

  &fReneg); 

// 假如它执行失败，这是重新协商的请求吗？ 

if ((pMsg == NULL) && fReneg){ 

 // 如果是，那么带着与凭证相关的凭证handle重新进入验证回圈 

 ULONG   lSSPIFlags = ISC_REQ_SEQUENCE_DETECT | 

                      ISC_REQ_REPLAY_DETECT     | 

                      ISC_REQ_CONFIDENTIALITY   | 

                      ISC_RET_EXTENDED_ERROR; 

 ss = 

  SSLClientHandshakeAuth( 

   &hCertCredentials, 

   &hCertCredentials, 

   &lSSPIFlags, 

   &hContext, 

   TEXT("Jason’s Test Server Certificate on Davemm"), 

   pIOBuff, &cbExtra, lIOBuffSize); 

 if (ss == SEC_E_OK){ 

  // 重新协商成功 

 } 

}

说明

如果您的客户端软件必须与要求重新协商的服务器通讯时，无论它什么时候会呼叫DecryptMessage函数，能够让您的客户端优雅地处理重新协商要求是很重要的。

SSL及模拟（Impersonation）
　

假如服务器已经透过客户端之凭证而验证客户端（相对于匿名的客户端验证）时，服务器有可能在那个时候模拟客户端。事实上，模拟的细节与其他使用SSPI安全性通讯协定的模拟方式不同。您只需传递完整的环境handle到ImpersonateSecurityContext函数中，或是直接使用QuerySecurityContextToken函数撷取权杖即可（这两种技巧在本章稍早时曾讨论过）。

然而，剩下一个重要的问题：Windows 2000为何只使用凭证即可为使用者建立一个权杖？这个问题的答案是透过凭证对应到Active Directory，或是经由存放在凭证本身的特定Microsoft资讯。有叁种方法，可以把凭证对应到Windows 2000网域的使用者信任帐户权杖。

在讨论可以用来把凭证对应到网域里的使用者方法前，我想要花些时间说明这个对应的重要性。

假如在Windows 2000上执行的服务器连接到具有已知凭证的客户端时，不管客户端使用的操作系统为何，您的服务器可能会建立一个权杖并把这个客户端登录您的服务器机器上。这个方法可以让您模拟连结到客户端的情形，可以在UNIX、Windows，或任何其他具有SSL通讯能力的机器上执行客户端软件。

这里有叁种不同的方法，可让您将凭证对应到Windows 2000使用者帐户中：

尽管SSL连结的模拟方式是简单的，这些凭证对应到的管理工作是您的责任。最简单的方法及要求最少的管理即是UPN对应的方式。使用UPN对应，您只需执行Microsoft凭证服务的CA，以作为企业的CA即可。然后您可以从这个CA中要求一个「使用者」凭证。这个使用者凭证将包括UPN属性，它包含要求凭证的使用者帐户名称。假如这个凭证被使用在客户端到SSL服务器的连结中，它就可以被模拟。

当然，您可能会发现您想要模拟不具有特定Microsoft之延伸部分所产生的凭证，这样做会需要您在Active Directory中作明确的对应。一对一对应及多对一对应都使用类似的技巧，把凭证对应到Active Directory中的使用者。

刚开始时，您必须将凭证汇出到一个 .CER文件中。这个文件类型是标准凭证汇出的格式，它包括凭证的签章副本及公开金钥部份，而不包括与凭证相配的私密金钥。MMC中的凭证嵌入式管理单元可让您在凭证上按下滑鼠右键，然后选择所有工作和汇出选项，以汇出一个凭证。这会启动凭证汇出精灵。一旦您有了 .CER文件，就应该采用这些步骤去建立对应到Active Directory中的使用者帐户：

在这些步骤被适当地执行后，您的服务器软件可以开始模拟客户端。

说明

使用凭证对应时，有两个常见的情形必须注意。首先，假如服务器并不信任凭证的发行者，与该凭证关联的客户端即不能被模拟。第二，如果凭证是执行Microsoft凭证服务之企业所建立的使用者凭证，在Active Directory中搜寻明确的对应前，会先使用UPN对应方式。假如您已明确地对应这种凭证时，会导致无法预料的结果。

SSL之疑难排解
　

在Windows 2000上实作SSL的Schannel安全性套件支援了错误及追踪报告的机制，并会把事件加入事件日志中。它会预设将错误情形记录到系统日志中。然而，它也可以被设定为将警告等级和追踪等级的事件记录到日志中。

为了赋予这些特色，您必须修改登录中的某个值。这个机码位于HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\Schannel中，而这个值的名称为EventLogging。

EventLogging值是叁个位元值的组合，位元值1表示错误，位元值2表示警告报告，而位元值4则表示追踪事件报告。您可以组合这些值以达到想要的任何报告组合。例如，EventLogging值为3会指示错误及警告报告，反之，EventLogging值为7会打开所有报告等级。这个特色对于了解安全性提供者在执行代表使用SSL客户端及服务器软件的工作时很有帮助。

使用SSPI实作SSL时，必定会牵涉一些比较难的程序代码，但是了解必须做什么再加上一个好的范例会很有帮助。在此强烈地建议您在试图实作自己的SSL服务器前，花些时间更深入地了解本书的范例和《Platform SDK》文件中的范例。

SSLChat范例应用程序
　

SSLChat范例应用程序（「12 SSLChat.exe」）说明如何使用目前为止我们已讨论过的所有SSL相关技术，包括客户端及服务器凭证的验证、讯息签章及加密的部份。范例应用程序的原始码及资源档存放在随书光碟上的12-SSLChat目录中。图12-7为SSLChat范例应用程序执行时的使用者介面。

SSLChat范例应用程序与SSPIChat范例应用程序非常类似。然而，在SSLChat范例应用程序中，客户端及服务器都可以选择一个凭证去验证远端原则。

客户端及服务器机器必须能够识别彼此之凭证的根CA，这是很重要的。完整讨论从使用者观点出发的凭证管理部份超出了本书的范围，您可以在Windows 2000 Help中查询这个主题，以取得一些资讯。