OCSP prieš CRL: kaip iš tikrųjų veikia kiekviena atšaukimo patikra

Viena iš šių dviejų atšaukimo patikrų grąžina pasirašytą atsakymą apie vieną sertifikatą, o kita – pasirašytą sąrašą, kurį atsisiunčiate visą. Abi turi pasakyti tikrintojui, ar kredencialas vis dar patikimas, ir abi nepavyksta taip, kad visai nepanašu viena į kitą. Toliau pateikta tvarka atitinka tai, su kuo operatorius iš tikrųjų susiduria gamyboje: nuo baitų tinkle iki šliuzo, atsisakančio jungties. Praleidus žingsnį, diegimas lieka su atšaukimo politika, kuri egzistuoja tik popieriuje.

1 žingsnis: ką grąžina kiekviena patikra ir kiek laiko ji lieka naudojama

CRL skelbiamas kaip vienas pasirašytas objektas, apimantis kiekvieną sertifikatą, kurį išdavėjas atšaukė, todėl tikrintojas jį paima vieną kartą ir naudoja pakartotinai, kol praeina sąrašo nextUpdate. OCSP atsakymas siauresnis: jis atsako tiksliai apie vieną sertifikatą ir neša thisUpdate, producedAt bei paprastai ir nextUpdate. Šis skirtumas lemia visa kita. Podėlyje laikomas CRL tyliai sensta, nes failas vis dar analizuojamas, o jo parašas vis dar tikrinamas, tuo tarpu pasibaigęs OCSP atsakymas akivaizdžiai bevertis tą akimirką, kai perskaitote jo laiko žymes.

Todėl podėliavimas yra pirmas dalykas, kurį reikia nustatyti: kuris komponentas laiko kopiją ir kokią viršutinę ribą ta kopija paklūsta. Šliuze riba turėtų būti nextUpdate atėmus saugos atsargą, niekada ne tai, ką atsitiktinai siūlo HTTP podėlio antraštė. openssl crl -in issuer.crl -noout -lastupdate -nextupdate išspausdina abi datas, ir sąrašas, kurio nextUpdate jau praeityje, turi būti traktuojamas kaip trūkstamas, o ne tik senas.

2 žingsnis: kur sertifikatas nukreipia klientą

Lapo sertifikatas paprastai turi dvi užuominas: CRL paskirstymo taško plėtinį ir institucijos informacijos prieigos įrašą OCSP. openssl x509 -in client.pem -noout -ext crlDistributionPoints išspausdina pirmąjį, o antrasis yra openssl x509 -in client.pem -noout -text išvesties AIA skirsnyje. Bet kuris plėtinys yra rodyklė, o ne prievolė. Klientas, kuris niekada neįgyvendina atšaukimo patikros, puikiai prisijungs prie sertifikato, kurio plėtiniai nurodo responderį, jau metus esantį mirusį.

Paskirstymo taškai dažnai nurodo vidinį hostą, kuris išsprendžiamas tik viename tinklo segmente, o kai kurie senesni klientai ldap URL atsisako visiškai. Pasiekiamumą tikrinkite iš hosto, kuris užbaigia tunelį, o ne iš savo nešiojamojo kompiuterio, nes tai vienintelis požiūris, kurio gedimas iš tikrųjų svarbus.

3 žingsnis: prieš sutrikimą pasirinkite fail-closed arba fail-open

Nepasiekiamas responderis arba pasibaigęs sąrašas verčia nuspręsti: atmesti jungtį arba ją priimti ir užfiksuoti spragą. OpenSSL verify papildoma komanda padaro griežtą pasirinkimą aiškų, nes pridėjus -crl_check neprieinamas CRL virsta unable to get certificate CRL ir nepavykusia patikra. Švelnus gedimas daugumoje rinkinių apskritai nėra vėliavėlė, o patikros nebuvimas, ir būtent todėl jis išleidžiamas netyčia.

Norėdami pamatyti, kokios elgsenos klientas iš tikrųjų turi, pašalinkite responderį ir prisijunkite iš naujo. Jei tunelis vis tiek pakyla, suraskite žurnalo eilutę, kurioje užfiksuota praleista patikra, ir paklauskite, ar kas nors tą eilutę skaitytų incidento metu. Tas pats tiekėjas gali skirtis pagal protokolą: IKEv2 klientas ir OpenVPN klientas tame pačiame kompiuteryje skaito nesusijusius konfigūracijos parametrus.

4 žingsnis: įrodykite, kad patikra vyksta ten, kur srautas priimamas

Raskite procesą, kuris užbaigia arba įgalioja jungtį, ir paklauskite jo apie konfigūracijos eilutę, kuri įjungia atšaukimo patikrą. Šliuzas, kuris tikrina grandinę, bet niekada neklausia apie atšaukimą, taiko kitokią politiką nei jūsų dokumentacijoje, ir jokia sertifikatų grandinės ekrano kopija neįrodo priešingai. OpenVPN tą parinktį rašo kaip crl-verify; strongSwan laiko CRL ir OCSP užklausas CA konfigūracijoje, kur nustatomi crl_uris arba ocsp_uris. Jei negalite nurodyti nė vieno, darykite prielaidą, kad patikros nėra.

OCSP atsakymas galioja tik tada, kai jį pasirašė išduodanti CA, arba kai jį pasirašė responderis, turintis šios CA deleguotą išplėstinį rakto naudojimą OCSPSigning, todėl nesusijusios paslaugos atsakymas nieko neįrodo. Jei responderį valdote patys, stebėkite jį kaip griežtą priklausomybę, nes viena mirusi paslauga vienu metu tampa sutrikimu kiekvienam fail-closed klientui.

5 žingsnis: tyčia atšaukite vieną sertifikatą

Paimkite bandomąjį sertifikatą, atšaukite jį tuo pačiu kanalu, kurį naudoja gamyba, ir paklauskite responderio tiesiogiai. openssl ocsp -issuer ca.pem -cert old.pem -url http://ocsp.example.net -resp_text turėtų pranešti Cert Status: revoked kartu su atšaukimo laiku, o atsakymas good reiškia, kad jūsų atšaukimas nepasiekė responderio, kurio klausia jūsų klientai. Tada paleiskite openssl verify -crl_check -CRLfile issuer.crl -CAfile ca.pem old.pem, kad pamatytumėte tą patį sprendimą sąrašo keliu. Skaitykite priežasties eilutę, o ne išėjimo kodą, nes atšaukimo atmetimas ir grandinės klaida abu baigiasi nesėkme.

Žingsnis, kuris tikrai svarbus, yra paskutinis: prisijunkite iš naujo su senuoju profiliu prie tikrojo vykdymo taško ir patvirtinkite, kad atmetimas kyla iš atšaukimo. Tada vėl prisijunkite su nauju, galiojančiu sertifikatu, kad įrodytumėte, jog ne tik sulaužėte klausytoją. Profilio ištrynimas kliente nieko neįrodo apie serverio sprendimą, ir to nepadaro sėkmingas openssl verify paleidimas kompiuteryje, kuris niekada neužbaigia tunelio. RFC 6960 apibrėžia, ką turi atitinkantis OCSP atsakymas, įskaitant būsenos reikšmes, kurias skaito šis testas.