OpenVPN username-as-common-name: kodėl jūsų CN patikra tuščia
client-connect scenarijus, kuris lygina common_name su username, gali palyginti vardą su juo pačiu. Susiekite sertifikatą su paskyra prieš atliekant pakeitimą.
Pridedate client-connect scenarijų, kuris atmeta kiekvieną ryšį, kuriame common_name skiriasi nuo username, ir tai atrodo kaip sertifikato susiejimas su paskyra. Serveryje, kuriame veikia username-as-common-name, tas palyginimas jau prarado prasmę iki scenarijaus paleidimo. Abi reikšmės yra ta pati eilutė, todėl testas praeina ir sertifikatui, išduotam visiškai kitam asmeniui.
Patikra nėra klaidinga todėl, kad scenarijus blogai parašytas. Ji klaidinga todėl, kad jos skaitoma reikšmė tame pačiame ryšyje buvo pakeista anksčiau.
Ką palyginimas tarsi įrodo
Sertifikato autentifikavimas ir slaptažodžio autentifikavimas yra atskiri įrodymai, ir serveris gali reikalauti abiejų nereikalaudamas, kad jie priklausytų tam pačiam asmeniui. Spraga tikra: galiojantis įrenginio sertifikatas su bet kokia galiojančia paskyra yra kitas teiginys nei tas pats sertifikatas su viena įvardyta paskyra. Scenarijus, lyginantis common_name su username, skaitomas kaip trūkstama grandis tarp jų. Taip ir būtų, jei common_name vis dar reikštų tai, ką sakė sertifikatas.
Ar taip yra, priklauso nuo vienos serverio parinkties, ir ta parinktis paprastai įjungiama dėl nesusijusios priežasties, pavyzdžiui, kad kiekvieno naudotojo konfigūracijos failus būtų lengviau pavadinti.
Ką username-as-common-name daro vardui
Kai username-as-common-name įjungta, OpenVPN patikrinus naudotojo vardą ir slaptažodį pakeičia sertifikato bendrą vardą autentifikuotu naudotojo vardu. To patikrinimo metu veikiantis patikros kabliukas vis dar gauna sertifikato bendrą vardą, nes pakeitimas dar neįvyko. Viskas po to, įskaitant client-connect, mato naudotojo vardą. Todėl vėlesnis atgalinis iškvietimas gauna vieną tapatybę du kartus ir negali jos palyginti su pateiktu sertifikatu.
| Stage | What common_name holds |
|---|---|
| Username and password verification hook | The certificate common name, for example bob-device |
| After the replacement | The authenticated account, alice |
| client-connect callback | The account again, alice |
Sekite vieną iliustracinį ryšį: sertifikatas, išduotas bob-device, sėkmingas prisijungimas prie katalogo kaip alice, ir parinktis įjungta. Patikros etapas vis dar gali matyti dvi skirtingas eilutes. Prisijungimo etapas mato alice ir alice.
Šis pavyzdys parodo, kodėl palyginimas tuščias. Jis neparodo, kad ryšys kitaip būtų priimtas, nes sertifikato patikra ir slaptažodžio tikrinimas vis dar veikia savarankiškai.
Įdėkite susiejimą ten, kur abi tapatybės dar egzistuoja
Taisyklė turi būti įgyvendinama etape, kuris vienu metu mato sertifikato tapatybę ir paskyrą, o praktiškai tai reiškia naudotojo vardo ir slaptažodžio patikros kabliuką arba ten įkeltą papildinį. Palaikomas papildinys, kuris jau atlieka slaptažodžio tikrinimą, paprastai yra tinkama vieta poravimo taisyklei pridėti, nes jį pakeitus vardų palyginimu slaptažodžio patikra būtų visiškai prarasta.
Apibrėžkite susiejimą prieš rašydami kodą, nes lygybė retai būna tikroji politika. Sertifikatas dažnai identifikuoja įrenginį, o prisijungimas – asmenį, ir vienas įrenginys gali teisėtai aptarnauti kelis žmones. Saugokite ryšį tokia forma, kurios išdavimą kontroliuojate, ir nuspręskite, kas nutinka pervadinant, išduodant iš naujo ir su domenu kvalifikuotais vardais. Mažųjų raidžių naudojimas ar domeno priešdėlio pašalinimas nesuprantant katalogo gali sujungti dvi paskyras, kurios turėjo likti atskiros.
Nepamirškite, kad parinktis taip pat keičia, kuri konfigūracija kiekvienam klientui taikoma, nes client-config-dir susietas su bendru vardu.
Išbandykite poravimą su dviem galiojančiais prisijungimo duomenimis
Pradėkite nuo poros, kurią leidžia jūsų politika, ir patvirtinkite, kad ji prisijungia. Tada pateikite tą patį galiojantį sertifikatą su kita, bet kitaip galiojančia paskyra: tas bandymas turi nepavykti, ir jis turi nepavykti dėl poravimo taisyklės, o ne dėl neteisingai įvesto slaptažodžio. Neteisingas slaptažodis įrodo, kad slaptažodžio patikra veikia, ir nieko nesako apie sertifikato ir paskyros taisyklę.
Patikrinkite ir kelius be sertifikato bei su negaliojančiu sertifikatu ir patvirtinkite, kokią tapatybę serveris naudoja kiekvieno kliento nustatymams. Jei vienintelis būdas, kad palyginimas veiktų, yra išjungti username-as-common-name, pirmiausia įvertinkite to pakeitimo kainą, nes jis visų klientų konfigūracijos paiešką grąžina prie sertifikato vardo.