Est-ce que cette invocation de "openssl s_client -connect" interroge réellement les serveurs répondeurs OCSP pour confirmer la validité actuelle des certificats?

Question

Je suis curieux de savoir si l'invocation d'une seule ligne de l'interface de ligne de commande openssl a la capacité d'exécuter un protocole de vérification OCSP complet, par ex. interroger tous les serveurs répondeurs OCSP dans une chaîne pour confirmer la validité actuelle des certificats.

Pour voir si cela pourrait être, je spécifié l'option -CAfile comme /dev/null, espérant qui éviterait les certificats mises en cache utilisées en lieu et place de la recherche:Comme cela est expliqué dans la réponse de de @pepo, le serveur chaîne de certificat est envoyée une partie de la poignée de main de TLS1.2 de base spécifié dans la RFC 5246 (plus de détails dans la mise à jour ci-dessous)

# openssl s_client -CAfile /dev/null -connect www.equifaxsecurity2017.com:443 

qui donne le résultat:

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 
.... 

Il semble que openssl a trouvé les trois maillons de la chaîne, sans l'aide de fichiers mis en cache, et ainsi doivent avoir communiqué sur Internet avec des agents (1) CA GeoTrust DV SSL - G3 et (2) GeoTrust Global CA, pour construire la chaîne. Est-ce exact? Non! Ce n'est pas correct!

Est-ce que openssl a également vérifié la chaîne en effectuant la demande OCSP appropriée à chacun des trois répondeurs OCSP?

openssl ocsp ... Je sais également que openssl ocsp ... peut être utilisé conjointement avec les opérations de texte manuelles sur les certificats pour effectuer une vérification OSCP un lien à la fois. openssl aurait été écrit pour effectuer la vérification OCSP complète, et c'est pourquoi je demande)

MISE A JOUR 14/09/2017:.

Merci à « @pepo de répondre « serveur SSL (si configuré correctement) enverra la chaîne de certificat (excepté le certificat CA de racine) ", j'ai levé les yeux RFC 5246 et trouvé la section " 7.4.2 Se RVer certificat » qui explique le contenu de la partie « certificat de serveur » de la poignée de main de TLS1.2:

Ceci est une séquence (chaîne) des certificats. Le certificat
de l'expéditeur DOIT venir en premier dans la liste. Chaque certificat suivant DOIT certifier directement celui qui le précède. Puisque la validation du certificat nécessite que les clés racines soient distribuées indépendamment, le certificat auto-signé qui spécifie le certificat racine peut être omis de la chaîne, en supposant que l'extrémité distante doit déjà le posséder pour le valider dans tous les cas.

De plus, grâce à la réponse de @ pepo sur l'option -crl_check_all, j'ai essayé et obtenu les résultats suivants:

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 

Il a échoué avec l'erreur unable to get certificate CRL. Il s'avère ne pas être critique, car le site Web choisi a OCSP agrafage activé.

Si au lieu de -crl_check_all pour effectuer vérification CRL, nous à la place add the option -status qui demande OCSP agrafer, la sortie suivante est reçue:

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> 

Cela montre agrafer OCSP est activé sur le serveur côté, mais il semble être activé uniquement pour le premier certificat (la feuille), et non pour le deuxième certificat. (Le troisième certificat auto-signé doit être validé indépendamment de toute façon). Ainsi, pour vérifier le deuxième certificat, vous devez utiliser CRL-checking ou OCSP-request-response. Puisque vérification CRL n'est pas activé par cette chaîne d'autorisation particulière, cela laisse seulement OCSP-request-response.

Merci à la réponse de @pepo, je comprends beaucoup mieux la relation entre openssl, le TLS1.2 protocole, et ces méthodes d'autorisation de vérification (par ordre historique):

• CRL (liste de révocation de certificats) vérification
• demande OCSP et la réponse
• OCSP agrafer

Cependant, une nouvelle question a également été soulevée:

• En ce qui concerne la réponse OCSP-agrafer envoyé par le serveur ainsi que les certificats de la chaîne pendant l'étape de message « Certificate Server » - ce qui a des informations de signature (de la prochaine niveau supérieur) qui doit être vérifié. Cette information de signature est-elle réellement vérifiée pendant le traitement de openssl ... -status?

MISE À JOUR: 9-15-2017

La réponse sûre à la question « Est-ce l'information de signature effectivement vérifié lors du traitement de openssl ... -status » ne semble pas, selon cette answer et aussi Commentaire @ dave_thompson_085 ci-dessous (il a regardé à travers le code source).

Est-ce que c'est déroutant? Oui! Bizarrement, le "Livre de cuisine OpenSSL (feistyduck, Ivan Ristić)" est unusually unclear about this question, montrant aucune manière explicite de vérifier la signature, mais n'a pas explicitement indiqué si oui ou non la signature a été vérifiée.En revanche, pour les deux autres types de vérification de révocation:

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

le « OpenSSL livre de recettes » présente des méthodes explicites (recettes) pour la distance supplémentaire et effectuer la vérification manuelle en utilisant les informations déjà fournies par openssl. Ce serait une erreur très humaine de déduire que la raison "OpenSSL Cookbok" n'inclut pas la recette pour la validation complète d'une réponse OCSP agrafée parce qu'elle n'est pas nécessaire.

à mon humble avis, il serait très responsable de OpenSSL (ou toute bibliothèque similaire) pour inclure la documentation de haut niveau, dans l'ordre de priorité suivant

• (1) explication OpenSSL ne propose pas une solution de boîte noire TLS + autorisation,
• (2) explication sur ce qui limite une partie de cette solution, il ne offre (par exemple, poignée de main TLS sans l'autorisation de vérification),
• (3) la documentation sur les recettes pour l'assemblage de composants OpenSSL pour compléter l'autorisation solution de vérification.

Malentendu se propage très facilement. Il y a quelques jours, j'essayais d'écrire un programme simple pour envoyer des messages de notification à partir de mon PC Linux Ubuntu. Les versions standard de Python (versions 2 et 3) incluent un serveur SMTP et une bibliothèque SSL "implémentant" TLS1.2. En 10 minutes, je pourrais écrire le programme et le parcourir dans le débogueur. J'ai pu voir l'appel de la bibliothèque SSL python à la fonction handshake() d'OpenSSL et supposé que handshake() devait gérer toutes les vérifications d'autorisation, en supposant que la bibliothèque SSL et la bibliothèque SMTP ne seraient pas libérées sans inclure de contrôle d'autorisation. Bizarrement, le code appelant dans la bibliothèque SSL comprenait une vérification post-handshake() pour s'assurer que le nom du certificat reçu correspondait à celui du serveur appelé. "Pourquoi un tel contrôle primitif serait-il nécessaire si handshake() traitait déjà toutes les vérifications de signature, etc.?", Pensais-je. Ce doute a déclenché un voyage en épluchant des couches de l'oignon de sécurité TLS et je n'ai pas pu arrêter de pleurer depuis.

Je ne veux pas essayer de réinventer la roue, qui serait probablement bancale de toute façon. Pourtant, je ne peux pas trouver de roues disponibles. Où aller en partant d'ici?

Answer 1

Le serveur SSL (s'il est configuré correctement) enverra la chaîne de certificats (sauf le certificat d'autorité de certification racine). Vous pouvez le vérifier here. Openssl n'a pas récupéré ces certificats mais les a servis lors de l'initialisation de la connexion SSL. Vous pouvez en savoir plus sur le comportement s_client dans openssl documentation

Je ne sais pas si elle effectue une vérification OCSP mais je doute. À mon humble avis (basé sur The s_client utility is a test tool and is designed to continue the handshake after any certificate verification errors.), il ne fonctionne pas de validation par défaut du tout, mais vous pouvez au moins permettre la vérification CRL par l'argument spécifiant -crl_check_all

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