07 — Protocolos Criptográficos

Protocolos combinam primitivas (cifras, hash, assinatura) em interações entre partes. Aqui: TLS, SSH, IPsec, Kerberos, OAuth/OIDC, Signal, MLS, Noise, WireGuard, OPAQUE, e protocolos clássicos relevantes.

1. SSL / TLS — evolução

SSL 1.0 (Netscape 1994) ❌

Nunca lançado publicamente. Falhas elementares descobertas internamente.

SSL 2.0 (1995) ❌

• MAC e encryption usam mesma chave.
• Tráfego header não autenticado.
• Vulnerável a truncation attacks.
• Padding oracle issues.
• Deprecated RFC 6176 (2011). Removido em todo browser ~2015.

SSL 3.0 (1996) ❌

• MAC com SHA-1 mas não cobre tudo.
• CBC vulnerável (BEAST, POODLE).
• POODLE (2014) — Padding Oracle On Downgraded Legacy Encryption. Killed SSL 3.0 in browsers Q4/2014.

TLS 1.0 (RFC 2246, 1999) ❌

Renomeio de SSL 3.1 (Netscape vs IETF politics). Mesmos algoritmos. BEAST (2011) demonstrou problema com CBC IV chaining.

TLS 1.1 (RFC 4346, 2006) ❌

Fix do BEAST: IV explícito por record. Caíram em desuso; deprecated junto com 1.0 em 2020 (RFC 8996).

TLS 1.2 (RFC 5246, 2008) ⚠️

• Suporta SHA-256, AES-GCM, AEAD.
• Ainda permite RSA key transport (no forward secrecy).
• Ainda permite cipher suites com RC4, 3DES, CBC.
• Configuração segura possível mas exige diligência.
• Status: ainda dominante. Deve estar configurado apenas com cipher suites ECDHE + AEAD.

Cipher suites recomendadas TLS 1.2:

• ECDHE-ECDSA-AES128-GCM-SHA256
• ECDHE-ECDSA-CHACHA20-POLY1305
• ECDHE-RSA-AES256-GCM-SHA384
• ECDHE-RSA-CHACHA20-POLY1305

TLS 1.3 (RFC 8446, 2018) ✅

Redesign profundo:

• Remove RSA key transport (sempre ECDHE/DHE → forward secrecy obrigatório).
• Remove RC4, 3DES, MD5, SHA-1, CBC modes (todos), static DH.
• Remove compressão (CRIME).
• Remove renegotiation.
• Apenas 5 cipher suites; todas AEAD.
• 0-RTT (zero round-trip resumption) — performance mas com replay caveats.
• Handshake encrypted após ServerHello.
• HKDF-based key schedule unificado.

Cipher suites TLS 1.3 (todas obrigatórias):

• TLS_AES_128_GCM_SHA256
• TLS_AES_256_GCM_SHA384
• TLS_CHACHA20_POLY1305_SHA256 (obrigatório por RFC)
• TLS_AES_128_CCM_SHA256
• TLS_AES_128_CCM_8_SHA256

Key exchange groups: secp256r1 (P-256), secp384r1, secp521r1, X25519, X448, plus X25519MLKEM768 (pós-quântico híbrido, draft-ietf-tls-hybrid-design).

TLS 1.3 handshake (simplificado)

ClientHello [random, cipher_suites, key_share, signature_algorithms, ...]
  →
ServerHello [random, cipher_suite, key_share, ...]
{EncryptedExtensions}
{Certificate}
{CertificateVerify}
{Finished}
  ←
{Certificate*}      // mTLS opcional
{CertificateVerify*}
{Finished}
  →
[Application Data]
  ⇄

{...} = encrypted with handshake traffic secret derived from ECDHE.

Migração pós-quântica

• X25519MLKEM768 — Cloudflare/Google rolling out em 2024–2025. ClientHello carrega ambos key_shares; server escolhe.
• Servers tradicionais ainda em ECDHE puro.
• Migration completa esperada 2028–2032.

Falhas históricas TLS 1.2/1.3

Extensions úteis

• SNI (Server Name Indication, RFC 6066) — host header em ClientHello.
• ALPN (RFC 7301) — Application-Layer Protocol Negotiation (HTTP2, HTTP3).
• ECH (Encrypted Client Hello, draft) — encrypta SNI; substitui ESNI. Usa HPKE.
• Certificate Transparency (RFC 6962) — public logs de cert issuances.
• OCSP Stapling (RFC 6066) — server envia OCSP response, cliente não consulta CA.
• 0-RTT — TLS 1.3 early data com PSK. Risco de replay.
• TLS-PSK — pre-shared key, sem cert.

Cert validation chain

Root CA (offline, em HSM)
  ↓
Intermediate CA (online)
  ↓
End-entity cert (server)

Cliente carrega Root store (Mozilla NSS, Microsoft, Apple, Google CRLSet). Cada intermediário assina o próximo.

Certificate Transparency (CT) — log público append-only assinado. Browsers exigem SCT (Signed Certificate Timestamp). Detecta cert mis-issued.

2. SSH (Secure Shell)

História

• 1995: Tatu Ylönen (Finlândia) — SSH-1.
• 1996: OpenSSH fork de SSH-1.2.12 (último free).
• 1997–2006: IETF padroniza SSH-2 (RFC 4251–4254).
• 2006: SSH-2 mainstream.

Camadas SSH-2

1. Transport (RFC 4253) — KEX, encryption, MAC, server authentication.
2. User auth (RFC 4252) — password, public key, host-based, GSSAPI.
3. Connection (RFC 4254) — multiplex channels (shell, exec, port forward, X11).

KEX

• diffie-hellman-group14-sha256 (RFC 8268)
• diffie-hellman-group-exchange-sha256
• ecdh-sha2-nistp256384521
• curve25519-sha256@libssh.org / curve25519-sha256 (default moderno)
• sntrup761x25519-sha512@openssh.com (PQC hybrid, OpenSSH 9.0+, abril 2022)

Host keys

• ssh-rsa (legacy, broken hash SHA-1; deprecated default em OpenSSH 8.2+)
• rsa-sha2-256, rsa-sha2-512
• ecdsa-sha2-nistp256384521
• ssh-ed25519 (recomendado, default desde 7.x)

User keys

~/.ssh/id_ed25519 recomendado em vez de id_rsa. RSA 4096 OK como alternativa.

Vulnerabilidades históricas

• CRC-32 compensation attack (1998, SSH-1) — RC4-MD5.
• Plaintext recovery in CBC mode (Albrecht et al. 2009) — exigia 8 GB tráfego.
• Roaming feature client bug (CVE-2016-0777, 2016) — vazava chave privada.
• Terrapin (CVE-2023-48795, dez/2023) — truncation attack em SSH BPP. Atacante MITM no handshake corta extension negotiation. Mitigado por strict KEX no OpenSSH 9.6+ e libssh 0.10.6+.

Hardening 2026

HostKeyAlgorithms ssh-ed25519,rsa-sha2-512,rsa-sha2-256
KexAlgorithms sntrup761x25519-sha512@openssh.com,curve25519-sha256
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com
PubkeyAuthentication yes
PasswordAuthentication no
PermitRootLogin prohibit-password

3. IPsec / IKE

Network-layer encryption. RFC 4301 (architecture), RFC 7296 (IKEv2).

Componentes

• AH (Authentication Header, RFC 4302) — integridade + autenticidade (sem confidencialidade). Pouco usado hoje.
• ESP (Encapsulating Security Payload, RFC 4303) — confidencialidade + integridade.
• IKE (Internet Key Exchange) — negocia SAs (Security Associations) e chaves.

Modos

• Transport mode — IP header preservado; payload cifrado. Host-to-host.
• Tunnel mode — IP header dentro cifrado; novo header externo. Gateway-to-gateway VPN.

IKEv1 ❌

RFC 2409 (1998). Aggressive Mode tem PSK offline crack (cipherspark 2018 demo). Main Mode mais robusto mas complexo.

IKEv2 ✅

RFC 7296. Simplificação radical: 1 RTT setup, mobility (RFC 4555 MOBIKE), EAP auth.

Cipher suites recomendadas

• AES-GCM-128 ou AES-GCM-256 (RFC 4106)
• ChaCha20-Poly1305 (RFC 7634)
• Diffie-Hellman group 19 (256-bit ECP) ou 20 (384-bit ECP) ou 31 (X25519)

IKE_AUTH com certificados ou PSK

Falhas

• CVE-2018-5389 — Aggressive Mode PSK offline.
• strongSwan / Libreswan stack code: várias CVEs ao longo dos anos; mantenha atualizado.

Alternativa moderna: WireGuard

Ver §10.

4. Kerberos

MIT Athena Project, 1980s. RFC 4120 (V5, 2005). Backbone de Active Directory.

Componentes

• KDC (Key Distribution Center): emite tickets.
• AS (Authentication Service): emite TGT (Ticket-Granting Ticket).
• TGS (Ticket-Granting Service): emite service tickets.
• Principal: identidade (user@REALM, host/fqdn@REALM).

Flow

1. AS-REQ: cliente envia username; AS responde com TGT cifrada com hash de senha.
2. Cliente decifra TGT com senha; agora tem TGT válido (e session key com TGS).
3. TGS-REQ: cliente apresenta TGT + service principal pedido; TGS responde com service ticket.
4. AP-REQ: cliente apresenta service ticket ao serviço.

Crypto

• DES (deprecated)
• 3DES (deprecated)
• AES-128/256-CTS-HMAC-SHA1-96 (RFC 3962)
• AES-128256-CTS-HMAC-SHA256384-192 (RFC 8009)

Vulnerabilidades

• Golden Ticket: comprometeu hash do krbtgt (principal de TGS); pode forjar qualquer TGT. AD requer rotate dupla pra invalidar.
• Silver Ticket: forja service ticket sem talk ao KDC.
• Kerberoasting: pede service tickets com SPN comprometível, faz offline crack da chave (= hash da senha do account).
• AS-REP Roasting: usuários com DONT_REQ_PREAUTH permitem dump.
• Zerologon (CVE-2020-1472) — Netlogon protocol bug: AES-CFB8 com IV all-zeros aceita all-zero plaintext → zera senha do DC. Crítico em set/2020.

5. OAuth 2.0 + OpenID Connect

Não-criptografia per se; protocolo de delegação de acesso.

OAuth 2.0 (RFC 6749, 2012)

Roles:

• Resource Owner (usuário)
• Client (app)
• Authorization Server (Koder ID, Google, etc.)
• Resource Server (API)

Flows:

• Authorization Code + PKCE — padrão atual mobileSPAweb.
• Implicit Flow — deprecated (token em URL fragment, vaza).
• Client Credentials — service-to-service.
• Device Authorization Flow (RFC 8628) — TVs, CLIs.
• Refresh Token — long-lived re-auth.

PKCE (RFC 7636)

code_verifier random; code_challenge = SHA256(verifier). Liga authorization code à sessão do cliente. Obrigatório para clientes públicos.

OpenID Connect (OIDC)

Identity layer on top de OAuth 2.0. Server emite id_token (JWT) com claims do usuário.

JWT (RFC 7519)

header.payload.signature

• Header: alg, typ.
• Payload: claims (iss, sub, aud, exp, iat, jti, etc.).
• Signature: assinatura sobre header.payload.

Algoritmos:

• HS256384512 — HMAC, simétrica (shared secret).
• RS256384512 — RSA-PKCS#1 v1.5 SHA-*.
• PS256384512 — RSA-PSS.
• ES256384512 — ECDSA.
• EdDSA — Ed25519 (RFC 8037).

Falhas comuns JWT

• alg: none aceito por libs descuidadas (CVE-2015-9235).
• alg: HS256 com pubkey RSA como secret (CVE-2015-2951).
• kid path traversal se kid usado como filename.
• Algorithm confusion entre RS256 e HS256.
• JWT explicações: nunca confie em JWT que veio do cliente — sempre valide assinatura, exp, aud, iss.

Koder ID

Spec da Stack: specs/auth/oauth-flow.kmd — slug koder-id, post-auth dashboard, no local form, deep-link preserve, R1-R12.

6. Signal Protocol

End-to-end encryption messaging. Open Whisper Systems (Moxie Marlinspike, Trevor Perrin) — atual Signal Foundation.

Componentes

1. X3DH (Extended Triple Diffie-Hellman) — initial key agreement com pre-keys publicados.
2. Double Ratchet — DH ratchet (cada msg, nova chave) + symmetric ratchet (KDF per msg) → forward secrecy + post-compromise security.
3. Sesame — multi-device session management.

X3DH

Server hosts:

• Long-term identity key (IK_B) — Ed25519.
• Signed pre-key (SPK_B) — rotated weekly.
• One-time pre-keys (OPK_B) — used once.

Alice fetches Bob's bundle. Compute:

DH1 = DH(IK_A, SPK_B)
DH2 = DH(EK_A, IK_B)
DH3 = DH(EK_A, SPK_B)
DH4 = DH(EK_A, OPK_B)
SK = HKDF(DH1 \\\| DH2 \\\| DH3 \\\| DH4)

Deniability: alguém com identity keys pode falsificar — Alice tem deniability cryptographically.

Double Ratchet

Para cada msg:

• Symmetric ratchet: \(\text{chain\_key} \to (\text{msg\_key}, \text{chain\_key}')\) via HMAC-SHA256.
• DH ratchet: ao receber msg nova com nova DH pubkey, advance DH chain: novo DH share → novo root key → novos chain keys.

Resultado:

• Forward secrecy: msg antiga não recuperável mesmo com chave atual.
• Post-compromise security: depois de comprometer estado, próximo DH ratchet recupera segurança.

Adoção

• Signal app
• WhatsApp (2016)
• Facebook Messenger Secret Conversations
• Google Allo (descontinuado)
• Skype private conversations
• KaKaoTalk

PQXDH (Signal, 2023)

Substituição PQC de X3DH. Combina X25519 + ML-KEM-1024. Hybrid model: ataque precisa quebrar ambos.

7. MLS — Messaging Layer Security

RFC 9420 (jul/2023). IETF padronização de E2E para grupos.

Motivação

Signal escala mal pra grupos grandes (cada msg cifra para N membros). MLS usa TreeKEM: árvore binária, cada nó tem chave; mudança propaga em \(O(\log n)\).

Componentes

• Asymmetric Ratchet Tree (RT): árvore com chaves em cada nó.
• TreeKEM: derivação eficiente de chaves de grupo.
• Welcome message: novo membro recebe ratchet state.
• Commit: muda estado do grupo (add, remove, update).

Adoção

• WebEx (Cisco)
• RingCentral
• Wickr (AWS)
• Implementations: OpenMLS (Rust), mlspp (Cisco C++)

8. Noise Protocol Framework

Trevor Perrin, 2015–2018. noiseprotocol.org. Framework para construir protocolos seguros. Não é protocolo único.

Patterns

Notação: cada handshake = sequência de tokens (e, s, ee, es, se, ss). Exemplos:

• N: one-shot encryption to pre-known recipient.
• K: known recipient + sender authenticated.
• X: full mutual auth + encrypted transport.
• IK (interactive K): used por WireGuard.
• XX: mutual auth, cert exchange.

Usado em

• WireGuard: Noise_IKpsk2.
• Lightning Network: Noise_XK.
• WhatsApp protocol stack (parts).
• Nym, Wesh, Slack Connect.

9. WireGuard

Jason Donenfeld, 2015–2018. Mergeado no kernel Linux 5.6 (mar/2020).

Design

• 4000 lines of kernel C (vs 100k+ de IPsec stack).
• Cryptographic agility: rejeitada por design. Algoritmos fixos:
  • Curve25519 (ECDH)
  • ChaCha20-Poly1305 (AEAD)
  • BLAKE2s (hash)
  • HKDF
• Sem PKI; cada peer tem pubkey listado em config.
• UDP only, single port.

Handshake

Noise_IKpsk2 — 2 mensagens, 1 RTT. Recupera de hibernação com cookie.

Privacy

Sem identidade em pacotes. Stateless transport packets indistinguíveis sem chave correta.

Limitações

• Sem dynamic peers (use Tailscale/Headscale acima).
• Sem TCP fallback (use TCP-tunneling overlay).
• Sem PQC (proposed: boringtun PQ fork experimentou em 2023).

10. OPAQUE — PAKE

RFC 9497 (2024). PAKE (Password-Authenticated Key Exchange) que evita servidor armazenar senha ou derivado.

• Server stores OPRF(salt, password) envelope, sem nunca ver senha.
• Mesmo se server vazar, offline dictionary attack impossível.
• Substitui sistema "send password, server bcrypt-compares".

Usado experimental em Cloudflare, ProtonMail planning, future Keybase.

Outras PAKE

• SRP (Secure Remote Password) — antiga, ainda usada em 1Password até 2024.
• SPAKE2, J-PAKE, CPace — variantes.

11. Email & Documents

PGP / OpenPGP

RFC 4880 (legacy), RFC 9580 (2024 — Crypto Refresh).

• Web of trust (vs PKI hierarchical).
• Cifras: AES, Camellia; hashes: SHA-2, SHA-3; sigs: RSA, ECDSA, EdDSA, Ed25519.
• RFC 9580 adiciona Curve25519, BLAKE2, Argon2.

Críticas modernas:

• Long-term keys (no forward secrecy).
• UX terrível.
• Implementações divergentes.
• EFAIL (2018) — backchannel via HTML rendering.
• SOP-spec (Stateless OpenPGP) tenta limpar implementações.

S/MIME (RFC 8551)

PKCS#7 / CMS para email. CA-based PKI. Menos popular fora corporate.

age (Filippo Valsorda 2019)

Substitui PGP para file encryption.

• Sem long-term identities; cada arquivo tem ephemeral key.
• X25519 + ChaCha20-Poly1305 + scrypt.
• SSH key compatibility (Ed25519, RSA).
• age CLI, libsodium-style.

12. DNSSEC, DoT, DoH, DoQ

DNSSEC (RFC 4033/4035)

Assina records DNS. Cadeia de confiança DS / DNSKEY. Algoritmos modernos: ECDSA P-256, Ed25519, Ed448. Algoritmos legacy ainda em uso: RSA-SHA256, RSA-SHA1 (proibir).

DNS-over-TLS (DoT, RFC 7858)

Porta 853. TLS sobre porta dedicada. Server cert validado.

DNS-over-HTTPS (DoH, RFC 8484)

Porta 443. Em HTTPS. Mais difícil de censurar mas misturando com tráfego web.

DNS-over-QUIC (DoQ, RFC 9250)

DNS sobre QUIC. Latência menor.

ODoH, Oblivious DoH (RFC 9230)

Privacy: client → proxy → resolver. Resolver não sabe IP cliente; proxy não vê queries.

13. QUIC e HTTP/3

QUIC (RFC 9000–9002, 2021) — transport sobre UDP com TLS 1.3 built-in. Multiplex sem head-of-line blocking. HTTP/3 (RFC 9114) é HTTP em QUIC.

Toda crypto = TLS 1.3 com extensão pra integrar nos pacotes QUIC.

14. ACME (Let's Encrypt)

RFC 8555 (2019). Protocolo de automatic cert issuance. Cliente prova controle do domain via challenges:

• HTTP-01: serve token em /.well-known/acme-challenge/.
• DNS-01: cria TXT record _acme-challenge.example.com.
• TLS-ALPN-01: serve cert ALPN especial.

Implementações:

• certbot (EFF, original).
• acme.sh (bash).
• lego (Go, usado pelo Caddy/Traefik).
• dehydrated (bash, minimal).
• Koder Jet native ACME.

Koder Stack: services/foundation/certs em s.khost1:9421 faz DNS-01 via ClouDNS API. LE staging confirmado.

15. WebAuthn / FIDO2

W3C + FIDO Alliance, 2019.

• Public-key authentication com hardware (YubiKey, Titan, Touch ID).
• Resiste phishing (origin binding).
• Crypto: ECDSA P-256, Ed25519, RSA opcional.
• Attestation opcional (prova autenticador genuíno).

Adoção: Google, Apple, Microsoft Passkeys (2022–) substituindo senhas. Passkey = WebAuthn credential sincronizado em iCloud / Google account.

16. Tor / mix-nets / Loopix

Anonymity protocols.

• Tor: 3-hop onion routing com TLS layered. AES-128-CTR + DH ECDH. Hidden services .onion.
• I2P: garlic routing.
• Mixnets (Loopix, Nym): cover traffic, mixing nodes. Latency-tolerant.

17. Resumo: protocolos por uso (2026)

18. Referência cruzada

• Primitivas usadas: 04-simetrica.md, 05-assimetrica.md, 06-hash-e-mac.md.
• Ataques contra: 11-ataques.md (BEAST, POODLE, FREAK, Logjam, DROWN, Heartbleed, ROBOT, Terrapin).
• PQC integration: 08-pos-quantica.md.
• Identidades / certs / CAs: 09-confidential-computing.md + 13-incidentes.md (DigiNotar, Comodo).
• Koder Stack usage: 14-koder-aplicada.md.