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 одговор, укључујући вредности статуса које овај тест чита.