通过SSL/TLS的OCSP

问题描述：

据我所知，OCSP仅提供了明确的请求和响应签名手段（请求[RFC2560，第7页]，响应请求[RFC2560，第8页]），但它确实没有提及加密。是否通过SSL/TLS运行OCSP以保证其机密性是典型的（或者甚至可能，我认为当然是这样）？通过SSL/TLS的OCSP

谢谢。

为什么？证书是公共文件。有什么风险？ – EJP

我只是想着[很可能]非典型场景。例如。我拥有一家为其运营私人CA的公司，我不希望任何竞争对手公司知道我正在撤销哪些用户：被撤销的用户意味着他/她可能是[解雇]的员工，他们[很可能]能够贿赂他/她以获取私人信息。或者埃里克森在下面给出的例子，这看起来更为典型。 – Ginswich

如果您想从诚信获取更多信息而不是保密信息。我认为可能会执行MiTM攻击，给出关于证书撤销状态的不正确状态，迫使用户使用它的旧版本 - 证书。 – ndrix

答

这绝对是可能的，但它不是典型的。如果您正在请求主机证书的状态，则OCSP请求不太可能揭示窃听者不知道任何东西，即您正在尝试验证的主机，即—。

对于S/MIME电子邮件或其他应用程序，OCSP请求可能会更加敏感，因为它们将支持组织分析。使用HTTPS传输可能是一个好主意。

感谢您的回复。但是后来，由于很可能通过SSL/TLS运行OCSP，为什么加密没有明确支持，但签名是？将所有这些负担转移到SSL/TLS（或IPSEC或任何其他安全协议）是不是更容易？ – Ginswich

@Ginswich我认为签名是在那里，以便可以提前创建响应或由客户端缓存响应。换句话说，签名可以保护休息时的完整性。我知道一些商业OCSP响应者提供更好的性能，在处理CRL时预先计算响应。这些服务器倾向于响应大量的响应，其中一个响应与您所做的请求相对应。 – erickson

意义重大。再次感谢你。 – Ginswich

答

是的，可以使用SSL/TLS。但考虑这样的：

当证书包括cRLDistributionPoints扩展与 HTTPS URI或类似的方案，可以引入循环依赖。依赖方*执行额外的路径验证以获取完成初始路径验证所需的CRL！还可以使用authorityInfoAccess或 subjectInfoAccess扩展中的https（）URI（或类似方案）创建循环条件。在最坏的情况下，这种情况可能会导致无法解析的依赖关系。

采取自RFC5280，第8节。本节讨论使用https的CRL分发点的问题。但你必须使用SSL/TLS的OCSP请求相同的问题：你必须检查服务器证书的有效性...

答

在RFC2560的附录是下面写：

一.1.1请求 [...]如果需要隐私是，使用HTTP交换的OCSP事务可能是使用TLS/SSL或其他一些较低层协议保护。

但是大多数OCSP-Responder只提供没有TLS/SSL的HTTP。

相关推荐