4

我们目前有一组 Web 服务，将接口暴露给各种不同的客户端类型和角色。

背景：

  • 身份验证通过 SSL 客户端证书验证处理。目前这是在 Web 服务代码中完成的（不是由 HTTP 服务器）。我们不想使用任何比这更安全的方案。这篇文章不是在谈论授权，而是在谈论身份验证。
  • Web 服务同时讨论 SOAP 和 REST(JSON)，我绝对没有兴趣开始讨论这两种方法的优点。
  • 通过 Web 服务公开的所有操作都是无状态的。

我的问题是在每个请求上验证客户端证书是非常重量级的，并且很容易支配应用服务器上的 CPU 时间。我已经尝试将身份验证和应用程序部分分离到不同的物理服务器上以减少负载，但这并不能提高整体调度速度——无论在哪里完成，请求仍然需要恒定的时间来进行身份验证。

我想尝试通过在客户端证书验证成功后生成一个 HTTP cookie（带有关联的服务器端会话）来限制身份验证的数量，当客户端提供该 cookie 时，将导致客户端证书验证被跳过（尽管仍在讨论SSL)。我还想对会话进行时间限制，并从客户的角度使流程尽可能透明。

我的问题：

  1. 这仍然安全吗？（以及我们如何优化安全性和实用性？）
  2. 这个方案有免费的实现吗？（我知道 CA 的 SiteMinder 产品）
  3. 鉴于上述情况，我们应该继续在应用程序内进行身份验证，还是转移到服务器内？
4

1 回答 1

4

在客户端证书验证成功后生成一个 HTTP cookie（带有关联的服务器端会话），当客户端提供该 cookie 时，将导致客户端证书验证被跳过

这仍然安全吗？（以及我们如何优化安全性和实用性？）

理论上它并不那么安全，因为服务器无法再向自己证明不存在中间人。

当客户端提供客户端证书时，服务器可以加密信任它。客户端和服务器应该基于客户端的密钥加密和数据（嗯，会话密钥）。如果没有客户端证书，服务器只能希望客户端已经很好地验证了服务器的证书（如客户端所感知的那样），并通过这样做消除了 MitM 先生的可能性。

开箱即用的 Windows 客户端信任 200 多个根 CA 证书。在没有客户端证书的情况下，服务器最终会通过扩展信任。

以下是关于在数据包捕获中寻找什么以验证客户端证书是否提供针对 MitM 的防御的很好的文章：http: //www.carbonwind.net/ISA/ACaseofMITM/ACaseofMITMpart3.htm

这种类型的 MitM 的解释。 http://www.networkworld.com/community/node/31124

某些防火墙设备盒实际上使用此技术对 SSL 进行深度检查。

MitM 曾经看起来像是一个巨大的 Mission Impossible 风格的制作，需要花费很多时间才能完成。真的，尽管它只需要一个受感染的 DNS 解析器或路由器就可以了。世界上有很多小 Linksys 和 Netgear 盒子，其中可能有两三个没有最新的安全更新。

在实践中，这对于主要金融机构的网站来说似乎已经足够好了，尽管最近的证据表明它们的风险评估策略并不理想。

这个方案有免费的实现吗？（我知道 CA 的 SiteMinder 产品）

只是一个客户端cookie，对吧？这似乎是每个 Web 应用程序框架的一个非常标准的部分。

鉴于上述情况，我们应该继续在应用程序内进行身份验证，还是转移到服务器内？

硬件加密加速器（SSL 代理前端或加速卡）可以显着加快这些速度。

将证书验证移至 HTTP 服务器可能会有所帮助。无论如何，你可能会在加密数学中做一些重复。

看看您是否会受益于客户端证书上更便宜的算法或更小的密钥大小。

验证客户端证书后，您可以尝试在短时间内缓存它（甚至整个内容）的哈希摘要。这可能使您不必在每次点击时都在信任链上重复签名验证。

您的客户多久进行一次交易？如果构成您交易的大部分的那些经常打击您，您可以说服他们在单个 SSL 协商/身份验证中组合多个交易。查看设置 HTTP Keep-Alive 标头。他们可能已经在某种程度上这样做了。也许您的应用程序正在对每个 HTTP 请求/响应进行客户端证书验证，或者在每个会话开始时只进行一次？

无论如何，这些都是一些想法，祝你好运！

于 2009-07-29T03:21:45.860 回答