Hi,
I was looking at some code in curl for TLS status (aka OCSP staple)
verification, and I've noticed that curl does something peculiar. If curl
asks for an OCSP staple and receives a response, one of the steps in
vtls/openssl.c:verifystatus() is to match the peer certificate to the list
of OCSP_CERTID structures inside the OCSP_RESPONSE. That is perfectly
logical, but the matching by itself is a bit strange:
for(i = 0; i < sk_X509_num(ch); i++) {
X509 *issuer = sk_X509_value(ch, i);
if(X509_check_issued(issuer, cert) == X509_V_OK) {
id = OCSP_cert_to_id(EVP_sha1(), cert, issuer);
break;
}
}
^^ curl assumes that the peer certificate's issuer attributes would be hashed
with sha1. Although sha1 is the default value in several OpenSSL OCSP APIs,
it's far from the only possibility and my trivial test examples show that this
snippet would fail if the server responds with OCSP_CERTIDs based off, say,
sha256.
Am I missing something here?
If not, imvho, the "fix" in this particular case is somewhat involved -- for
every OCSP_CERTID (#1) available in the stapled response, curl should construct
its own OCSP_CERTID (#2) corresponding to the peer certificate based on the
hash of #1 and use OCSP_resp_find_status() to locate the OCSP_CERTID in the
response. And only after trying all of OCSP_CERTIDs in this fashion
unsuccessfully should one reply with:
failf(data, "Could not find certificate ID in OCSP response");
result = CURLE_SSL_INVALIDCERTSTATUS;
Does that make sense? Should I submit a patch ?
Some of the context for this is <URL:
https://github.com/openssl/openssl/issues/8561>
ivr
--
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
