Certificados VPN de corta duración

Un cliente VPN confía en el servidor al que se conecta vía un certificado firmado por una autoridad certificadora. Ese certificado prueba que el servidor es quien dice ser. Si el certificado se compromete (tomado de una laptop robada, filtrado de un backup, exfiltrado de un bucket S3 mal configurado), un atacante puede impersonar el servidor. Hasta que alguien manualmente revoque ese certificado, cada cliente que se conecte recibe un man-in-the-middle sin advertencia.

La mayoría de las VPNs de consumo emiten certificados válidos por meses. Algunas las emiten por años. Fexyn las emite por 24 horas desde una public key infrastructure respaldada por Vault. Acá por qué ese es el número correcto.

El problema de revocación de certificados del que nadie habla

La respuesta estándar a "¿qué pasa si un cert se filtra?" es "lo revocamos." El mecanismo es una Certificate Revocation List (CRL) o su primo moderno OCSP (Online Certificate Status Protocol). El cliente chequea la CRL, ve que el cert está revocado, rehúsa confiar en él.

En la práctica, ambos mecanismos no son confiables.

Las CRLs son lentas para propagar. El PKI publica una nueva CRL en un schedule, típicamente cada hora o diariamente. Los clientes cachean la CRL entre chequeos. Entre la revocación y la propagación, cada cliente allá afuera todavía confía en el cert revocado.

Las CRLs son grandes. Un PKI de larga vida acumula revocaciones. La CRL crece sin límite hasta que un certificado caduca. CRLs de varios megabytes son comunes. Los clientes que descargan la CRL completa en cada conexión se ralentizan a medida que el PKI envejece. Los clientes que no la descargan se atrasan en estatus de revocación.

OCSP supuestamente arregla esto haciendo chequeos de revocación en tiempo real por-cert en lugar de en lote por-CRL. En la práctica, los responders OCSP se caen. Cuando el responder no es alcanzable, los clientes enfrentan una elección: fallar cerrado (bloquear la conexión) o fallar abierto (confiar en el cert igual). La mayoría falla abierto, porque fallar cerrado rompe la experiencia de usuario cada vez que el responder OCSP hipea. Así que en la práctica, OCSP no atrapa revocaciones de manera confiable tampoco.

Los navegadores eventualmente se rindieron. Chrome dejó de hacer OCSP por defecto en 2012. Firefox siguió. Se movieron a CRLSets y CRLite (subsets curados de revocaciones empujados en updates del navegador). Mejor, pero específicamente para navegadores, no VPNs.

Para un PKI VPN: si tu cert se filtra y lo revocás, esperá que cada cliente refresque su CRL antes de que el atacante lo use. Esperá que no fallen abierto durante un outage transitorio de OCSP. Esperá que nada haya salido mal en el gap.

Los certificados de corta duración esquivan el problema

La perspicacia de Let's Encrypt: si los certificados expiran lo suficientemente rápido, no necesitás revocarlos. El cert se va antes de que importe.

Let's Encrypt emite certificados de 90 días. El ecosistema web reconstruyó su automatización alrededor de esa restricción. ACME, certbot, renovación automática: todo eso existe porque alguien decidió que 90 días era lo suficientemente corto como para que la revocación se volviera una nota al pie en lugar de una feature.

Para un PKI VPN podés ir más corto. El trade-off:

Certs largos (meses a años): baja carga operacional, terrible blast radius si se compromete.
Certs cortos (horas): mayor carga operacional, bajo blast radius.

24 horas es el sweet spot para clientes VPN. Lo suficientemente largo para que un solo ciclo de sleep/resume no dispare renovación. Lo suficientemente corto para que una credencial robada expire antes de que la mayoría de los atacantes pueda hacer algo con ella.

Cómo Fexyn lo implementa

Fexyn corre un PKI HashiCorp Vault como emisor de certificados. La configuración:

Root CA offline, mantenido en tokens de hardware. Fuera del alcance de cualquier compromiso de la infraestructura corriendo.
Intermediate CA online, firma certificados de servidor y cliente.
TTL de cert de cliente: 24 horas.
TTL de cert de servidor: 24 horas, rotado automáticamente.

El flujo cuando te conectás:

El cliente Fexyn se autentica al API con tus credenciales de cuenta.
El API solicita un certificado fresco de Vault para tu cliente.
Vault firma un nuevo certificado, válido por 24 horas.
El cliente usa ese cert para el túnel VPN.
El cert expira. La próxima conexión dispara una emisión fresca.

El cert nunca se sienta en disco más tiempo que su lifetime. No hay un secreto de larga duración en tu laptop que necesite sobrevivir entre sesiones.

Modelos de amenaza que esto aborda

Laptop robada. Un ladrón tiene una ventana de 24 horas para impersonarte en la VPN antes de que el cert muera. Comparado con un cert de larga duración que sería válido por meses: mejora dramática.

Incautación en frontera. Cruzando fronteras con una laptop, en cualquier lugar donde aduana tiene autoridad expansiva de incautación. Si imagen tu disco o sacan credenciales, esas credenciales expiran al día siguiente. No necesitás scramblear para revocar; el sistema lo maneja por envejecimiento.

Backup comprometido. Si tu backup se roba y el atacante extrae la credencial VPN, misma historia. El atacante tiene horas, no meses.

Infraestructura comprometida. Si un servidor Fexyn se compromete de una forma que expone su certificado, el impacto está limitado por el lifetime restante del cert. Rotamos certs de servidor diariamente; el peor caso es una ventana de 24 horas donde un servidor malicioso podría ser impersonado. Pareamos esto con pinning de certificados del lado del cliente, lo que atrapa la impersonación antes de que importe.

Lo que esto no es

Los certs de corta duración no son sustituto de:

Auth de cuenta fuerte. Si tu password se phisha y el atacante se loguea en tu cuenta de Fexyn, obtienen certificados frescos del API. El lifetime del cert no ayuda. Usá un password manager y habilitá MFA.
Seguridad del endpoint. Una laptop comprometida puede backdoorearse para silenciosamente exfiltrar cada cert el momento que se emite. El PKI no arregla eso.
Compromiso a nivel red fuera del túnel. Si tu ISP está haciendo intercepción TLS con su CA pre-confiada en tu máquina, ese es un ataque distinto y el PKI VPN está debajo del nivel donde puede ayudar.

El PKI limita un modo de falla específico: credenciales filtradas siendo útiles indefinidamente. Es una mejora significativa, no una defensa completa.

Por qué ninguna otra VPN de consumo hace esto

No es técnicamente difícil. Vault PKI es open-source. La automatización estilo ACME está bien documentada. La razón por la que la mayoría de los proveedores VPN se quedan con certs de larga duración es operacional:

Los certs de larga duración significan menos carga en la infraestructura PKI.
Significan que los clientes pueden conectarse aunque el PKI sea brevemente inalcanzable.
Significan menos tickets de soporte de "mi VPN no se conecta" causados por una renovación malcocida.

Estas son preocupaciones reales. Resolverlas requiere construir el flujo de renovación dentro del cliente hasta que sea invisible. Ese es trabajo de ingeniería que el equipo VPN promedio no prioriza porque la copia de marketing no vende sobre higiene de PKI.

Fexyn lo priorizó porque es una diferencia de seguridad significativa para usuarios en posiciones de riesgo más alto: periodistas, activistas, trabajadores remotos manejando datos sensibles.

Relacionados

Probá Fexyn gratis 7 días. Tu primer cert es válido por 24 horas, y no tenés que pensar en él.