OpenVPN tls-crypt-v2: que fan a clave do cliente e o blob envolto
Un perfil tls-crypt-v2 contén unha clave de control do cliente e unha copia envolta que só o servidor pode abrir. Mantén cada obxecto e cada paso de retirada por separado.
Pegar un perfil tls-crypt-v2 nunha incidencia parece inofensivo ata que contas o que contén o ficheiro. A clave da canle de control do cliente está xunto a unha copia cifrada desa mesma clave, e un terceiro obxecto, a clave de envoltura, nunca sae do servidor que acepta. Eses tres responden a preguntas distintas sobre custodia, compartición e retirada. Separaos e a maioría das discusións de política resólvense antes de comezar.
Que contén realmente o perfil
A metade do cliente de tls-crypt-v2 é unha clave máis unha copia envolta dela. O cliente usa a clave simple para protexer a canle de control e entrega a copia envolta ao servidor durante a configuración, de xeito que o servidor recupera a mesma clave sen gardar unha copia en texto claro por cliente. A clave de envoltura fai posible esa recuperación e pertence só ao lado que acepta. Todo o seguinte deriva de onde viven eses tres obxectos.
| Object | Where it lives | What can open it | What a leak costs |
|---|---|---|---|
| Server wrapping key | accepting servers only | the unwrap step inside the server | every wrapped copy issued to that group becomes readable |
| Wrapped client key | inside the client profile | the server wrapping key | it names a client and exposes its metadata, but not the key inside |
| Client control key | inside the client profile, usable as-is | the client that owns it | someone can open handshakes as that client until the server refuses the key |
Le a táboa por custodia en vez de por nome e as consecuencias sáenche soas. Perder a clave de envoltura é o acontecemento caro, porque nada nun perfil pode reconstruíla e a recuperación honesta é volver emitir o grupo. Un perfil filtrado é máis barato pero moito máis común, xa que os perfís péganse en incidencias por xente que cre que a copia envolta fai que o ficheiro sexa seguro para compartir. Os dous fallos necesitan respostas distintas, e por iso os obxectos mantéñense á parte.
Por que a copia envolta non é toda a historia
Un perfil leva o material utilizable do cliente xunto coa súa contraparte envolta, así que protexer a copia para o servidor non di nada sobre protexer o ficheiro. O blob é seguro de transmitir e inseguro de publicar. Os metadatos que contén son visibles para quen reciba o blob, incluído calquera que despois lea a incidencia na que se pegou.
Trata un perfil como unha credencial e non como un exemplo de configuración. Un ficheiro filtrado dálle ao seu portador unha identidade de cliente operativa ata que o servidor deixe de aceptar esa identidade, e a envoltura non fai nada respecto desa xanela. Emite un perfil por cliente para que a retirada siga sendo unha decisión dun só ficheiro, e fai copia de seguridade da clave de envoltura á parte da configuración do servidor que habilita. Ningún dos dous hábitos repara un perfil comprometido, pero ambos deciden con que rapidez se contén o seguinte.
Onde se sitúa o gancho de verificación na negociación
O gancho de verificación execútase antes de expoñer a pila TLS, e o seu traballo é inspeccionar os metadatos que leva o blob envolto. Recibe eses metadatos máis unha contorna pequena e documentada, e ten menos con que traballar que un gancho de autenticación. Supoñer que pode ver nomes de usuario, estado de sesión ou variables de complementos é a forma habitual de escribir mal este gancho. Le a propia sección do manual do gancho en vez de tomar prestadas expectativas doutro gancho.
O seu estado de saída é a decisión: un resultado distinto de cero rexeita o cliente e un resultado cero deixa continuar a negociación. A política ten que dicir, por tanto, que acontece cando faltan metadatos, non se poden analizar ou son inesperados. Escribe primeiro o camiño de rexeitamento e despois decide que valores son aceptables.
tls-crypt-v2 /etc/openvpn/server/tcv2-server.key
tls-crypt-v2-verify /etc/openvpn/server/verify-client-metadata.shEses dúas liñas son a superficie de política no servidor: unha nomea a clave de envoltura, a outra nomea o programa que xulga cada cliente. Todo o interesante vive no script, que merece control de versións e a mesma revisión que calquera outra regra de acceso.
Conta, certificado e clave de control retíranse por separado
A aceptación temperá da canle de control non é autenticación, porque ocorre antes da comprobación da identidade TLS e antes de calquera autorización de conta. Desactivar unha conta, revogar un certificado e rexeitar unha clave de control do cliente son tres accións con tres mecanismos. Unha implantación que só fai unha delas ten un oco en vez dunha política. Concilia as tres a propósito e rexistra que paso exerce que autoridade.
O momento é a segunda distinción. Unha lista de aceptación modificada aplícase aos novos handshakes, mentres que as sesións xa establecidas seguen funcionando ata que algo as remata. Contar entradas na nova lista como proba de que as sesións antigas remataron é como un cliente retirado segue conectado durante horas.
As autoridades non conciliadas deixan dous buratos fáciles de atopar na práctica. Pódese desactivar unha conta mentres a súa clave de control aínda abre un handshake, e pódese revogar un certificado mentres a política de metadatos aínda admite o mesmo cliente. Ambos son o mesmo erro en lugares distintos, porque un operador tratou unha soa lista como toda a autoridade. Pon as tres listas unha xunto á outra no momento da retirada e o erro faise visible.
Emitir e retirar un perfil
Emitir é a metade fácil: crea a clave do cliente no lado que acepta, entrega o perfil a exactamente un propietario, mantén o material de envoltura restrinxido e executa o mesmo programa de verificación en cada servidor que acepta. A admisión barata é unha propiedade do grupo enteiro, non do host máis novo. Un segundo servidor cun script máis antigo ou máis laxo convértese silenciosamente no camiño máis feble da implantación.
A retirada necesita os tres pasos nunha orde deliberada. Denega o cliente no gancho de verificación para que fallen os novos handshakes, revoga o seu certificado se se usa unha PKI e desactiva a conta para que a autorización posterior non teña nada que autorizar. Despois remata as sesións que permitía a aceptación antiga, xa que non notarán ningunha das tres. Ensaya a secuencia nun cliente que poidas permitirche romper.
Os metadatos dun perfil son unha entrada para esa política, non a proba de que xa existe control de acceso. O documento de deseño de OpenVPN 2.6 describe os obxectos e a fronteira que trazan, mentres que aplicalos segue sendo responsabilidade do operador.