这种对"openssl s_client -connect"的调用实际上是在查询 OCSP 响应程序服务器以确认证书的当前有效性吗?



我很好奇openssl命令行接口的单行调用是否能够执行完整的OCSP验证协议,例如查询链中的所有OCSP响应服务器以确认证书的当前有效性。

为了查看是否是这样,我将-CAfile选项指定为/dev/null希望这将避免使用任何缓存的证书来代替查找: 正如@pepo的回答中所解释的,服务器证书链是作为RFC 5246中指定的基本TLS1.2握手的一部分发送的(更多详细信息请参阅下面的更新)
# openssl s_client -CAfile /dev/null -connect www.equifaxsecurity2017.com:443

它给出了输出:

CONNECTED(00000003)
depth=3 C = US, O = Equifax, OU = Equifax Secure Certificate Authority
verify return:1
depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
verify return:1
depth=1 C = US, O = GeoTrust Inc., OU = Domain Validated SSL, CN = GeoTrust DV SSL CA - G3
verify return:1
depth=0 CN = www.equifaxsecurity2017.com
verify return:1
---
Certificate chain
0 s:/CN=www.equifaxsecurity2017.com
i:/C=US/O=GeoTrust Inc./OU=Domain Validated SSL/CN=GeoTrust DV SSL CA - G3
1 s:/C=US/O=GeoTrust Inc./OU=Domain Validated SSL/CN=GeoTrust DV SSL CA - G3
i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority
---
Server certificate
-----BEGIN CERTIFICATE-----
<omitted>
-----END CERTIFICATE-----
subject=/CN=www.equifaxsecurity2017.com
issuer=/C=US/O=GeoTrust Inc./OU=Domain Validated SSL/CN=GeoTrust DV SSL CA - G3
---
No client certificate CA names sent
....

openssl似乎在没有缓存文件帮助的情况下找到了链中的所有三个链接,因此必须通过互联网与代理(1)GeoTrust DV SSL CA-G3和(2)GeoTrust Global CA进行通信,以构建链。这是正确的吗TR

openssl是否也通过向三个OCSP响应者中的每一个发出适当的OCSP请求来验证链?

(我的猜测是"否"。我也知道openssl ocsp ...可以与证书上的手动文本操作一起使用,一次一个链接地执行OSCP验证。然而,openssl被编写来执行完整的OCSP验证似乎是合理的,甚至更可取,这就是我问的原因。)

更新9-14-2017:

由于@pepo的回答"SSL服务器(如果配置正确)将发送证书链(根CA证书除外)">,我查阅了RFC 5246,发现了部分"7.4.2服务器证书">TLS1.2握手的"服务器证书"部分的内容:

这是一个证书序列(链)。发件人的
证书必须位于列表的第一位。以下每个证书必须直接认证其前面的证书。因为证书验证要求根密钥独立分发指定根证书的自签名证书在假定远程端必须已经拥有它才能在中进行验证无论如何。

此外,由于@pepo对-crl_check_all选项的回答,我尝试了一下,得到了以下输出:

CONNECTED(00000003)
depth=0 CN = www.equifaxsecurity2017.com
verify error:num=3:unable to get certificate CRL
verify return:1
depth=1 C = US, O = GeoTrust Inc., OU = Domain Validated SSL, CN = GeoTrust DV SSL CA - G3
verify error:num=3:unable to get certificate CRL

它失败,出现错误unable to get certificate CRL。事实证明,这并不重要,因为所选网站已启用OCSP装订

如果不是-crl_check_all执行CRL检查,我们添加选项-status请求OCSP装订,则接收以下输出:

CONNECTED(00000003)
<stuff omitted omitted>
OCSP response: 
======================================
OCSP Response Data:
OCSP Response Status: successful (0x0)
Response Type: Basic OCSP Response
Version: 1 (0x0)
Responder Id: CE2C8B1E8BD2300FD1B15446E9B594254949321B
Produced At: Sep 10 11:12:45 2017 GMT
Responses:
Certificate ID: ...
Cert Status: good
This Update: Sep 10 11:12:45 2017 GMT
Next Update: Sep 17 11:12:45 2017 GMT
Signature Algorithm: sha1WithRSAEncryption
<stuff omitted>

这表明OCSP装订已在服务器端启用,但似乎仅对第一个(叶)证书启用,而不对第二个证书启用。(自签名的第三个证书必须独立验证)。因此,要验证第二个证书,必须使用CRL检查OCSP请求响应。由于此特定授权链未启用CRL检查,因此只剩下OCSP请求响应

感谢@pepo的回复,我更好地理解了opensslTLS1.2协议和这些验证授权的方法(按历史顺序列出)之间的关系:

  • CRL(证书吊销列表)检查
  • OSCP请求和响应
  • OCSP缝合

然而,也提出了一个新问题:

  • 关于服务器在"服务器证书"消息步骤期间与链中的证书一起发送的OCSP装订响应,它包含需要验证的签名信息(从下一级开始)。这个签名信息在openssl ... -status的处理过程中是否得到了验证

更新:9-15-2017

根据这一点,"这个签名信息在openssl ... -status的处理过程中真的得到了验证吗?"这个问题的安全答案似乎是否定的答复以及下面@dave_thompson_085的评论(他已经浏览了源代码)。

这让人困惑吗?对奇怪地"OpenSSL食谱(feistyduck,Ivan Ristić)"是对这个问题异常不清楚,没有显示验证签名的明确方式,同时也没有明确表示签名是否已被验证。相反,对于其他两种类型的吊销检查:

  • CRL检查
  • 以及OCSP请求响应(查找"提交OCSP请求")

"OpenSSL Cookbook"显示了明确的方法(食谱),以达到额外的距离,并使用openssl已经产生的信息手动完成验证。如果认为"OpenSSL Cookbook"没有包含对缝合OCSP回复进行完全验证的配方,是因为它没有必要,那将是一个非常人为的错误。

IMHO,OpenSSL(或任何类似的库)将非常负责按照以下优先级顺序包含顶级文档

  • (1)解释OpenSSL不提供TLS+授权的黑盒解决方案
  • (2) 关于该解决方案的有限部分的解释(例如,未经授权检查的TLS握手)
  • (3) 关于组装OpenSSL组件以完成的配方的文档授权检查解决方案

误解很容易传播。就在几天前,我正试图编写一个简单的程序,从我的Linux Ubuntu PC发送通知邮件。标准的Python版本(第2版和第3版)包括一个SMTP和一个"实现"TLS1.2的SSL库。在10分钟内,我就可以编写程序并在调试器中遍历它。我可以看到python SSL库对OpenSSL的handshake()函数的调用,并假设handshake()必须处理所有的授权检查,基于SSL库和SMTP库在不包括授权检查的情况下不会发布的假设。奇怪的是,SSL库中的调用代码包含一个后handshake()检查,以确保接收到的证书名称与被调用服务器的名称匹配。"如果handshake()已经处理了所有的签名验证等,为什么需要这样的原始检查?",我想。这种怀疑开始了一段剥离TLS安全洋葱的旅程,从那以后我一直哭个不停。

我不想尝试重新发明轮子,反正它可能会摇晃。然而,我似乎找不到任何可用的轮子。从这里去哪里

SSL服务器(如果配置正确)将发送证书链(根CA证书除外)。你可以在这里验证。

Openssl没有获取这些证书,但它在启动ssl连接时为它们提供了服务。您可以在openssl文档中阅读更多关于s_client行为的信息

我不知道它是否执行OCSP验证,但我对此表示怀疑。IMHO(基于The s_client utility is a test tool and is designed to continue the handshake after any certificate verification errors.)默认情况下它根本不执行任何验证,但您至少可以通过指定参数-crl_check_all来启用CRL检查

openssl s_client -connect www.equifaxsecurity2017.com:443 -crl_check_all

最新更新