OpenVPN username-as-common-name: miks teie CN-kontroll on tühi

Lisate client-connect skripti, mis keeldub igast ühendusest, kus common_name erineb username-st, ja see näeb välja nagu sertifikaadi ja konto vaheline side. Serveris, kus töötab username-as-common-name, on see võrdlus skripti käivitumise ajaks juba oma tähenduse kaotanud. Mõlemad väärtused on sama string, seega test läbib sertifikaadi puhul, mis on väljastatud hoopis teisele inimesele.

Kontroll ei ole vale sellepärast, et skript on halvasti kirjutatud. See on vale sellepärast, et väärtus, mida see loeb, asendati samas ühenduses varem.

Mida võrdlus justkui tõestab

Sertifikaadi autentimine ja parooli autentimine on eraldi tõendid ning server võib nõuda mõlemat, nõudmata, et need kuuluksid samale inimesele. Vahe on tõeline: kehtiv seadme sertifikaat pluss ükskõik milline kehtiv konto on teine väide kui sama seadme sertifikaat pluss üks nimetatud konto. Skript, mis võrdleb common_name username-ga, kõlab nende kahe vahelise puuduva lülina. Ja olekski, kui common_name tähendaks endiselt seda, mida sertifikaat ütles.

Kas see nii on, sõltub ühest serveri valikust ja see valik lülitatakse tavaliselt sisse mitteseotud põhjusel, näiteks selleks, et kasutajapõhiseid konfiguratsioonifaile oleks lihtsam nimetada.

Mida username-as-common-name nimega teeb

Kui username-as-common-name on lubatud, asendab OpenVPN sertifikaadi üldnime autenditud kasutajanimega, kui kasutajanimi ja parool on kontrollitud. Selle kontrolli ajal töötav kontrollkonks saab endiselt sertifikaadi üldnime, sest asendus ei ole veel toimunud. Kõik edasine, sealhulgas client-connect, näeb kasutajanime. Seega saab hilisem tagasikutse ühe identiteedi kaks korda ega saa seda esitatud sertifikaadiga võrrelda.

Jälgige üht näidisühendust: bob-device jaoks väljastatud sertifikaat, edukas kataloogi sisselogimine alice-na ja valik on lubatud. Kontrollietapp võib endiselt näha kahte erinevat stringi. Ühendusetapp näeb alice ja alice.

See näide näitab, miks võrdlus on tühi. See ei näita, et ühendus muidu vastu võetaks, sest sertifikaadi valideerimine ja parooli kontrollimine töötavad endiselt iseseisvalt.

Pange side sinna, kus mõlemad identiteedid veel eksisteerivad

Reeglit tuleb rakendada etapis, mis näeb sertifikaadi identiteeti ja kontot korraga, mis praktikas tähendab kasutajanime ja parooli kontrollkonksu või sinna laaditud pistikprogrammi. Toetatud pistikprogramm, mis juba teeb parooli kontrolli, on tavaliselt õige koht paaritamisreegli lisamiseks, sest selle asendamine nime võrdlemisega jätaks parooli kontrolli täielikult välja.

Määratlege vastendus enne koodi kirjutamist, sest võrdsus on harva tegelik poliitika. Sertifikaat tuvastab sageli seadme, samal ajal kui sisselogimine tuvastab inimese, ja üks seade võib seaduslikult teenindada mitut inimest. Hoidke seost kujul, mille väljastamist te kontrollite, ja otsustage, mis juhtub ümbernimetamisel, uuesti väljastamisel ja domeeniga kvalifitseeritud nimede puhul. Domeeniprefiksi väiketähtedeks muutmine või eemaldamine ilma kataloogist aru saamata võib liita kaks kontot, mis pidid jääma eraldi.

Pidage meeles, et valik muudab ka seda, milline kliendipõhine konfiguratsioon kehtib, sest client-config-dir võtmetakse üldnime järgi.

Testige paaritamist kahe kehtiva mandaadiga

Alustage paarist, mille teie poliitika lubab, ja kinnitage, et see ühendub. Seejärel esitage sama kehtiv sertifikaat teistsuguse, kuid muidu kehtiva kontoga: see katse peab ebaõnnestuma ja peab ebaõnnestuma paaritamisreegli tõttu, mitte valesti trükitud parooli tõttu. Vale parool tõestab, et parooli kontroll töötab, ega ütle midagi sertifikaadi ja konto reegli kohta.

Kontrollige ka puuduva ja kehtetu sertifikaadi radu ning kinnitage, millist identiteeti server kliendipõhiste seadete jaoks kasutab. Kui ainus viis võrdlus tööle saada on username-as-common-name keelamine, hinnake esmalt selle muudatuse hinda, sest see viib iga kliendi konfiguratsiooniotsingu tagasi sertifikaadi nime juurde.