security - Is this invocation of "openssl s_client -connect" actually querying OCSP responder servers to confirm the current validity of certificates? -
i curious whether invocation of single line of openssl command line interface has ability perform complete ocsp verification protocol, e.g. query ocsp responder servers in chain confirm current validity of certificates.
to see if might so, specified as explained in @pepo 's answer, server certificate chain sent part of basic tls1.2 handshake specified in rfc 5246 (more details in update below)-cafile option /dev/null, hoping avoid cached certificates being used in lieu of lookup:
# openssl s_client -cafile /dev/null -connect www.equifaxsecurity2017.com:443 which gave output:
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 .... looks though no! it's not correct!openssl has found 3 links in chain without cached files, , must have communicated on internet agents (1) geotrust dv ssl ca - g3, , (2) geotrust global ca, build chain. correct?
has openssl verified chain making appropriate ocsp request each of 3 ocsp responders?
(my guess "no". aware openssl ocsp ... can used in conjunction manual text operations on certificates perform oscp verification 1 link @ time. however, seem plausible, preferable, openssl have been written perform full ocsp verification, , why asking.)
update 9-14-2017:
thanks @pepo 's answer "ssl server (if configured correctly) send certificate chain (except root ca certificate)", looked rfc 5246 , found section "7.4.2 server certificate" explains content of "server certificate" part of tls1.2 handshake:
this sequence (chain) of certificates. sender's
certificate must come first in list. each following certificate must directly certify 1 preceding it. because certificate validation requires root keys distributed independently, self-signed certificate specifies root certificate authority may omitted chain, under assumption remote end must possess in order validate in case.
furthermore, @pepo's answer -crl_check_all option, tried , got following output:
connected(00000003) depth=0 cn = www.equifaxsecurity2017.com verify error:num=3:unable 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 certificate crl it failed error unable certificate crl. turns out not critical, because chosen website has ocsp stapling enabled.
if instead of -crl_check_all perform crl checking, instead add option -status requests ocsp stapling, following output received:
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: update: sep 10 11:12:45 2017 gmt next update: sep 17 11:12:45 2017 gmt signature algorithm: sha1withrsaencryption <stuff omitted> this shows ocsp stapling enabled on server side, appears enabled first (the leaf) certificate, , not second certificate. (the self-signed third certificate must validated independently anyway). so, verify second certificate, either crl-checking or ocsp-request-response must used. since crl-checking not enabled particular authorization chain, leaves ocsp-request-response.
thanks @pepo 's reply, understand better relationship between openssl, tls1.2 protocol, , these methods verifying authorization (listed in historical order):
- crl (certificate revocation list) checking
- oscp request , response
- ocsp stapling
however, new question has been raised:
- regarding ocsp-stapling response sent server along certificates in chain during "server certificate" message step - has signature information (from next level up) needs verified. signature information verified during processing of
openssl ... -status?
update: 9-15-2017
the safe answer question "is signature information verified during processing of openssl ... -status? " seems no, according answer , @dave_thompson_085 's comment below (he has looked through source code).
is confusing? yes! oddly, "openssl cookbook (feistyduck, ivan ristić)" unusually unclear question, showing no explicit way verify signature, while not explicitly saying whether or not signature has been verified. in contrast, both of other types revocation checking:
the "openssl cookbook" shows explicit methods (recipes) go distance , complete verification manually using information yielded openssl. human mistake infer reason "openssl cookbok" not include recipe full validation of stapled ocsp-reponse because not necessary.
imho, responsible of openssl (or similar library) include top level documentation, in following order of priority
- (1) explanation openssl not offer black box solution tls+authorization,
- (2) explanation limited part of solution offer (e.g., tls handshake without authorization checking),
- (3) documentation on recipes assembling openssl components complete authorization checking solution.
misunderstanding spreads easily. few days ago trying write simple program send notification mail linux ubuntu pc. standard python releases (both ver 2 , 3) include smtp , ssl library "implementing" tls1.2. in 10 minutes write program , walk through in debugger. see call python ssl library openssl's handshake() function , assumed handshake() must handling authorization checking, based on assumption ssl library , smtp library not released without including authorization checking. strangely, calling code in ssl library included post-handshake() check make sure received certificate name matched of called server. "why such primitive check necessary if handshake() handled signature verifications, etc.?", thought. doubt started journey peeling layers of tls security onion , haven't been able stop crying since.
i don't want try re-invent wheel, wobbly anyway. yet, can't seem find available wheels. go here?
ssl server (if configured correctly) send certificate chain (except root ca certificate). can verify here.
openssl did not fetch these certificate got them served when initiating ssl connection. can read more s_client behavior in openssl documentation
i don't know if performs ocsp verification doubt it. imho (based on the s_client utility test tool , designed continue handshake after certificate verification errors.) not perform validation default @ can @ least enable crl checking specifying argument -crl_check_all
openssl s_client -connect www.equifaxsecurity2017.com:443 -crl_check_all
Comments
Post a Comment