Criptografia — TLS, Certificados, SSH

1. Contexto histórico e normativo

A criptografia moderna remonta à Segunda Guerra Mundial (máquina Enigma e os trabalhos de Alan Turing) e ao advento da criptografia de chave pública nos anos 1970, com os trabalhos de Diffie-Hellman (1976), RSA (Rivest, Shamir, Adleman, 1977) e ECC (Elliptic Curve Cryptography, Miller/Koblitz, 1985).

Os protocolos que usamos hoje são padronizados por organismos internacionais:

• NIST — padroniza curvas elípticas (P-256, P-384) e algoritmos de hash (SHA-2, SHA-3).
• IETF — RFCs de TLS (RFC 8446 para TLS 1.3), SSH (RFC 4251-4254) e DNSSEC (RFC 4033-4035).
• ANSSI/BASI — agências europeias que emitem recomendações sobre algoritmos.

Para ISPs, a criptografia é essencial não apenas para proteger o acesso administrativo (SSH), mas também para garantir a confidencialidade e integridade dos dados dos clientes — exigência explícita da LGPD (Art. 46).

2. Simétrica vs. assimétrica

Criptografia simétrica usa a mesma chave para cifrar e decifrar — rápida, mas exige que as duas partes compartilhem a chave com segurança antes (problema de distribuição). Criptografia assimétrica usa um par de chaves (pública/privada) — o que uma cifra, só a outra decifra, resolvendo o problema de distribuição, mas com custo computacional maior.

Na prática, quase todo protocolo moderno (TLS, SSH) usa os dois juntos: assimétrica para negociar/trocar uma chave de sessão com segurança, e simétrica para cifrar o volume real de dados depois — o melhor dos dois mundos.

3. Curvas elípticas e forward secrecy

A criptografia de curvas elípticas (ECC) oferece o mesmo nível de segurança que o RSA com chaves muito menores — uma chave ECC de 256 bits é equivalente a uma RSA de 3072 bits. Isso significa menor overhead de processamento e menos dados trafegados.

Forward secrecy (sigilo futuro) é a propriedade de que, mesmo que uma chave privada de longo prazo seja comprometida, o tráfego passado continua seguro. Isso é obtido usando trocas de chave efêmeras (Diffie-Hellman Efêmero — DHE ou ECDHE), que geram uma chave de sessão única que nunca é armazenada após a conexão terminar.

4. TLS — handshake resumido

Ao conectar num servidor com TLS: o servidor apresenta seu certificado (contém a chave pública, assinado por uma Autoridade Certificadora confiável); o cliente valida essa assinatura contra uma lista de CAs em que já confia (embutida no sistema operacional/navegador); os dois lados negociam uma chave de sessão simétrica através de troca assimétrica; a partir daí, todo o tráfego real é cifrado simetricamente, muito mais rápido. Certificado expirado ou emitido por CA não confiável quebra esse processo — daí o aviso de "conexão não segura" no navegador.

5. Certificado gratuito automatizado — Let's Encrypt

apt install certbot python3-certbot-nginx   # ou python3-certbot-apache

certbot --nginx -d painel.exemplo-isp.com.br

# Renovação automática — certbot já instala o timer/cron pra isso,
# mas vale confirmar
certbot renew --dry-run
systemctl status certbot.timer

Certificado Let's Encrypt tem validade curta (dias) por padrão, especificamente para forçar automação — se sua renovação não está automatizada, o certificado vai expirar, é questão de quando, não de se.

6. CA própria para serviços internos

Para serviço que nunca será acessado pela internet pública (ex: painel interno de gerência), Let's Encrypt não se aplica (exige validação de domínio público). Solução: CA própria, mesma ferramenta já vista na página de OpenVPN:

easyrsa init-pki
easyrsa build-ca nopass
easyrsa gen-req painel-interno nopass
easyrsa sign-req server painel-interno

# Certificado da CA precisa ser distribuído/instalado como confiável
# em cada máquina que vai acessar o serviço interno

7. Chaves SSH — geração e boas práticas

# Ed25519 — algoritmo moderno recomendado, mais rápido e chave menor
# que RSA equivalente em segurança
ssh-keygen -t ed25519 -C "tecnico-joao@isp"

# Copiar chave pública pro servidor
ssh-copy-id -i ~/.ssh/id_ed25519.pub tecnico-joao@10.0.0.5

Chave privada nunca sai da máquina do usuário — o que se distribui é sempre só a chave pública. Proteger a chave privada com passphrase adiciona uma camada extra caso o notebook do técnico seja roubado/comprometido.

8. Aplicações adicionais — LUKS, hashing de senhas

8.1 Criptografia de disco — LUKS

Para servidores que armazenam dados sensíveis (ex.: banco de dados do RADIUS), a criptografia de disco é uma camada adicional contra acesso físico não autorizado:

# Criptografar partição com LUKS (durante instalação ou particionamento)
cryptsetup luksFormat /dev/sdb1
cryptsetup open /dev/sdb1 dados-cifrados
mkfs.ext4 /dev/mapper/dados-cifrados
mount /dev/mapper/dados-cifrados /var/lib/mysql

8.2 Hashing de senhas

Nunca armazene senhas em texto puro. Use algoritmos de hash adequados para senhas:

• bcrypt — algoritmo clássico, com custo ajustável.
• argon2 — vencedor da Password Hashing Competition (2015), recomendado atualmente.
• scrypt — resistente a hardware especializado.
• Evite: MD5, SHA1 (sem salt), SHA256 puro para senhas.

No contexto do FreeRADIUS, a senha de autenticação PPPoE frequentemente precisa estar em texto puro ou em formato específico (ex.: Cleartext-Password para CHAP/MSCHAP). Nesses casos, restrinja ao máximo o acesso ao banco de dados.

9. Verificação de certificado

# Validade e cadeia de um certificado remoto
echo | openssl s_client -connect painel.exemplo-isp.com.br:443 2>/dev/null \
    | openssl x509 -noout -dates -issuer -subject

# Testar suporte de protocolo/cifra específico
openssl s_client -connect painel.exemplo-isp.com.br:443 -tls1_2

O portal já tem uma ferramenta pronta para isso — Verificador SSL — sem precisar do comando manual para checagem rápida.

10. Algoritmos — o que evitar hoje

Cifra sem forward secrecy (não usa troca Diffie-Hellman efêmera) deve ser evitada — comprometer a chave privada no futuro não deveria permitir decifrar tráfego capturado no passado.

11. Monitoramento de expiração

Certificados expirados são uma das causas mais comuns de interrupção de serviço. Script para monitorar e alertar via Zabbix/PRTG:

#!/bin/bash
# check_cert_expiry.sh
DOMINIO="painel.exemplo-isp.com.br"
DIAS_LIMITE=30
EXPIRA=$(echo | openssl s_client -connect $DOMINIO:443 2>/dev/null \
    | openssl x509 -noout -enddate 2>/dev/null | cut -d= -f2)
EXPIRA_EPOCH=$(date -d "$EXPIRA" +%s)
AGORA_EPOCH=$(date +%s)
DIAS_RESTANTES=$(( (EXPIRA_EPOCH - AGORA_EPOCH) / 86400 ))
if [ $DIAS_RESTANTES -lt $DIAS_LIMITE ]; then
  echo "CRITICAL: certificado $DOMINIO expira em $DIAS_RESTANTES dias"
  exit 2
else
  echo "OK: certificado $DOMINIO válido por $DIAS_RESTANTES dias"
  exit 0
fi

12. Backup e recuperação de chaves

A perda de chaves privadas pode ser catastrófica. O backup deve incluir:

• Chaves SSH privadas — de servidores e de técnicos (com passphrase).
• Certificados e chaves TLS — incluindo a CA própria (se usada).
• Chaves DNSSEC — se operar zonas assinadas.
• Chaves LUKS — backups de cabeçalho LUKS.

Use restic ou Borg com a regra 3‑2‑1‑1‑0. Guarde as chaves em local seguro, idealmente com hardening adicional.

13. Troubleshooting

14. Glossário

15. Referências

• RFC 8446 — TLS 1.3.
• RFC 4251-4254 — SSH protocol.
• RFC 4033-4035 — DNSSEC.
• NIST SP 800-57 — Recommendation for Key Management.
• Let's Encrypt / EFF Certbot — documentação oficial.
• OpenSSH — documentação oficial.
• Páginas relacionadas: Hardening, DNSSEC, LGPD.

Conteúdo técnico independente. Nenhum trecho é cópia literal de fonte de terceiro.