OpenVPN username-as-common-name: per què la vostra comprovació de CN surt buida
Un script client-connect que compara common_name amb username pot comparar un nom amb si mateix. Vinculeu el certificat al compte abans que s’executi la substitució.
Afegiu un client-connect que rebutja qualsevol connexió en què common_name difereix de username, i sembla una vinculació entre un certificat i un compte. En un servidor amb username-as-common-name activat, aquesta comparació ja ha perdut el sentit quan l’script s’executa. Tots dos valors són la mateixa cadena, de manera que la prova passa per a un certificat emès a una altra persona.
La comprovació no és incorrecta perquè l’script estigui mal escrit. És incorrecta perquè el valor que llegeix es va substituir abans en la mateixa connexió.
Què sembla demostrar la comparació
L’autenticació per certificat i l’autenticació per contrasenya són proves separades, i un servidor pot exigir les dues sense exigir que pertanyin a la mateixa persona. La diferència és real: un certificat de dispositiu vàlid més qualsevol compte vàlid és una afirmació diferent d’aquell certificat més un compte concret. Un script que compara common_name amb username es llegeix com l’enllaç que falta entre tots dos. Ho seria, si common_name encara volgués dir el que deia el certificat.
Si ho és o no depèn d’una opció del servidor, i aquesta opció normalment s’activa per un motiu no relacionat, com ara fer més fàcil posar nom als fitxers de configuració per usuari.
Què fa username-as-common-name amb el nom
Amb username-as-common-name activat, OpenVPN substitueix el nom comú del certificat pel nom d’usuari autenticat un cop s’han verificat el nom d’usuari i la contrasenya. El ganxo de verificació que s’executa durant aquesta comprovació encara rep el nom comú del certificat, perquè la substitució encara no ha passat. Tot el que ve després, client-connect inclòs, veu el nom d’usuari. Per tant, la crida posterior rep una identitat dues vegades i no la pot comparar amb el certificat que s’havia presentat.
| 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 |
Seguiu una connexió il·lustrativa: un certificat emès per a bob-device, un inici de sessió correcte al directori com a alice i l’opció activada. L’etapa de verificació encara pot veure dues cadenes diferents. L’etapa de connexió veu alice i alice.
Aquest exemple mostra per què la comparació és buida. No mostra que la connexió s’acceptaria d’una altra manera, perquè la validació del certificat i la verificació de la contrasenya encara es fan pel seu compte.
Poseu la vinculació on totes dues identitats encara existeixin
La regla s’ha d’aplicar en una etapa que vegi la identitat del certificat i el compte alhora, cosa que a la pràctica vol dir el ganxo de verificació del nom d’usuari i la contrasenya o un connector carregat allà. Un connector compatible que ja faci la verificació de la contrasenya sol ser el lloc adequat per afegir una regla d’aparellament, perquè substituir-lo per una comparació de noms eliminaria del tot la comprovació de la contrasenya.
Definiu el mapatge abans d’escriure codi, perquè la igualtat poques vegades és la política real. Un certificat sovint identifica un dispositiu mentre que l’inici de sessió identifica una persona, i un dispositiu pot servir legítimament diverses persones. Guardeu la relació en una forma l’emissió de la qual controleu, i decidiu què passa en canviar el nom, en reemetre i amb noms qualificats per domini. Passar a minúscules o eliminar un prefix de domini sense entendre el directori pot fusionar dos comptes que havien de romandre separats.
Recordeu que l’opció també canvia quina configuració per client s’aplica, perquè client-config-dir s’indexa pel nom comú.
Proveu l’aparellament amb dues credencials vàlides
Comenceu amb la parella que la vostra política permet i confirmeu que es connecta. Després presenteu el mateix certificat vàlid amb un compte diferent però vàlid d’altra manera: aquest intent ha de fallar, i ha de fallar per la regla d’aparellament, no per una contrasenya mal escrita. Una contrasenya incorrecta demostra que la comprovació de la contrasenya funciona i no diu res sobre la regla de certificat a compte.
Comproveu també els camins del certificat absent i del certificat no vàlid, i confirmeu quina identitat fa servir el servidor per a la configuració per client. Si l’única manera de fer funcionar la comparació és desactivar username-as-common-name, calculeu primer el cost d’aquest canvi, perquè torna la cerca de configuració de cada client al nom del certificat.