OpenVPN tls-crypt-v2: qué hacen la clave del cliente y el blob envuelto
Un perfil tls-crypt-v2 guarda una clave de control del cliente y una copia envuelta que solo el servidor puede abrir. Mantenga cada objeto, y cada paso de retirada, por separado.
Pegar un perfil tls-crypt-v2 en un ticket parece inofensivo hasta que se cuenta lo que contiene el archivo. La clave del canal de control del cliente está junto a una copia cifrada de esa misma clave, y un tercer objeto, la clave de envoltura, nunca sale del servidor que acepta. Esos tres responden a preguntas distintas sobre custodia, compartición y retirada. Separarlos resuelve la mayoría de las discusiones de política antes de que empiecen.
Qué contiene realmente el perfil
La mitad del cliente de tls-crypt-v2 es una clave más una copia envuelta de ella. El cliente usa la clave simple para proteger el canal de control y entrega la copia envuelta al servidor durante la configuración, de modo que el servidor recupera la misma clave sin guardar una copia en texto plano por cliente. La clave de envoltura hace posible esa recuperación y pertenece solo al lado que acepta. Todo lo que sigue se deriva de dónde viven esos tres objetos.
| 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 |
Lea la tabla por custodia y no por nombre, y las consecuencias salen solas. Perder la clave de envoltura es el suceso caro, porque nada en un perfil puede reconstruirla y la recuperación honesta es reemitir el grupo. Un perfil filtrado es más barato pero mucho más común, porque los perfiles se pegan en tickets por gente que cree que la copia envuelta hace que el archivo sea seguro para compartir. Los dos fallos necesitan respuestas distintas, y esa es la razón de mantener los objetos separados.
Por qué la copia envuelta no es toda la historia
Un perfil lleva el material de cliente utilizable junto con su contraparte envuelta, así que proteger la copia para el servidor no dice nada sobre proteger el archivo. El blob es seguro de transmitir e inseguro de publicar. Los metadatos que contiene son visibles para quien reciba el blob, incluido quien más tarde lea el ticket en el que se pegó.
Trate un perfil como una credencial y no como una muestra de configuración. Un archivo filtrado da a su poseedor una identidad de cliente operativa hasta que el servidor deje de aceptar esa identidad, y la envoltura no hace nada respecto de esa ventana. Emita un perfil por cliente para que la retirada siga siendo una decisión de un solo archivo, y haga copia de seguridad de la clave de envoltura separada de la configuración del servidor que habilita. Ninguno de los dos hábitos repara un perfil comprometido, pero ambos deciden con qué rapidez se contendrá el siguiente.
Dónde se sitúa el hook de verificación en el saludo
El hook de verificación se ejecuta antes de que se exponga la pila TLS, y su tarea es inspeccionar los metadatos que lleva el blob envuelto. Recibe esos metadatos más un entorno pequeño y documentado, y tiene menos con lo que trabajar que un hook de autenticación. Suponer que ve nombres de usuario, estado de sesión o variables de complementos es la forma habitual de escribir mal este hook. Lea la sección propia del manual del hook en lugar de tomar prestadas expectativas de otro hook.
Su estado de salida es la decisión: un resultado distinto de cero rechaza al cliente y un resultado cero permite que el saludo continúe. Por eso la política debe decir qué pasa cuando faltan los metadatos, no se pueden analizar o son inesperados. Escriba primero la ruta de rechazo y después decida qué valores son aceptables.
tls-crypt-v2 /etc/openvpn/server/tcv2-server.key
tls-crypt-v2-verify /etc/openvpn/server/verify-client-metadata.shEsas dos líneas son la superficie de política en el servidor: una nombra la clave de envoltura y la otra nombra el programa que juzga a cada cliente. Todo lo interesante vive en el script, que merece control de versiones y la misma revisión que cualquier otra regla de acceso.
Cuenta, certificado y clave de control se retiran por separado
La aceptación temprana del canal de control no es autenticación, porque ocurre antes de la comprobación de identidad TLS y antes de cualquier autorización de cuenta. Desactivar una cuenta, revocar un certificado y rechazar una clave de control de cliente son tres acciones con tres mecanismos. Un despliegue que ejecuta solo una de ellas tiene un hueco y no una política. Reconcilie las tres a propósito y registre qué paso ejerce qué autoridad.
El momento es la segunda distinción. Una lista de aceptación cambiada se aplica a los saludos nuevos, mientras que las sesiones ya establecidas siguen hasta que algo las termina. Contar entradas de la lista nueva como prueba de que las sesiones antiguas acabaron es cómo un cliente eliminado sigue conectado durante horas.
Las autoridades no reconciliadas dejan dos agujeros fáciles de encontrar en la práctica. Una cuenta puede desactivarse mientras su clave de control todavía abre un saludo, y un certificado puede revocarse mientras la política de metadatos todavía admite al mismo cliente. Ambos son el mismo error en lugares distintos, porque un operador trató una lista como toda la autoridad. Ponga las tres listas una al lado de otra en el momento de la eliminación y el error se hace visible.
Emitir y retirar un perfil
Emitir es la mitad fácil: cree la clave del cliente en el lado que acepta, entregue el perfil a exactamente un propietario, mantenga restringido el material de envoltura y ejecute el mismo programa de verificación en cada servidor que acepta. La admisión barata es una propiedad de todo el grupo, no del host más nuevo. Un segundo servidor con un script más antiguo o más laxo se convierte en silencio en la ruta más débil del despliegue.
La retirada necesita los tres pasos en un orden deliberado. Deniegue el cliente en el hook de verificación para que fallen los saludos nuevos, revoque su certificado si se usa una PKI y desactive la cuenta para que la autorización posterior no tenga nada que autorizar. Después termine las sesiones que permitía la aceptación antigua, ya que no notarán ninguna de las tres. Ensaye la secuencia con un cliente que pueda permitirse romper.
Los metadatos de un perfil son una entrada para esa política, no una prueba de que el control de acceso ya exista. El documento de diseño de OpenVPN 2.6 describe los objetos y la frontera que trazan, mientras que aplicarla sigue siendo cosa del operador.