OCSP наспроти CRL: како навистина функционира секоја проверка за отповикување

Една од овие две проверки за отповикување враќа потпишан одговор за еден сертификат, а другата враќа потпишана листа што ја преземате цела. Двете треба да му кажат на проверувачот дали акредитивот е уште доверлив, и двете не успеваат на начини што воопшто не личат еден на друг. Редоследот подолу го следи она со што операторот навистина се среќава во продукција, почнувајќи од бајтите на мрежата и завршувајќи со порта што одбива врска. Прескокнувањето чекор е токму начинот на кој распоредувањето останува со политика за отповикување што постои само на хартија.

Чекор 1: Што враќа секоја проверка и колку долго останува употреблива

CRL се објавува како еден потпишан објект што го покрива секој сертификат што издавачот го отповикал, па проверувачот го зема еднаш и го користи повторно додека не помине nextUpdate на листата. Одговорот на OCSP е потесен: одговара точно за еден сертификат и носи thisUpdate, producedAt и обично и nextUpdate. Таа разлика управува со сите други. Кешираниот CRL тивко старее, бидејќи датотеката уште се парсира и нејзиниот потпис уште се проверува, додека истечениот одговор на OCSP е очигледно безвреден во моментот кога ќе ги прочитате неговите временски ознаки.

Затоа кеширањето е првото нешто што треба да се утврди: која компонента ја држи копијата и на кој горен лимит таа копија се покорува. На порта лимитот треба да биде nextUpdate минус безбедносна маржа, никогаш не она што случајно го предлага HTTP заглавието за кеш. openssl crl -in issuer.crl -noout -lastupdate -nextupdate ги печати двата датума, и листа чиј nextUpdate веќе е во минатото мора да се третира како отсутна, а не само како стара.

Чекор 2: Каде сертификатот го насочува клиентот

Листовиот сертификат обично носи два навестувања: продолжување на точката за дистрибуција на CRL и запис за пристап до информации на органот за OCSP. openssl x509 -in client.pem -noout -ext crlDistributionPoints го печати првото, а второто се наоѓа под делот AIA на openssl x509 -in client.pem -noout -text. Секое продолжување е показател, не обврска. Клиент што никогаш не имплементира проверка за отповикување совршено ќе се поврзе со сертификат чии продолжувања именуваат одговорник што е мртов веќе една година.

Точките за дистрибуција често именуваат внатрешен хост што се решава само во еден мрежен сегмент, а некои постари клиенти воопшто ги одбиваат ldap URL-адресите. Проверете ја достапноста од хостот што го завршува тунелот, не од сопствениот лаптоп, бидејќи тоа е единственото гледиште чиј неуспех навистина е важен.

Чекор 3: Изберете fail-closed или fail-open пред прекинот

Недостапен одговорник или истечена листа принудуваат одлука: одбијте ја врската, или прифатете ја и запишете го јазот. Подкомандата verify на OpenSSL го прави строгиот избор експлицитен, бидејќи додавањето -crl_check претвора недостапен CRL во unable to get certificate CRL и неуспешна проверка. Мекиот неуспех во повеќето стекови воопшто не е знаменце, туку отсуство на проверката, и токму затоа се испорачува случајно.

За да видите какво однесување навистина има клиентот, отстранете го одговорникот и поврзете се повторно. Ако тунелот уште се крева, пронајдете ја линијата во дневникот што ја запишала прескокнатата проверка, па прашајте дали некој би ја читал таа линија за време на инцидент. Истиот добавувач може да се разликува по протокол: клиент на IKEv2 и клиент на OpenVPN на иста машина читаат несродни конфигурациски параметри.

Чекор 4: Докажете дека проверката работи таму каде што сообраќајот се прифаќа

Пронајдете го процесот што ја завршува или авторизира врската, па прашајте го за конфигурациската линија што ја овозможува проверката за отповикување. Порта што го валидира синџирот, но никогаш не прашува за отповикување, применува поинаква политика од онаа во вашата документација, и ниту еден екрански снимак на синџир на сертификати не го докажува спротивното. OpenVPN ја пишува опцијата како crl-verify; strongSwan ги држи CRL и OCSP пребарувањата под конфигурацијата на CA, каде што се поставуваат crl_uris или ocsp_uris. Ако не можете да покажете на ниту едно од двете, претпоставете дека проверката отсутствува.

Одговорот на OCSP важи само кога издавачката CA го потпишала, или кога го потпишал одговорник што ја има проширената употреба на клучот OCSPSigning делегирана од таа CA, затоа одговор од неврзана услуга не докажува ништо. Ако сами го управувате одговорникот, надгледувајте го како цврста зависност, бидејќи една мртва услуга одеднаш станува прекин за секој fail-closed клиент.

Чекор 5: Намерно отповикајте еден сертификат

Земете тест сертификат, отповикајте го преку истиот канал што го користи продукцијата и прашајте го одговорникот директно. openssl ocsp -issuer ca.pem -cert old.pem -url http://ocsp.example.net -resp_text треба да пријави Cert Status: revoked заедно со време на отповикување, а одговор good значи дека вашето отповикување не стигнало до одговорникот што го прашуваат вашите клиенти. Потоа извршете openssl verify -crl_check -CRLfile issuer.crl -CAfile ca.pem old.pem за да ја видите истата одлука низ патеката на листата. Читајте ја низата со причина наместо излезниот код, бидејќи одбивањето поради отповикување и грешката во синџирот и двете завршуваат со неуспех.

Чекорот што навистина е важен е последниот: поврзете се повторно со стариот профил против вистинската точка на примена и потврдете дека одбивањето доаѓа од отповикување. Потоа поврзете се повторно со свеж, важечки сертификат за да докажете дека не сте само го расипале слушателот. Бришењето на профилот на клиентот не докажува ништо за одлуката на серверот, а ниту успешното извршување на openssl verify на машина што никогаш не завршува тунел. RFC 6960 дефинира што содржи соодветен одговор на OCSP, вклучувајќи ги вредностите на статусот што ги чита овој тест.