Seguranca em Redes

Criptografia simétrica vs assimétrica:

  Simétrica (AES-256-GCM):
    - Uma chave compartilhada entre emissor e receptor
    - Rápida (~1 GB/s em hardware moderno)
    - Problema: como compartilhar a chave de forma segura?

  Assimétrica (RSA, ECDHE):
    - Par de chaves: pública (todos conhecem) + privada (secreta)
    - Dados encriptados com pública → só a privada descriptografa
    - Lenta (~1000x mais lenta que simétrica)
    - Resolve o problema de troca de chaves

  TLS usa as DUAS:
    1. Assimétrica no handshake → troca da session key
    2. Simétrica após handshake → encripta dados (AES)

  Diffie-Hellman (ECDHE):
    Permite que duas partes criem uma chave compartilhada
    via canal público, sem que um observador consiga calculá-la.
    É a base do "forward secrecy" — mesmo que a chave privada
    do servidor vaze, sessões passadas permanecem seguras.

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)

import ssl
import socket

def inspect_tls_connection(host, port=443):
    """Inspeciona os detalhes TLS de uma conexão."""
    ctx = ssl.create_default_context()
    with socket.create_connection((host, port)) as sock:
        with ctx.wrap_socket(sock, server_hostname=host) as ssock:
            print(f"Host: {host}")
            print(f"Versão TLS: {ssock.version()}")           # TLSv1.3
            print(f"Cipher: {ssock.cipher()}")                 # AES-256-GCM
            cert = ssock.getpeercert()
            print(f"Subject: {cert['subject'][0][0][1]}")
            print(f"Issuer: {cert['issuer'][1][0][1]}")
            print(f"Expira: {cert['notAfter']}")
            print(f"SANs: {[v for _, v in cert.get('subjectAltName', [])]}")

inspect_tls_connection("google.com")

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!")

Ataques por camada:

Camada 2 (Enlace):
  ARP Spoofing:   Atacante envia ARP replies falsos
                  → redireciona tráfego para si (MitM)
  MAC Flooding:   Inunda switch com MACs falsos
                  → switch vira hub, todos recebem tudo

Camada 3 (Rede):
  IP Spoofing:    Forja endereço IP de origem
  BGP Hijacking:  Anuncia rotas falsas para sequestrar tráfego

Camada 4 (Transporte):
  SYN Flood:      Envia milhares de SYN sem completar handshake
                  → esgota recursos do servidor (tabela de conexões)
  Port Scanning:  Descobre serviços ativos (nmap)

Camada 7 (Aplicação):
  DNS Spoofing:   Responde DNS com IP falso → redireciona tráfego
  SQL Injection:  Injeta SQL malicioso via input do usuário
  XSS:            Injeta JavaScript malicioso em páginas web
  CSRF:           Força usuário a executar ação não intencional

Defesas:
  ARP Spoofing  → Dynamic ARP Inspection (DAI) no switch
  SYN Flood     → SYN cookies (não aloca estado no SYN)
  DNS Spoofing  → DNSSEC (assinatura digital de records DNS)
  BGP Hijacking → RPKI (Resource Public Key Infrastructure)

Segurança 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