OpenVPN bez klijentskog certifikata: poslužiteljska politika, a ne profil

Obrišete retke za certifikat i ključ, predate profil, a veza se i dalje prekida s pogreškom certifikata. Profil nikada nije bio ono što nameće taj zahtjev. Poslužitelj odlučuje je li klijentski certifikat obavezan, i nijedna izmjena na strani klijenta to ne pregovara. Dakle, popravak je promjena poslužiteljske politike, napravljena namjerno, uz ažuriranje svega što o njoj ovisi u istom prolazu.

Profil nije politika

Community OpenVPN 2.6 dolazi s obaveznim klijentskim certifikatima, jer verify-client-cert po defaultu ima vrijednost require. Postavljanje na none zaustavlja zahtjev za certifikatom i predaje autentikaciju klijenta onom rasporedu korisničkog imena i lozinke koji poslužitelj već koristi. Stariji vodiči posežu za client-cert-not-required, zastarjelim pravopisom iste ideje, pa koristite direktivu koju dokumentira vaša instalirana verzija. U svakom slučaju promjena se događa na poslužitelju i nijedan klijentski profil je ne može izvesti.

Fragment ispod je cijela promjena na strani poslužitelja i sam po sebi nije radna konfiguracija autentikacije. verify-client-cert none uklanja zahtjev za certifikatom, dok username-as-common-name čini ime računa identitetom koji vide kasniji povratni pozivi i datoteke pojedinačnog klijenta. Nijedan redak ne provjerava lozinku, pa verifikator i dalje mora postojati.

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

Taj verifikator je dodatak ili skripta koju pokreće auth-user-pass-verify i mora biti na mjestu prije nego ijedan od gornjih redaka išta znači. Obrnuti redoslijed daje vam prozor u kojem poslužitelj ne traži certifikat i ne provjerava račun.

Što još provjerava poslužitelj

Napuštanje klijentskog certifikata ne znači napuštanje TLS-a. Poslužitelj zadržava svoj certifikat i ključ, a klijent zadržava povjerenje u CA i provjere imena hosta koje ga sprječavaju da razgovara s prevarantom. Uklanjanje remote-cert-tls server ili CA paketa zato što klijent više nema certifikat često je i ozbiljno pogrešno čitanje, a referenca za 2.6 izričito kaže da su dva smjera neovisna. Jedan dokazuje poslužitelj klijentu; drugi dokazuje klijenta poslužitelju.

Profil može sadržavati i blok tls-auth ili tls-crypt. To je zajednički ključ kontrolnog kanala s vlastitim ciklusom distribucije i rotacije, pa datoteka bez redaka za certifikat ili ključ nije automatski sigurna za objavljivanje. Tretirajte je kao tajnu dok je ne pročitate.

Datoteka certifikata kopirana iz radnog profila sama po sebi ništa ne dokazuje; posjedovanje znači držanje privatnog ključa koji joj odgovara, što provjerava implementacija s autentikacijom po certifikatu. Datoteka koja sadrži certifikat nije datoteka kojom se može autentificirati.

Što verifikator mora raditi

Kad se zahtjev za certifikatom ukloni, sve počiva na verifikatoru: dodatku ili skripti koju pokreće auth-user-pass-verify. Mora odbijati nevažeće vjerodajnice, odbijati onemogućene ili nepodobne račune i zatvoreno se prekidati kad ne može dosegnuti svoj backend. username-as-common-name se često uključuje uz to i mijenja identitet koji vide kasniji povratni pozivi i konfiguracijske datoteke pojedinačnog klijenta. Ne provjerava lozinku i ne čini nepodoban račun podobnim. To su odvojeni poslovi, a njihovo miješanje je način na koji migracija prođe test sretnog puta i padne na prvom stvarnom incidentu.

Testirajte negativne slučajeve jednako pažljivo kao pozitivni. Profil koji prikazuje upit za lozinku dokazuje samo da klijent može nacrtati upit, dok poslužitelj koji prihvati pogrešnu lozinku dokazuje nešto znatno gore. Dodajte onemogućen račun i istekle vjerodajnice u testni skup, a ne samo lošu lozinku.

Mijenjajte politiku, profil i mapiranje zajedno

Uskladite tri stvari: poslužiteljsku direktivu, klijentski profil i mapiranje identiteta po klijentu. Mijenjajte ih odvojeno pa klijenti padnu prije verifikacije ili se povežu pod imenom koje administrator nije očekivao, što je gore jer izgleda kao uspjeh. Veza koja uspije pod pogrešnim identitetom teže se primjećuje od one koja padne.

Držite dva testna računa za taj put, jedan valjan i jedan poznato loš, i koristite oba nakon svake promjene verifikatora. Valjan račun dokazuje sretan put i mapiranje identiteta; loš dokazuje da odbijanje još radi. Nijedan test ne govori ništa o pravilima podobnosti, pa dodajte račun koji bi trebao biti odbijen iz političkih razloga ako ih implementacija ima. Pokrenite sva tri nakon svake promjene, jer verifikator koji počne prihvaćati sve izgleda točno kao radna prijava.

Zabilježite koje metode autentikacije poslužitelj zapravo prihvaća, a ne koje profil predlaže. Taj zapis odgovara na pitanje koje ljudi stalno postavljaju, a to je tko se može povezati na ovu uslugu. On nadživljava i sljedećeg administratora, koji bi ga inače ponovno otkrio iz snimanja paketa.