Seguranca em Redes

TLS Handshake (simplificado):

Cliente                              Servidor
   |                                    |
   |--- ClientHello ------------------>|  Versao TLS, cipher suites, random
   |                                    |
   |<-- ServerHello -------------------|  Cipher suite escolhida, random
   |<-- Certificate -------------------|  Certificado X.509 do servidor
   |<-- ServerHelloDone ---------------|
   |                                    |
   |  [Verifica certificado contra CAs]|
   |                                    |
   |--- ClientKeyExchange ------------>|  Pre-master secret (criptografado
   |--- ChangeCipherSpec ------------->|  com chave publica do servidor)
   |--- Finished (encrypted) -------->|
   |                                    |
   |<-- ChangeCipherSpec --------------|
   |<-- Finished (encrypted) ---------|
   |                                    |
   |==== DADOS CRIPTOGRAFADOS =========|  Symmetric encryption (AES)

Apos o handshake:
  - Ambos tem a mesma session key (simetrica)
  - Todos os dados sao criptografados com AES
  - HMAC garante integridade (dados nao alterados)

Cadeia de certificados:

Root CA (pre-instalada no SO/browser)
  |
  +-- Intermediate CA (assinada pela Root)
       |
       +-- Certificado do servidor (assinado pela Intermediate)
            Subject: neon.tech
            Issuer: Let's Encrypt
            Valid: 2026-01-01 to 2026-04-01
            Public Key: RSA 2048-bit

Verificacao:
  1. Browser recebe certificado do servidor
  2. Verifica assinatura com a chave publica da Intermediate CA
  3. Verifica assinatura da Intermediate com a Root CA
  4. Root CA esta na trust store do SO? Sim -> CONFIAVEL

OAuth 2.0 Authorization Code Flow:

Usuario    App (Client)     Auth Server     Resource Server
  |           |                  |                |
  |--login--->|                  |                |
  |           |---redirect------>|                |
  |           |                  |                |
  |<------login page------------|                |
  |---credentials--------------->|                |
  |<------auth code--------------|                |
  |           |                  |                |
  |           |---auth code----->|                |
  |           |<--access token---|                |
  |           |                                   |
  |           |---GET /api + Bearer token-------->|
  |           |<--200 OK + data-------------------|

Metodo           Seguranca   Complexidade   Uso
──────────────   ─────────   ────────────   ────────────────────
API Key          Baixa       Simples        APIs publicas, rate limiting
  Header: X-API-Key: abc123

Bearer Token     Media       Media          OAuth 2.0, JWT
  Header: Authorization: Bearer eyJ...

mTLS             Alta        Alta           Servico-a-servico, zero trust
  Ambos os lados apresentam certificados

HMAC Signature   Alta        Media          Webhooks, AWS Signature v4
  Assinatura do request com shared secret

import jwt
import time

# Criando um JWT (JSON Web Token)
secret = "my-secret-key"
payload = {
    "sub": "build-ai",           # Subject (quem)
    "role": "agent",              # Permissoes
    "iat": int(time.time()),     # Issued at
    "exp": int(time.time()) + 3600,  # Expira em 1h
}
token = jwt.encode(payload, secret, algorithm="HS256")
print(f"JWT: {token}")

# Verificando JWT
try:
    decoded = jwt.decode(token, secret, algorithms=["HS256"])
    print(f"Subject: {decoded['sub']}")
    print(f"Role: {decoded['role']}")
except jwt.ExpiredSignatureError:
    print("Token expirado!")
except jwt.InvalidTokenError:
    print("Token invalido!")

Seguranca de rede no harness.os:

1. MCP Server endpoints
   Atual:   API key no header (X-API-Key)
   Ideal:   JWT com escopos (read:knowledge, write:sessions)
   Futuro:  mTLS entre mesh nodes (zero trust)

2. Neon Postgres
   Atual:   Password auth + SSL required
   Ideal:   SSL + IP allowlist + credential rotation
   Futuro:  IAM authentication (sem passwords)

3. Mesh inter-node communication
   Problema: como build.ai confia em marco.ai?
   Solucao:  JWT signed com shared secret entre nodes
             Cada node tem um token que identifica quem e + permissoes

4. Fly.io deployment
   Atual:   Auto-TLS (Let's Encrypt) para HTTPS
   Ideal:   mTLS entre apps Fly.io (WireGuard mesh interno)

Fluxo de autenticacao mesh proposto:
  Node A --[JWT: sub=build-ai, role=build]--> Node B
  Node B verifica JWT, checa permissoes
  Se valido: processa request
  Se invalido: 401 Unauthorized