security - 此“openssl s_client -connect”调用实际上是在查询OCSP响应程序服务器以确认证书的当前有效性吗？

Question

我对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在没有缓存文件的任何帮助的情况下找到了链中的所有三个链接，因此必须已通过Internet与代理（1）GeoTrust DV SSL CA-G3和（2）GeoTrust Global CA进行了通信，建立链条。那是对的吗？
 没有！不对！

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

（我的猜测是“否”。我也知道 openssl ocsp ...可以与证书上的手动文本操作结合使用，以一次一次执行一次OSCP验证。但是， 会被编写为执行完整的OCSP验证，这就是为什么我要问这个问题。）

更新9-14-2017：

感谢@pepo的回答“ SSL服务器（如果配置正确）将发送证书链（根CA证书除外）”，我查阅了RFC 5246并找到了“ 7.4.2服务器证书”部分，该部分解释了“服务器”的内容TLS1.2握手中的“证书”部分：


  这是证书的序列（链）。发件人的
  证书必须在列表中排在第一位。以下各证书
  必须直接证明其前一个。因为证书
  验证要求根密钥是独立分发的，
  指定根证书的自签名证书
  在以下假设下，可以从链中省略授权
  远端必须已经拥有它才能验证它
  任何情况。


此外，由于@pepo对 openssl选项的回答，我尝试了一下并得到以下输出：

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

它失败，错误为 -crl_check_all。事实并非如此，因为所选网站已启用OCSP装订。

如果不是用 unable to get certificate CRL来执行CRL检查，而是
add the option -crl_check_all
请求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-request-response。

感谢@pepo的回复，我更好地理解了 -status，TLS1.2协议以及这些用于验证授权的方法（按历史顺序列出）之间的关系：


CRL（证书吊销列表）检查
OSCP请求和响应
OCSP装订


但是，还提出了一个新问题：


关于服务器在“服务器证书”消息步骤期间与链中的证书一起发送的OCSP装订响应-该证书具有签名信息（从下一级开始）。在处理 openssl期间，此签名信息是否已实际验证？


更新：9/15/2017

据此，对于“在 openssl ... -status处理期间是否确实验证了此签名信息？”这个问题的安全答案似乎为“否”
answer
以及下面的@ dave_thompson_085的注释（他浏览了源代码）。

令人困惑吗？是!奇怪，
“ OpenSSL食谱（feistyduck，IvanRistić）”
是
unusually unclear about this question,
显示没有明确的方法来验证签名，同时也没有明确说明签名是否已被验证。相反，对于其他两种类型的吊销检查：


CRL-checking
and OCSP-request-response (find "submit OCSP request")


“ OpenSSL Cookbook”显示了明确的方法（配方），可以走更多的距离并使用 openssl ... -status已经产生的信息手动完成验证。推断原因“ OpenSSL Cookbok”不包含对装订的OCSP响应进行完全验证的原因是非常人为的，因为这是不必要的。

恕我直言，它将由OpenSSL（或任何类似的库）来负责按以下优先级顺序包含顶级文档


（1）关于OpenSSL不为TLS +授权提供黑盒解决方案的说明，
（2）关于该解决方案提供的有限部分的说明（例如，未经授权检查的TLS握手），
（3）有关组装OpenSSL组件以完成的配方的文档
授权检查解决方案。


误解很容易蔓延。就在几天前，我试图编写一个简单的程序从Linux Ubuntu PC发送通知邮件。标准的Python版本（版本2和版本3）包括SMTP和“实现” TLS1.2的SSL库。在10分钟内，我可以编写程序并在调试器中逐步进行。我可以看到从python SSL库到OpenSSL的 openssl函数的调用，并假定 handshake()必须处理所有授权检查，这是基于以下假设：如果不包括授权检查，则不会释放SSL库和SMTP库。 。奇怪的是，SSL库中的调用代码包括一个 handshake()后检查，以确保接收到的证书名称与被调用服务器的名称匹配。我想：“如果 handshake()已经处理了所有签名验证，为什么要进行这种原始检查？”那个疑问开始了剥离TLS安全性洋葱层的旅程，此后我一直没有停止哭泣。

我不想尝试重新发明轮子，不管怎么说，它可能会摇摆不定。但是，我似乎找不到任何可用的轮子。然后去哪儿？

Answer 1

SSL服务器（如果配置正确）将发送证书链（根CA证书除外）。您可以here验证它。

Openssl没有获取这些证书，但是在启动ssl连接时将它们送达。您可以在openssl documentation中阅读有关s_client行为的更多信息。

我不知道它是否执行OCSP验证，但我对此表示怀疑。恕我直言（基于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