HTTPS e TLS (Handshake, Certificados)

1. Definição e Posicionamento

HTTPS (HyperText Transfer Protocol Secure) é HTTP sobre uma conexão protegida por TLS (Transport Layer Security), antigamente conhecido como SSL (Secure Sockets Layer). TLS é um protocolo de camada 6 (Apresentação) que provê confidencialidade, integridade e autenticação para conexões TCP. HTTPS é simplesmente HTTP encapsulado em TLS, tipicamente na porta 443.

Stack de Protocolos

Camada	Protocolo
7 - Aplicação	HTTP
6 - Apresentação	TLS 1.3
4 - Transporte	TCP

Versões TLS

Versão	RFC	Status
SSL 2.0/3.0	6101	Obsoleto (POODLE)
TLS 1.0	2246	Obsoleto (2020)
TLS 1.1	4346	Obsoleto (2020)
TLS 1.2	5246	Aceito (em transição)
TLS 1.3	8446	Recomendado

2. Handshake TLS 1.3

TLS 1.3 reduziu o handshake para 1-RTT (um round-trip), contra os 2-RTT do TLS 1.2. Suporta ainda 0-RTT (early data) para conexões de retorno.

Fluxo 1-RTT

Cliente                                  Servidor
  | ---- ClientHello ------------------->  | (key_share, SNI, ALPN, ciphers)
  | <--- ServerHello --------------------- | (key_share, selected_cipher)
  | <--- EncryptedExtensions/Certificate/CertificateVerify/Finished |
  | ---- Finished -------------------->  |
  | ===== Dados criptografados ========== |

Após o ServerHello, todo o tráfego é criptografado — inclusive o Certificate do servidor. Isso melhora privacidade (certificado não fica visível na rede) e performance.

0-RTT (Early Data)

Em reconexões, o cliente usa uma chave PSK (Pre-Shared Key) derivada de sessão anterior para enviar dados já no primeiro pacote, economizando um RTT. Risco: suscetível a replay attacks — servidor deve aceitar 0-RTT apenas para requisições idempotentes (GET, HEAD); nunca para POST/PUT/DELETE.

Comparação TLS 1.2 vs 1.3

Aspecto	TLS 1.2	TLS 1.3
RTT handshake	2	1 (ou 0)
Ciphers	CBC, GCM, RSA	Apenas AEAD
Troca de chaves	RSA, DH, ECDH	Apenas ECDHE/DHE (PFS)
Renegociação	Sim	Não
Certificado visível	Sim	Não (criptografado)

3. Certificados X.509

Certificado digital X.509v3 contém: versão, número de série, algoritmo de assinatura, emissor (Issuer DN), validade (notBefore, notAfter), sujeito (Subject DN), chave pública (RSA, ECDSA, Ed25519) e extensões (SAN, KeyUsage, BasicConstraints).

Subject Alternative Name (SAN): extensão crítica que lista todos os hostnames cobertos. Browsers ignoram o Common Name (CN) e consideram apenas SAN. Um certificado pode cobrir múltiplos domínios via SAN wildcard (*.exemplo.com) ou listagem explícita.

Cadeia de Confiança

Root CA (auto-assinado, na trust store do SO)
   |
   +-- Intermediate CA
          |
          +-- Server Certificate (ex: *.exemplo.com)

O servidor envia seu certificado + certificados intermediários. O cliente valida a cadeia até chegar a uma Root CA confiável presente no sistema operacional ou no browser.

Tipos de Certificado

Tipo	Validação	Custo
DV (Domain Validation)	Domínio	Grátis (Let's Encrypt)
OV (Organization Validation)	Domínio + Organização	$50-200/ano
EV (Extended Validation)	Verificação extendida	$200-700/ano

Desde 2019, browsers não exibem mais destaque visual para EV.

4. Autoridades Certificadoras e Let's Encrypt

CAs raiz são pré-instaladas no SO ou browser. Programas de trust store: Mozilla (CA Bundle, usado por Firefox, curl, Python), Microsoft (Windows Root Certificate Program), Apple (macOS/iOS root store), Oracle/Java (cacerts).

Let's Encrypt: CA gratuita, automatizada e aberta, lançada em 2015 pela ISRG. Emitiu mais de 50 milhões de certificados ativos. Usa o protocolo ACME (RFC 8555) para automação.

ACME (Automatic Certificate Management Environment)

Protocolo que automatiza emissão e renovação: (1) cliente gera chave de conta e CSR; (2) pede emissão à CA para o domínio; (3) CA retorna desafios (HTTP-01, DNS-01, TLS-ALPN-01); (4) cliente prova controle do domínio (ex: publica arquivo em /.well-known/acme-challenge/); (5) CA valida, assina certificado, envia ao cliente; (6) instala no servidor web; (7) renovação automática a cada 60 dias (validade: 90 dias).

Ferramentas comuns: certbot, acme.sh, lego (Go), módulo ACME embutido no Caddy.

5. SNI e ALPN

SNI (Server Name Indication)

Permite que o cliente indique o hostname alvo no ClientHello. Isso habilita servidores com múltiplos domínios (virtual hosting) na mesma porta 443 a selecionarem o certificado correto. Sem SNI, um servidor IP só poderia servir um certificado.

ESNI/ECH: Encrypted SNI (ou Encrypted Client Hello, RFC 9460) criptografa o SNI para esconder o hostname de intermediários. Requer DNS HTTPS records publicando a chave pública do servidor. Adoção lenta (2024).

ALPN (Application-Layer Protocol Negotiation)

Permite que cliente e servidor negociem o protocolo de aplicação durante o handshake TLS, sem round-trip adicional. Usado para selecionar entre HTTP/1.1, HTTP/2 e HTTP/3: ClientHello: alpn=[h2, http/1.1] → ServerHello: alpn=h2.

6. Cipher Suites e PFS

Uma cipher suite TLS 1.3 é nomeada como TLS_<cipher>_<hash> (ex: TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256).

Perfect Forward Secrecy (PFS): garante que, mesmo se a chave privada do servidor for comprometida no futuro, sessões anteriores não poderão ser descriptografadas. TLS 1.3 força PFS usando apenas ECDHE ou DHE para troca de chaves — chaves efêmeras descartadas após handshake. RSA key exchange (sem PFS) foi removido.

7. HSTS e HPKP

HSTS (HTTP Strict Transport Security)

Header que instrui o navegador a usar apenas HTTPS para o domínio:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

• max-age: segundos (1 ano típico).
• includeSubDomains: aplica a subdomínios.
• preload: autoriza inclusão na lista HSTS Preload do Chrome (embutida no browser, força HTTPS mesmo na primeira visita).

Sem HSTS, um atacante na mesma rede (Wi-Fi público) pode fazer downgrade attack (SSL Strip) redirecionando o usuário para HTTP.

HPKP (HTTP Public Key Pinning): mecanismo que fixava hashes de chaves públicas esperadas. Depreciado em 2018 devido a risco de "brick" do site. Substituído por CAA records.

CAA (Certification Authority Authorization)

Registro DNS que especifica quais CAs estão autorizadas a emitir certificados para o domínio:

exemplo.com.  CAA  0 issue "letsencrypt.org"
exemplo.com.  CAA  0 issuewild ";"

8. Ataques Históricos a TLS

Ataque	Versão afetada	Mitigação
BEAST (2011)	TLS 1.0 CBC	TLS 1.2 com GCM
CRIME (2012)	TLS com compressão	Desativar compressão TLS
POODLE (2014)	SSL 3.0 CBC	Desativar SSL 3.0
Heartbleed (2014)	OpenSSL 1.0.1	Patch (1.0.1g+)
ROBOT (2017)	Servidores RSA	Desativar RSA key exchange
DROWN (2016)	SSLv2 habilitado	Desativar SSLv2

9. Ferramentas de Diagnóstico

openssl s_client -connect www.exemplo.com:443 -servername www.exemplo.com
testssl.sh https://www.exemplo.com/   # Teste completo de fraquezas
# SSL Labs (online): https://www.ssllabs.com/ssltest/ (nota A+ a F)
nmap --script ssl-enum-ciphers -p 443 www.exemplo.com

10. Boas Práticas

Habilitar Apenas TLS 1.2 e 1.3

ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers on;
ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384';
ssl_ecdh_curve X25519:secp384r1;

OCSP Stapling

ssl_stapling on; ssl_stapling_verify on; resolver 8.8.8.8;

Permite que servidor entregue prova de que o certificado não foi revogado (OCSP response assinada pela CA), sem o cliente precisar consultar a CA diretamente.

HSTS com Preload e Renovação Automatizada

Após certificar-se de que HTTPS está estável, submeter domínio à HSTS Preload List. Com Let's Encrypt, configurar renovação automática (cron/systemd timer a cada 60 dias).

11. Resumo Técnico

Atributo	Valor
Protocolo	TLS 1.3 (RFC 8446)
Porta padrão	443
Handshake	1-RTT (ou 0-RTT)
PFS	Obrigatório (ECDHE/DHE)
SNI	Sim (criptografado via ECH)
ALPN	Sim (h2, http/1.1, h3)
CA gratuita	Let's Encrypt (ACME)
Header de segurança	HSTS, CAA

12. Conclusão

HTTPS e TLS formam a espinha dorsal da web moderna. TLS 1.3 trouxe ganhos em performance (1-RTT, 0-RTT), segurança (apenas AEAD, PFS obrigatório) e privacidade (certificado criptografado). Let's Encrypt democratizou certificados. HSTS, CAA e OCSP Stapling complementam a proteção.