Proteção contra abuso do relay cego
Como nós AeroNyx contêm replay, loops, excesso de requisições e peers falhos sem ler o cifrado, com evidência operacional segura para privacidade.
Blind Relay Abuse Guard é o limite de segurança do encaminhamento criptografado descentralizado AeroNyx. Ele contém relays abusivos ou instáveis sem analisar ciphertext, criar histórico persistente de rotas ou transformar o operador em observador de tráfego.
Status e escopo
A proteção está implementada em Rust e os resultados agregados aparecem no health metadata e Nodeboard. A função é conter e produzir evidência honesta: trabalho opaco aceito, protegido, degradado ou stale, nunca seu conteúdo.
| Controle | Estado |
|---|---|
| Blind payload forwarding | Implementado |
| Signed freshness and replay suppression | Implementado |
| Previous-hop rate limiting and quarantine | Implementado |
| Privacy-safe runtime evidence | Implementado |
| Nodeboard operator visibility | Implementado |
| Plaintext or payload inspection | Proibido |
| User, route, or social-graph analytics | Proibido |
Invariante do nó cego
Um relay pode autenticar metadata de rota, aplicar política limitada, encaminhar envelope opaco e retornar receipt assinado pelo terminal. Não pode inspecionar ou inferir payload nem revelar metadata capaz de reconstruir rota, identidade ou relação social.
- mensagens em claro, packet payloads, mídia ou MemChain em claro
- DNS, destinos, domínios, URLs ou histórico
- route IDs, caminhos completos, endpoint URLs ou IP do cliente
- chaves públicas completas, receiver, message IDs ou grafo social
- chaves privadas, voucher secrets, tráfego wallet-level ou material de descriptografia
Pipeline de admissão
Cada request passa por controles limitados antes de consumir capacidade. A ordem abaixo é conceitual; decisões usam somente routing metadata assinada e estado agregado local, nunca conteúdo descriptografado.
verify signed previous_hop and envelope
apply in-flight backpressure
check timestamp freshness
check route replay cache
apply previous-hop rate/quarantine decision
validate TTL, loop safety, next-hop descriptor, and endpoint
forward opaque ciphertext or terminate into pending store
Proteção de replay e freshness
A supressão de replay é local, curta e limitada em capacidade. Timestamps assinados rejeitam frames antigos ou muito futuros. A tabela contém defaults atuais de main, não promessas permanentes; mudanças exigem tests e documentação.
| Constante de runtime | Default atual |
|---|---|
MAX_BLIND_RELAY_SEEN_ROUTES | 8192 route IDs |
BLIND_RELAY_ROUTE_REPLAY_WINDOW_SECS | 600 seconds |
BLIND_RELAY_PREVIOUS_HOP_RATE_LIMIT | 120 requests / 60 seconds |
BLIND_RELAY_PREVIOUS_HOP_FAILURE_THRESHOLD | 12 scored failures / 300 seconds |
BLIND_RELAY_PREVIOUS_HOP_QUARANTINE_SECS | 300 seconds |
MAX_BLIND_RELAY_PREVIOUS_HOP_BUCKETS | 4096 buckets |
BLIND_RELAY_MAX_ENVELOPE_AGE_SECS | 600 seconds |
BLIND_RELAY_MAX_FUTURE_SKEW_SECS | 120 seconds |
BLIND_RELAY_DELIVERY_RECEIPT_MAX_AGE_SECS | 120 seconds |
MAX_BLIND_RELAY_FORWARD_ATTEMPTS | 3 attempts |
Limite e quarentena do salto anterior
O rate limit é por identidade assinada do salto anterior. Mais de 120 requests em 60 segundos inicia cinco minutos de quarentena local. Um score separado inicia a mesma quarentena após 12 falhas hostis em cinco minutos.
invalid_previous_hop | invalid_signature | self_loop | route_loop | ttl_exhausted
Somente razões adversariais contam no score. Timeouts, ACK perdido e retry de rota duplicada não penalizam peer saudável. Buckets são limitados e estado ocioso expira, impedindo um grafo persistente.
Idempotência e tentativas
Route ID repetido na janela recebe sucesso idempotente: registra replay drop agregado, sem entregar ou encaminhar novamente. Falhas transitórias têm até três tentativas com jitter limitado; falhas permanentes não são repetidas.
duplicate route_id -> accepted=true, reason=duplicate_route, no second delivery
transient next-hop failure -> bounded retry with deterministic jitter
permanent validation failure -> no retry
Contadores agregados de runtime
Rust expõe contadores cumulativos grossos e timestamps de freshness nos dois caminhos seguintes. São evidência operacional do nó, não logs de mensagens, analytics faturáveis ou prova de conversa específica.
system_stats.discovery_status.peer_store.runtime.blind_relay
system_stats.discovery_status.peer_store.peer_health_summary
| Grupo de contadores | Campos |
|---|---|
| Entrada e resultado | received, terminal, forwarded, rejected |
| Validação e proteção | invalid_signature, envelope_too_large, ttl_exhausted, no_route, invalid_endpoint, loop_detected, replay_dropped, timestamp_rejected, rate_limited, quarantined, quarantine_started |
| Transporte e retry | backpressure_dropped, forward_failed, retry_attempted, retry_succeeded, retry_exhausted |
| Evidência sintética | probe_attempted, probe_succeeded, probe_failed, two_hop_probe_attempted, two_hop_probe_succeeded, two_hop_probe_failed |
| Entrega real e freshness | verified_client_onion_deliveries, last_verified_client_onion_delivery_at, last_accepted_at, last_event_at |
Semântica de qualidade da evidência
O resumo separa trabalho opaco aceito, probes sintéticos, proofs sintéticos two-hop e receipts de client assinados pelo terminal. real_relay_ready exige receipt recente, autenticado, originado por client e assinado pelo terminal esperado. Evidência sintética nunca é tráfego App/usuário.
status | Significado |
|---|---|
idle | Ainda não há evidência relay ou probe. |
observing | Há evidência parcial, readiness não estabelecida. |
stale | Evidência anterior não está fresca. |
ready | Trabalho aceito ou proof fresco sem alerta ativo de transporte. |
protecting | Proteções estão ativas e o relay segue operacional. |
degraded | Falhas de forwarding ou probe exigem investigação. |
attention | Backpressure ou retries esgotados exigem ação imediata. |
proof_scope separa client_message_delivery, relay_acceptance, message_delivery, control_plane, single_hop_control_plane, attempted e none. Totais históricos são cumulativos; readiness exige evidência fresca e considera falhas ativas.
Saúde de peers com privacidade
peer_health_summary usa identificador abreviado e buckets grossos para isolar peer falho ou em quarentena sem expor relações de tráfego. É diagnóstico control-plane com limite de privacidade explícito.
Permitido:
node_id_prefixabreviado- health e descriptor state grossos
- buckets de freshness de gossip e route success
- contagens agregadas de sucesso e falha
- contagens agregadas loop, replay, rate-limit e quarantine
- tempo restante de quarentena e razões limitadas
Não permitido:
- chaves públicas completas
- route IDs ou listas de endpoints
- blobs cifrados ou payload hashes
- message IDs ou identidade receiver
- IP do cliente, destinos ou DNS
- grafo social ou relações de comunicação
Fluxo do operador
Abra Nodeboard, selecione o nó e veja Discovery e Security / Relay Protection. Interprete tendências somente com saúde, alcance, pressão de fila e freshness de proofs assinados.
- Confirme freshness dos descriptors e bootstrap recovery.
- Compare
accepted_total,accepted_percente idade do último accepted antes de declarar ready. - Separe
real_relay_readyde synthetic readiness; só o primeiro prova receipt terminal autenticado originado por client. - Em protecting, degraded ou attention, examine buckets agregados e transporte sem pedir logs de usuário.
Mapa do código
Os caminhos são relativos ao repositório para continuar válidos após mover hosts. Backend e Nodeboard são separados e consomem apenas metadata owner-scoped segura para privacidade.
| Camada | Caminho do repositório | Papel |
|---|---|---|
| API relay Rust | crates/aeronyx-server/src/api/chat_peer.rs | Autentica envelopes e aplica loop, replay, freshness, rate, quarantine, retry e terminal receipt. |
| Rust PeerStore | crates/aeronyx-server/src/services/peer_store.rs | Armazena contadores limitados, peer health, readiness e classificação de proofs. |
| API health Rust | crates/aeronyx-server/src/api/vpn_health.rs | Publica health JSON local e privado. |
| Reporter Rust | crates/aeronyx-server/src/management/reporter.rs | Transporta status agregado no heartbeat. |
| Observabilidade backend | privacy_network/api/vpn_observability.py | Retorna metadata owner-scoped ao console. |
| Tipos Nodeboard | types/index.ts | Define tipos blind relay e peer health. |
| Detalhe e i18n Nodeboard | app/dashboard/nodes/[id]/page.tsx and lib/i18n/index.ts | Exibe Security / Relay Protection com texto localizado de privacidade. |
Base para roteamento multi-hop
Multi-hop exige resistência a replay, contenção de loops, retries limitados, quarentena e evidência não confundida com tráfego real. Esta proteção sustenta criptografia em camadas e diversidade de rotas sem enfraquecer o invariante cego.
Regras de desenvolvimento
Trate todo campo novo como revisão de privacidade. Uma métrica deve responder sobre confiabilidade do nó sem identificar payload, emissor, receptor, rota, endpoint ou conversa.
- Manter
payload_b64opaco em todo caminho relay. - Adicionar somente contadores agregados ou reason buckets limitados.
- Nunca juntar contadores com rotas, endpoints, usuários, receivers ou metadata de mensagem.
- Excluir probes sintéticos de totais de mensagens, pacotes e bytes criptografados.
- Atualizar tests Rust, tipos Nodeboard e todos os idiomas quando a semântica mudar.