我们目前有一组Web服务公开接口，用于各种不同的客户端类型和角色。
背景
我的问题是，在每个请求上验证客户端证书是非常重要的，并且很容易控制应用程序服务器上的CPU时间。我已经尝试分离身份验证＆amp;将应用程序部分分配到不同的物理服务器上以减少负载，但这并不能提高整体的调度速度 - 无论在何处执行，请求仍需要一段时间进行身份验证。
我想尝试通过在成功进行客户端证书验证后生成HTTP cookie（带有关联的服务器端会话）来限制身份验证的数量，当客户端提供该证书时，将会跳过客户端证书验证（尽管还在谈论SSL）。我还想限制会话时间，并从客户的角度使流程尽可能透明。
我的问题：
答案 0 :(得分：4)
生成HTTP 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请求/响应进行客户端证书验证，或者在每个会话开始时只执行一次？
无论如何，这些都是一些想法，祝你好运！