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, включително стойностите на статуса, които този тест чете.