OpenVPN bez klientského certifikátu: politika servera, nie profil

Vymažete riadky s certifikátom a kľúčom, odovzdáte profil a pripojenie stále zlyháva s chybou certifikátu. Profil nikdy nebol tým, čo túto požiadavku vynucovalo. O tom, či je klientsky certifikát povinný, rozhoduje server a žiadna úprava na strane klienta to nevyjedná. Oprava je teda zmena serverovej politiky, vykonaná zámerne, so všetkým, čo od nej závisí, aktualizovaným v tom istom kroku.

Profil nie je politika

Community OpenVPN 2.6 prichádza s povinnými klientskymi certifikátmi, pretože verify-client-cert má predvolene hodnotu require. Nastavenie na none zastaví požiadavku na certifikát a odovzdá autentifikáciu klienta tomu usporiadaniu používateľského mena a hesla, ktoré server už prevádzkuje. Staršie príručky siahajú po client-cert-not-required, zastaranom pravopise tej istej myšlienky, preto použite direktívu, ktorú dokumentuje vaša nainštalovaná verzia. V každom prípade sa zmena deje na serveri a žiadny klientsky profil ju nemôže vykonať.

Nasledujúci fragment je celá zmena na strane servera a sám o sebe nie je funkčnou konfiguráciou autentifikácie. verify-client-cert none odstraňuje požiadavku na certifikát, kým username-as-common-name robí názov účtu identitou, ktorú vidia neskoršie spätné volania a súbory jednotlivých klientov. Ani jeden riadok nekontroluje heslo, takže verifikátor stále musí existovať.

verify-client-cert none
username-as-common-name

Tým verifikátorom je plugin alebo skript riadený auth-user-pass-verify a musí byť na mieste skôr, než ktorýkoľvek z vyššie uvedených riadkov niečo znamená. Opačné poradie vám dá okno, v ktorom server nechce certifikát a nekontroluje účet.

Čo server stále overuje

Zrušenie klientského certifikátu neznamená zrušenie TLS. Server si ponecháva svoj certifikát a kľúč a klient si ponecháva dôveru v CA a kontroly názvu hostiteľa, ktoré mu bránia hovoriť s podvodníkom. Odstránenie remote-cert-tls server alebo balíka CA preto, že klient už nemá certifikát, je časté a vážne nesprávne čítanie a referencia k 2.6 výslovne uvádza, že oba smery sú nezávislé. Jeden preukazuje server klientovi; druhý preukazuje klienta serveru.

Profil môže niesť aj blok tls-auth alebo tls-crypt. Je to zdieľaný kľúč riadiaceho kanála s vlastným cyklom distribúcie a rotácie, takže súbor bez riadkov s certifikátom alebo kľúčom nie je automaticky bezpečný na publikovanie. Považujte ho za tajomstvo, kým si ho neprečítate.

Súbor certifikátu skopírovaný z funkčného profilu sám o sebe nič nedokazuje; držba znamená mať súkromný kľúč, ktorý k nemu patrí, čo nasadenie overujúce certifikátom kontroluje. Súbor, ktorý obsahuje certifikát, nie je súbor, ktorým sa možno autentifikovať.

Čo musí verifikátor robiť

Po odstránení požiadavky na certifikát všetko stojí na verifikátore: plugine alebo skripte riadenom auth-user-pass-verify. Musí odmietať neplatné prihlasovacie údaje, odmietať zakázané alebo nespôsobilé účty a pri nedostupnosti backendu zlyhať zavreté. username-as-common-name sa často zapína popri tom a mení identitu, ktorú vidia neskoršie spätné volania a konfiguračné súbory jednotlivých klientov. Neoveruje heslo a nerobí nespôsobilý účet spôsobilým. To sú oddelené úlohy a ich miešanie je spôsob, akým migrácia prejde testom šťastnej cesty a zlyhá pri svojom prvom skutočnom incidente.

Testujte negatívne prípady rovnako starostlivo ako pozitívny. Profil, ktorý zobrazí výzvu na heslo, dokazuje len to, že klient vie vykresliť výzvu, kým server, ktorý prijme nesprávne heslo, dokazuje niečo podstatne horšie. Pridajte do testovacej sady zakázaný účet a prepadnuté prihlasovacie údaje, nielen zlé heslo.

Meňte politiku, profil a mapovanie spoločne

Zosúlaďte tri veci: direktívu servera, klientsky profil a mapovanie identity jednotlivých klientov. Zmeňte ich oddelene a klienti zlyhajú pred overením alebo sa pripoja pod menom, ktoré správca neočakával, čo je horšie, pretože to vyzerá ako úspech. Spojenie, ktoré uspeje pod nesprávnou identitou, sa odhalí ťažšie než to, ktoré zlyhá.

Pre túto cestu udržujte dva testovacie účty, jeden platný a jeden známy zlý, a po každej zmene verifikátora použite oba. Platný účet dokazuje šťastnú cestu a mapovanie identity; zlý dokazuje, že odmietanie stále funguje. Ani jeden test nič nehovorí o pravidlách spôsobilosti, preto pridajte účet, ktorý by mal byť odmietnutý z politických dôvodov, ak ich nasadenie má. Po každej zmene spustite všetky tri, pretože verifikátor, ktorý začne prijímať všetko, vyzerá presne ako fungujúce prihlásenie.

Zaznamenajte, ktoré metódy autentifikácie server skutočne prijíma, nie ktoré navrhuje profil. Tento záznam odpovedá na otázku, ktorú ľudia stále kladú, a to kto sa k tejto službe môže pripojiť. Prežije aj ďalšieho správcu, ktorý by ho inak znovu objavil zo zachytenia paketov.