OpenVPN username-as-common-name: zašto je tvoja provjera CN prazna

Dodaješ skriptu client-connect koja odbija svaku vezu u kojoj se common_name razlikuje od username, i to izgleda kao veza između sertifikata i naloga. Na serveru koji pokreće username-as-common-name, to poređenje je već izgubilo smisao dok se skripta pokrene. Obe vrednosti su isti niz znakova, pa test prolazi za sertifikat izdat sasvim drugoj osobi.

Provjera nije pogrešna zato što je skripta loše napisana. Pogrešna je zato što je vrednost koju čita zamenjena ranije u istoj vezi.

Šta poređenje kao da dokazuje

Autentikacija sertifikatom i autentikacija lozinkom su odvojeni dokazi, a server može zahtevati oboje bez zahteva da pripadaju istoj osobi. Razlika je stvarna: važeći sertifikat uređaja plus bilo koji važeći nalog drugačiji je zahtev od tog sertifikata plus jednog imenovanog naloga. Skripta koja poredi common_name sa username čita se kao karika koja nedostaje između njih. Bila bi to, kad bi common_name još značilo ono što je sertifikat rekao.

Da li je tako zavisi od jedne opcije servera, a ta opcija se obično uključuje zbog nepovezanog razloga, na primer da se konfiguracione datoteke po korisniku lakše imenuju.

Šta username-as-common-name čini sa imenom

Sa uključenim username-as-common-name, OpenVPN zamenjuje uobičajeno ime sertifikata autentifikovanim korisničkim imenom nakon što se korisničko ime i lozinka provjere. Kuka za provjeru koja se izvršava tokom te provjere još uvek prima uobičajeno ime sertifikata, jer se zamena još nije dogodila. Sve nakon toga, uključujući client-connect, vidi korisničko ime. Zato kasniji povratni poziv prima jedan identitet dva puta i ne može ga uporediti sa predstavljenim sertifikatom.

Prati jednu ilustrativnu vezu: sertifikat izdat za bob-device, uspešna prijava u imenik kao alice i uključena opcija. Faza provjere još može videti dva različita niza znakova. Faza povezivanja vidi alice i alice.

Taj primer pokazuje zašto je poređenje prazno. Ne pokazuje da bi veza inače bila prihvaćena, jer provjera sertifikata i provjera lozinke i dalje rade same.

Postavi vezu tamo gde oba identiteta još postoje

Pravilo se mora sprovoditi u fazi koja vidi identitet sertifikata i nalog istovremeno, što u praksi znači kuku za provjeru korisničkog imena i lozinke ili tamo učitani dodatak. Podržani dodatak koji već obavlja provjeru lozinke obično je pravo mesto za dodavanje pravila uparivanja, jer bi njegova zamena poređenjem imena u potpunosti uklonila provjeru lozinke.

Definiši mapiranje pre pisanja koda, jer jednakost retko je stvarna politika. Sertifikat često identifikuje uređaj, dok prijava identifikuje osobu, a jedan uređaj može legitimno služiti više ljudi. Sačuvaj odnos u obliku čije izdavanje kontrolišeš i odluči šta se dešava pri preimenovanju, ponovnom izdavanju i kod imena sa kvalifikacijom domena. Pretvaranje u mala slova ili uklanjanje prefiksa domena bez razumevanja imenika može spojiti dva naloga koja su trebala ostati odvojena.

Imaj na umu da opcija takođe menja koja se konfiguracija po klijentu primenjuje, jer je client-config-dir vezan za uobičajeno ime.

Testiraj uparivanje sa dva važeća pristupna podatka

Počni sa parom koji tvoja politika dozvoljava i potvrdi da se povezuje. Zatim predstavi isti važeći sertifikat sa drugim, ali inače važećim nalogom: taj pokušaj mora propasti, i mora propasti zbog pravila uparivanja, a ne zbog pogrešno upisane lozinke. Pogrešna lozinka dokazuje da provjera lozinke radi i ne govori ništa o pravilu između sertifikata i naloga.

Provjeri i putanje bez sertifikata i sa nevažećim sertifikatom, i potvrdi koji identitet server koristi za postavke po klijentu. Ako je jedini način da poređenje radi isključivanje username-as-common-name, prvo proceni cenu te promene, jer ona vraća traženje konfiguracije svakog klijenta na ime sertifikata.