Certificados de VPN de curta duração

Um cliente VPN confia no servidor com que conecta via certificado. Esse certificado prova que o servidor é quem diz ser. Se o certificado é comprometido — tirado dum laptop roubado, vazado de backup, exfiltrado dum bucket S3 mal configurado — um atacante pode se passar pelo servidor. Até alguém revogar manualmente aquele certificado, todo cliente que conectar leva man-in-the-middle sem aviso.

A maioria das VPNs consumidor emite certificados válidos por meses. Algumas emitem por anos. O Fexyn emite por 24 horas. Esse post explica por que esse é o número certo.

O problema de revogação de certificado de que ninguém fala

A resposta padrão pra "e se um cert vazar" é "a gente revoga." O mecanismo é Certificate Revocation List (CRL) ou seu primo moderno OCSP (Online Certificate Status Protocol). O cliente checa o CRL, vê que o cert foi revogado, recusa confiar.

Na prática, ambos os mecanismos não são confiáveis.

CRLs são lentos pra propagar. A PKI publica um novo CRL num cronograma — tipicamente horário ou diário. Clientes cacham o CRL entre checagens. Entre revogação e propagação, todo cliente lá fora ainda confia no cert revogado.

CRLs são grandes. Uma PKI de longa duração acumula revogações. O CRL cresce sem limite até um certificado expirar. CRLs de vários megabytes são comuns. Clientes que baixam o CRL completo a cada conexão ficam mais lentos conforme a PKI envelhece. Clientes que não fazem isso ficam pra trás no status de revogação.

OCSP deveria consertar isso fazendo checagens de revogação real-time por cert em vez de batched por CRL. Na prática, OCSP responders caem. Quando o responder está inalcançável, clientes enfrentam uma escolha: fail closed (bloquear a conexão) ou fail open (confiar no cert mesmo assim). A maioria fail open, porque fail closed quebra a experiência de usuário sempre que o OCSP responder soluça. Então na prática, OCSP também não pega revogações de forma confiável.

Navegadores eventualmente desistiram. Chrome parou de fazer OCSP por padrão em 2012. Firefox seguiu. Eles migraram pra CRLSets e CRLite — subconjuntos curados de revogações empurradas em updates de navegador. Melhor, mas especificamente pra navegadores, não pra VPNs.

Pra uma PKI de VPN: se seu cert vazar e você revogar, espere que todo cliente atualize seu CRL antes do atacante usar. Espere que não fail open durante outage transitório de OCSP. Espere que nada deu errado na janela.

Certificados de curta duração escapam do problema

O insight do Let's Encrypt: se certificados expiram rápido o bastante, você não precisa revogar. O cert se foi antes que importe.

Let's Encrypt emite certificados de 90 dias. O ecossistema da web reconstruiu sua automação em torno daquela restrição. ACME, certbot, renovação automática — tudo isso existe porque alguém decidiu que 90 dias era curto o bastante pra revogação virar nota de rodapé em vez de feature.

Pra uma PKI de VPN você pode ir mais curto. O trade-off:

Certs longos (meses a anos): baixa carga operacional, blast radius terrível se comprometido.
Certs curtos (horas): carga operacional maior, blast radius baixo.

24 horas é o sweet spot pra clientes VPN. Longo o bastante pra que um único ciclo sleep/resume não dispare renovação. Curto o bastante pra que um credential roubado expire antes que a maioria dos atacantes consiga fazer algo com ele.

Como o Fexyn implementa

O Fexyn roda um HashiCorp Vault PKI como emissor de certificado. A configuração:

Root CA offline, mantido em hardware tokens. Fora de alcance de qualquer comprometimento da infra rodando.
Intermediate CA online, assina certificados de servidor e cliente.
TTL de cert de cliente: 24 horas.
TTL de cert de servidor: 24 horas, rotacionado automaticamente.

O fluxo quando você conecta:

O cliente Fexyn autentica na API com suas credenciais de conta.
A API requisita um certificado fresco do Vault pro seu cliente.
Vault assina um novo certificado, válido por 24 horas.
O cliente usa aquele cert pro túnel VPN.
O cert expira. Próxima conexão dispara emissão fresca.

O cert nunca fica em disco mais que sua duração. Não tem segredo de longa duração no seu laptop que precise sobreviver entre sessões.

Modelos de ameaça que isso aborda

Laptop roubado. Um ladrão tem janela de 24 horas pra se passar por você na VPN antes do cert morrer. Comparado com cert de longa duração que seria válido por meses: melhoria dramática.

Apreensão de fronteira. Cruzando fronteiras com laptop, qualquer lugar onde alfândega tem autoridade expansiva de apreensão. Se imagearem seu disco ou puxarem credentials, esses credentials expiram no dia seguinte. Você não precisa se desesperar pra revogar; o sistema lida via expiração.

Backup comprometido. Se seu backup for roubado e o atacante extrair o credential VPN, mesma história. O atacante tem horas, não meses.

Infra comprometida. Se um servidor Fexyn for comprometido de uma forma que expõe seu certificado, o impacto é limitado pela duração restante do cert. A gente rotaciona certs de servidor diariamente; o pior caso é janela de 24 horas onde um servidor malicioso poderia ser personificado. A gente parea isso com certificate pinning no lado do cliente, que pega a personificação antes que importe.

O que isso não é

Certs de curta duração não são substituto pra:

Auth de conta forte. Se sua senha for phishada e o atacante logar na sua conta Fexyn, ele pega certificados frescos da API. A duração do cert não ajuda. Use gerenciador de senhas e ative MFA.
Segurança de endpoint. Um laptop comprometido pode ser backdoored pra silenciosamente exfiltrar todo cert no momento que é emitido. A PKI não conserta isso.
Comprometimento a nível de rede fora do túnel. Se seu provedor está fazendo TLS interception com a CA dele pré-confiada na sua máquina, isso é ataque diferente e a PKI da VPN está abaixo do nível onde pode ajudar.

A PKI limita um modo de falha específico: credentials vazados ficam úteis indefinidamente. É melhoria significativa, não defesa completa.

Por que nenhuma outra VPN consumidor faz isso

Não é tecnicamente difícil. Vault PKI é open-source. Automação estilo ACME é bem documentada. A razão de a maioria dos provedores de VPN ficar com certs de longa duração é operacional:

Certs de longa duração significam menos carga na infra de PKI.
Significam que clientes podem conectar mesmo se a PKI estiver brevemente inalcançável.
Significam menos tickets de suporte de "minha VPN não conecta" causados por renovação mal feita.

Essas são preocupações reais. Resolvê-las requer construir o fluxo de renovação no cliente até ficar invisível. Isso é trabalho de engenharia que o time de VPN comum não prioriza porque o marketing copy não vende em higiene de PKI.

O Fexyn priorizou porque é diferença de segurança significativa pra usuários em posições de risco mais alto: jornalistas, ativistas, trabalhadores remotos lidando com dados sensíveis.

Leitura relacionada

Experimente o Fexyn grátis por 7 dias — seu primeiro cert é 24 horas, e você não precisa pensar nele.