OCSP vai CRL: miten kukin mitätöintitarkistus todella toimii

Toinen näistä kahdesta mitätöintitarkistuksesta palauttaa allekirjoitetun vastauksen yhdestä varmenteesta, ja toinen palauttaa allekirjoitetun luettelon, jonka lataat kokonaan. Molempien on kerrottava tarkistajalle, onko valtuutus edelleen luotettava, ja molemmat epäonnistuvat tavoilla, jotka eivät muistuta toisiaan lainkaan. Alla oleva järjestys seuraa sitä, mitä operaattori todella kohtaa tuotannossa, alkaen johdossa kulkevista tavuista ja päättyen yhdyskäytävään, joka hylkää yhteyden. Askelman väliin jättäminen on juuri se tapa, jolla käyttöönotto päätyy mitätöintikäytäntöön, joka on olemassa vain paperilla.

Vaihe 1: Mitä kukin tarkistus palauttaa ja kuinka kauan se pysyy käyttökelpoisena

CRL julkaistaan yhtenä allekirjoitettuna objektina, joka kattaa jokaisen varmenteen, jonka myöntäjä on mitätöinyt, joten tarkistaja noutaa sen kerran ja käyttää sitä uudelleen, kunnes luettelon nextUpdate on ohitettu. OCSP-vastaus on kapeampi: se vastaa täsmälleen yhdestä varmenteesta ja kantaa thisUpdate-, producedAt- ja yleensä myös nextUpdate-tiedot. Tämä ero ohjaa kaikkea muuta. Välimuistiin tallennettu CRL vanhenee hiljaa, koska tiedosto yhä jäsennetään ja sen allekirjoitus yhä varmennetaan, kun taas vanhentunut OCSP-vastaus on selvästi arvoton heti, kun luet sen aikaleimat.

Siksi välimuisti on ensimmäinen asia, joka on lyötävä lukkoon: mikä komponentti pitää kopiota ja mitä ylärajaa se kopio noudattaa. Yhdyskäytävässä ylärajan tulisi olla nextUpdate miinus turvamarginaali, ei koskaan se, mitä HTTP-välimuistin otsake sattuu ehdottamaan. openssl crl -in issuer.crl -noout -lastupdate -nextupdate tulostaa molemmat päivämäärät, ja luetteloa, jonka nextUpdate on jo menneisyydessä, on kohdeltava puuttuvana eikä vain vanhana.

Vaihe 2: Mihin varmenne ohjaa asiakkaan

Lehtivarmenne kantaa yleensä kaksi vihjettä: CRL-jakelupisteen laajennuksen ja OCSP:tä varten olevan viranomaistietojen käyttöoikeuden merkinnän. openssl x509 -in client.pem -noout -ext crlDistributionPoints tulostaa ensimmäisen, ja toinen on openssl x509 -in client.pem -noout -text-tulosteen AIA-osiossa. Kumpikin laajennus on osoitin, ei velvoite. Asiakas, joka ei koskaan toteuta mitätöintitarkistusta, yhdistyy täysin hyvin varmenteeseen, jonka laajennukset nimeävät vastaajan, joka on ollut kuolleena jo vuoden.

Jakelupisteet nimeävät usein sisäisen isännän, joka ratkeaa vain yhden verkkosegmentin sisällä, ja jotkin vanhemmat asiakkaat hylkäävät ldap-URL-osoitteet kokonaan. Testaa tavoitettavuus isännästä, joka päättää tunnelin, älä omasta kannettavastasi, sillä se on ainoa näkökulma, jonka epäonnistumisella todella on merkitystä.

Vaihe 3: Valitse fail-closed tai fail-open ennen katkoa

Tavoittamaton vastaaja tai vanhentunut luettelo pakottaa päätökseen: hylkää yhteys tai hyväksy se ja kirjaa aukko. OpenSSL:n verify-alikomento tekee tiukasta valinnasta eksplisiittisen, koska -crl_check:n lisääminen muuttaa käyttämättömissä olevan CRL:n unable to get certificate CRL:ksi ja epäonnistuneeksi varmennukseksi. Pehmeä epäonnistuminen ei useimmissa pinoissa ole lainkaan lippu, vaan tarkistuksen puuttuminen, ja juuri siksi se päätyy tuotantoon vahingossa.

Nähdäksesi, millainen käyttäytyminen asiakkaalla todella on, poista vastaaja ja yhdistä uudelleen. Jos tunneli nousee silti, etsi lokirivi, joka kirjasi ohitetun tarkistuksen, ja kysy sitten, lukisiko joku sitä riviä tapahtuman aikana. Sama toimittaja voi vaihdella protokollittain: IKEv2-asiakas ja OpenVPN-asiakas samalla koneella lukevat toisiinsa liittymättömiä asetusnuppeja.

Vaihe 4: Todista, että tarkistus toimii siellä, missä liikenne hyväksytään

Etsi prosessi, joka päättää tai valtuuttaa yhteyden, ja kysy siltä asetusriviä, joka ottaa mitätöintitarkistuksen käyttöön. Yhdyskäytävä, joka validoi ketjun mutta ei koskaan kysy mitätöinnistä, soveltaa eri käytäntöä kuin dokumentaatiossasi oleva, eikä mikään varmenneketjun kuvakaappaus todista päinvastaista. OpenVPN kirjoittaa valinnan muodossa crl-verify; strongSwan pitää CRL- ja OCSP-haut CA-asetusten alla, jossa crl_uris tai ocsp_uris asetetaan. Jos et voi osoittaa kumpaakaan, oleta, että tarkistus puuttuu.

OCSP-vastaus on pätevä vain, kun myöntävä CA on allekirjoittanut sen, tai kun sen on allekirjoittanut vastaaja, jolla on kyseisen CA:n delegoima OCSPSigning-laajennettu avaimenkäyttö, joten asiaan liittymättömän palvelun vastaus ei todista mitään. Jos ajat vastaajaa itse, valvo sitä kovana riippuvuutena, sillä yksi kuollut palvelu muuttuu kerralla katkoksi jokaiselle fail-closed-asiakkaalle.

Vaihe 5: Mitätöi yksi varmenne tarkoituksella

Ota testivarmenne, mitätöi se samaa kanavaa pitkin, jota tuotanto käyttää, ja kysy vastaajalta suoraan. openssl ocsp -issuer ca.pem -cert old.pem -url http://ocsp.example.net -resp_text:n pitäisi raportoida Cert Status: revoked yhdessä mitätöintiajan kanssa, ja vastaus good tarkoittaa, että mitätöintisi ei saavuttanut vastaajaa, jolta asiakkaasi kysyvät. Aja sitten openssl verify -crl_check -CRLfile issuer.crl -CAfile ca.pem old.pem nähdäksesi saman päätöksen luetteloreittiä pitkin. Lue syymerkkijono poistumiskoodin sijaan, sillä mitätöinnin hylkäys ja ketjuvirhe päättyvät molemmat epäonnistumiseen.

Vaihe, jolla todella on merkitystä, on viimeinen: yhdistä uudelleen vanhalla profiililla todellista valvontapistettä vasten ja varmista, että hylkäys tulee mitätöinnistä. Yhdistä sitten uudelleen tuoreella, kelvollisella varmenteella todistaaksesi, ettei kuuntelijaa vain rikottu. Profiilin poistaminen asiakkaalta ei todista mitään palvelimen päätöksestä, eikä sitä tee onnistunut openssl verify:n ajo koneella, joka ei koskaan päätä tunnelia. RFC 6960 määrittelee, mitä yhdenmukainen OCSP-vastaus sisältää, mukaan lukien ne tilan arvot, jotka tämä testi lukee.