我们最近为我们的客户端/服务器通信实施了基于 SSL 的 WS Trust 安全性。我们的应用程序被成千上万的客户使用，分布在世界各地。我们过去在安全通信方面遇到的问题之一是时钟不同步的客户难以连接，从而导致客户来电并感到沮丧。不幸的是，过去引起的反应是简单地禁用此检查或简单地将可接受的时钟偏差增加到接近无限量。
我不希望我们系统的安全性受到损害，也不希望引发大量客户投诉，因为他们的时钟与我们服务器上的时间（与互联网时间同步）没有密切同步。为了防止同步检查被有效禁用，我必须首先能够向我的经理解释为什么这是一个坏主意，以及为什么时钟同步的好处超过了客户投诉或混淆的成本。
在 SSL 中，时钟用于证书验证。客户端需要确保它与正确的服务器通信；为此，客户端将验证服务器的证书。验证意味着验证很多事情；其中两个涉及时钟：
服务器的证书（以及所有涉及的 CA 证书）必须在其有效时间范围内包含当前时间。每个证书作为一个notBefore和一个notAfter字段；当前时间必须介于这两个日期之间。
客户端应该通过从适当的颁发者（CA）获取（并验证）CRL（证书撤销列表）来获取每个证书的撤销状态。如果（特别是）CRL“不太旧”，则认为 CRL 是可接受的：同样，CRL 有一个thisUpdate字段说明它是何时生成的，以及一个nextUpdate或多或少用作 CRL 到期日期的字段。
如果客户端的时钟关闭，那么它将破坏这些功能中的一个或两个。例如，服务器的证书将被视为“长期过期”或“尚不可用”，从而导致拒绝。
接受客户端的时钟关闭意味着客户端被修改为忽略证书和 CRL 中的日期。安全的最终结果是，如果攻击者成功窃取了服务器的私钥，那么该攻击者将能够永远冒充该服务器。撤销的重点是要有一个经过验证的方法来从这种妥协中恢复；证书到期的目的是防止 CRL 无限增长。如果客户无视撤销和/或到期，那么原始后果是一旦发生妥协，那么你注定永远。这通常被认为是一件坏事。
更重要的是，这是客户端的问题，而不是服务器的问题。如果您操作服务器，那么正确验证您的证书是客户端的工作，而不是您的工作。如果客户真的坚持不安全地做事并且容易受到攻击，那么您就无法真正阻止它，至少在技术上不是（您可以通过合同来做事：如果客户的无能允许违反，客户应该为此付出代价）。
同样，如果客户端可以与您的服务器通信，则它们连接到某种网络，这意味着基于 Internet 的时间同步是可能的。对于某些嵌入式设备而言，要求准确的时钟具有挑战性，但对于联网的计算机（包括智能手机）则不应该如此。
简单版（针对经理）：时间同步可以防止重放攻击。没有它们，有人可以记录客户端和服务器之间发送的数据包，解密，修改数据，然后重新发送数据包流，没有人会更聪明。但是，因为解密需要时间，时间戳（双方都验证）可以表明流是“重播”。
也许您可以考虑为您的公司/应用程序设置更长的超时期限？您可以通过扩大窗口来实现一些好处，而不是狭窄的窗口。当然，这必须分析它对您的系统的全部影响。