OCSP yn erbyn CRL: sut mae pob gwiriad dirymu yn gweithio mewn gwirionedd

Mae un o’r ddau wiriad dirymu hyn yn dychwelyd ateb llofnodedig am un dystysgrif, a’r llall yn dychwelyd rhestr lofnodedig a lawrlwythwch yn gyfan. Mae’r ddau i fod i ddweud wrth wiriedydd a yw tystlythyr yn dal i fod yn ymddiriedadwy, ac mae’r ddau yn methu mewn ffyrdd nad ydynt yn edrych o gwbl yn debyg i’w gilydd. Mae’r drefn isod yn dilyn yr hyn y mae gweithredwr yn ei gyrraedd mewn gwirionedd mewn cynhyrchu, gan ddechrau gyda’r beitiau ar y wifren a gorffen gyda phorth yn gwrthod cysylltiad. Mae hepgor cam yn un ffordd y mae defnydd yn gorffen gyda pholisi dirymu nad yw’n bodoli ond ar bapur.

Cam 1: Beth mae pob gwiriad yn ei ddychwelyd a pha mor hir y mae’n parhau’n ddefnyddiol

Cyhoeddir CRL fel un gwrthrych llofnodedig sy’n cwmpasu pob tystysgrif y mae’r un sy’n ei chyhoeddi wedi’i dirymu, felly mae gwiriedydd yn ei chymryd unwaith ac yn ei hailddefnyddio nes bod nextUpdate y rhestr wedi pasio. Mae ymateb OCSP yn gulach: mae’n ateb ar gyfer un dystysgrif yn union ac yn cario thisUpdate, producedAt ac fel rheol nextUpdate hefyd. Mae’r gwahaniaeth hwnnw’n llywio popeth arall. Mae CRL a gacheir yn mynd yn hen yn dawel, oherwydd mae’r ffeil yn dal i ddadansoddi ac mae ei llofnod yn dal i ddilysu, tra bo ymateb OCSP wedi dod i ben yn amlwg yn ddiwerth yr eiliad y byddwch yn darllen ei stampiau amser.

Cachu felly yw’r peth cyntaf i’w benderfynu: pa gydran sy’n cadw’r copi, a pha nenfwd y mae’r copi hwnnw’n ufuddhau iddo. Ar borth dylai’r nenfwd fod yn nextUpdate heb lawer o ymyl diogelwch, byth yr hyn y mae pennawd cachu HTTP yn digwydd ei awgrymu. Mae openssl crl -in issuer.crl -noout -lastupdate -nextupdate yn argraffu’r ddau ddyddiad, a rhaid trin rhestr y mae ei nextUpdate eisoes wedi mynd heibio fel un ar goll, ac nid fel un hen yn unig.

Cam 2: I ble mae’r dystysgrif yn cyfeirio’r cleient

Mae’r dystysgrif ddail fel rheol yn cario dau awgrym: estyniad pwynt dosbarthu CRL a chofnod mynediad gwybodaeth awdurdod ar gyfer OCSP. Mae openssl x509 -in client.pem -noout -ext crlDistributionPoints yn argraffu’r cyntaf, ac mae’r ail yn eistedd o dan adran AIA openssl x509 -in client.pem -noout -text. Mae’r naill estyniad neu’r llall yn bwyntiwr, nid yn rhwymedigaeth. Bydd cleient na fydd byth yn gweithredu gwiriad dirymu yn cysylltu’n berffaith dda â thystysgrif y mae ei hestyniadau’n enwi ymatebydd sydd wedi bod yn farw ers blwyddyn.

Mae pwyntiau dosbarthu’n aml yn enwi gwesteiwr mewnol sy’n datrys y tu mewn i un segment rhwydwaith yn unig, ac mae rhai cleientiaid hŷn yn gwrthod URLau ldap yn llwyr. Profwch gyrhaeddiad o’r gwesteiwr sy’n terfynu’r twnnel, nid o’ch gliniadur eich hun, oherwydd dyma’r unig safbwynt y mae ei fethiant yn wirioneddol o bwys.

Cam 3: Dewiswch fail-closed neu fail-open cyn y methiant

Mae ymatebydd ansymudol neu restr sydd wedi dod i ben yn gorfodi penderfyniad: gwrthod y cysylltiad, neu ei dderbyn a chofnodi’r bwlch. Mae isorchymyn verify OpenSSL yn gwneud y dewis llym yn eglur, oherwydd mae ychwanegu -crl_check yn troi CRL sydd ddim ar gael yn unable to get certificate CRL ac yn ddilysiad wedi methu. Nid yw methiant meddal yn y rhan fwyaf o staciau yn faner o gwbl, sef absenoldeb y gwiriad, a dyna’n union pam mae’n cyrraedd drwy ddamwain.

I weld pa ymddygiad sydd gan gleient mewn gwirionedd, tynnwch yr ymatebydd i ffwrdd ac ailgysylltu. Os bydd y twnnel yn dal i godi, dewch o hyd i’r llinell log a gofnododd y gwiriad a hepgorwyd, yna gofynnwch a fyddai unrhyw un yn darllen y llinell honno yn ystod digwyddiad. Gall yr un gwerthwr fod yn wahanol fesul protocol, gyda chleient IKEv2 a chleient OpenVPN ar un peiriant yn darllen nodau ffurfweddu heb berthynas.

Cam 4: Profwch fod y gwiriad yn rhedeg lle y derbynnir traffig

Dewch o hyd i’r broses sy’n terfynu neu’n awdurdodi’r cysylltiad, yna gofynnwch iddi am y llinell ffurfweddu sy’n galluogi gwiriad dirymu. Mae porth sy’n dilysu’r gadwyn ond byth yn gofyn am ddirymu yn gorfodi polisi gwahanol i’r un yn eich dogfennaeth, ac nid oes sgrinlun o gadwyn tystysgrifau yn profi’r gwrthwyneb. Mae OpenVPN yn sillafu’r opsiwn fel crl-verify; mae strongSwan yn cadw chwiliadau CRL ac OCSP o dan ffurfweddiad y CA, lle mae crl_uris neu ocsp_uris yn cael eu gosod. Os na allwch gyfeirio at y naill na’r llall, tybiwch fod y gwiriad yn absennol.

Nid yw ymateb OCSP yn cyfrif ond pan fydd y CA sy’n ei gyhoeddi wedi’i lofnodi, neu pan fydd ymatebydd sy’n dal y defnydd allweddol estynedig OCSPSigning a ddirprwywyd gan y CA hwnnw wedi’i lofnodi, felly nid yw ateb gan wasanaeth heb berthynas yn profi dim. Os ydych chi’n rhedeg yr ymatebydd eich hun, monitro ef fel dibyniaeth galed, oherwydd mae un gwasanaeth marw yn dod yn fethiant i bob cleient fail-closed ar unwaith.

Cam 5: Dirymwch un dystysgrif yn fwriadol

Cymerwch dystysgrif brawf, ei dirymu drwy’r un sianel ag y mae cynhyrchu’n ei defnyddio, a gofyn i’r ymatebydd yn uniongyrchol. Dylai openssl ocsp -issuer ca.pem -cert old.pem -url http://ocsp.example.net -resp_text adrodd Cert Status: revoked ynghyd ag amser dirymu, ac mae ateb good yn golygu na chyrhaeddodd eich dirymiad yr ymatebydd y mae eich cleientiaid yn gofyn iddo. Yna rhedeg openssl verify -crl_check -CRLfile issuer.crl -CAfile ca.pem old.pem i weld yr un penderfyniad drwy lwybr y rhestr. Darllenwch y llinyn rheswm yn hytrach na’r cod allanfa, oherwydd mae gwrthodiad dirymu a gwall cadwyn ill dau’n gorffen mewn methiant.

Y cam sy’n wirioneddol bwysig yw’r olaf: ailgysylltu â’r hen broffil yn erbyn y pwynt gorfodi go iawn a chadarnhau bod y gwrthodiad yn dod o ddirymu. Yna ailgysylltwch â thystysgrif newydd, ddilys i brofi nad ydych wedi torri’r gwrandawr yn unig. Nid yw dileu’r proffil ar y cleient yn profi dim am benderfyniad y gweinydd, nac ychwaith rhedeg openssl verify yn llwyddiannus ar beiriant nad yw byth yn terfynu twnnel. Mae RFC 6960 yn diffinio beth sydd mewn ymateb OCSP cydymffurfiol, gan gynnwys y gwerthoedd statws y mae’r prawf hwn yn eu darllen.