Resumo

  • Um Exported Authenticator reúne Certificate, CertificateVerify e Finished com material derivado de uma conexão TLS/DTLS estabelecida. Prova posse de outra identidade X.509 naquela conexão, sem alterar o estado TLS.
  • Não traz horário intrínseco nem número de stream. O contexto único limita replay dentro da conexão; operação, instante efetivo e permissão dependem de vínculo aplicativo separado.
  • A operação segura separa pedido, conexão, criptografia, política do certificado, recusa vazia autenticada e autorização. Um terminador TLS rompe o vínculo mesmo que o certificado pareça igual nos dois lados.

A validação passou; a atribuição histórica não

A conexão abriu às 13h58 sob a identidade comum do handshake. Cinco minutos depois, chegou a resposta a um pedido de identidade adicional e as verificações do RFC 9261 foram concluídas. O erro veio quando o serviço transformou prova válida em a conexão sempre pertenceu à nova identidade.

Authenticators são independentes e unidirecionais; sua criação ou validação não muda explicitamente o estado TLS. A prova pode apoiar uma transição prospectiva para uma operação futura nomeada. Não pode criar timestamp, escolher stream ou autenticar trabalho anterior.

O objeto combina mensagens conhecidas sem abrir novo handshake. Certificate apresenta a cadeia X.509, CertificateVerify prova a chave privada e Finished protege a transcrição com chave derivada da conexão. Não há framing de record TLS; o transporte ocorre na camada de aplicação em canal com proteção equivalente.

No TLS 1.3 usa-se exporter_master_secret, nunca o segredo early. No TLS 1.2 são necessários PRF e Extended Master Secret. O resultado é estreito: este endpoint provou esta identidade nesta conexão. Não prova outra conexão, o início da sessão, todos os streams ou permissão de negócio.

A política X.509 continua separada. Assinatura e Finished corretos não corrigem expiração, emissor recusado, nome inadequado ou identidade sem papel autorizado.

O contexto organiza replay, não o negócio

certificate_request_context tem até 255 octetos, deve ser único na conexão entre os tipos de pedido do RFC 9261 e deveria ser imprevisível. A resposta ecoa esse valor, impedindo que uma prova aceita satisfaça outro pedido local.

Ele não é ID global, relógio, conta ou stream. Gateway, serviço de identidade e worker podem colidir se mantiverem inventários separados. O dono da unicidade precisa enxergar a conexão inteira. Contador previsível e gerador aleatório restaurado de snapshot exigem testes diferentes.

Registre hash do contexto, época do gerador, conexão, extensões, alvo e hora local; nunca exporter secrets ou chaves privadas. Clientes precisam de pedido prévio; servidores podem provar espontaneamente. Essa assimetria deve aparecer nas métricas.

Uma conexão multiplexada não determina o alcance

HTTP/2 reúne muitos streams. O RFC 9001 proíbe post-handshake client authentication de TLS no QUIC porque o pedido TLS não se correlaciona com segurança ao evento aplicativo. Exported Authenticators movem pedido e prova para uma camada capaz de expressar a correlação, mas não a inventam.

O protocolo superior deve dizer que contexto X vale para stream 41, operação Y, somente após Z. O padrão seguro é futuro e mínimo. Filas anteriores e streams vizinhos mantêm a identidade original. Se houver elevação da conexão inteira, ordem, barreira e rollback precisam ser explícitos.

Recebimento, validação e efeito são três tempos. O autenticador não contém hora de criação. Um único authenticated_at esconde atraso, replay e reordenação.

O proxy cria outra conexão

Handshake Context nasce da conexão inicial. Prova criada em A falha quando validada contra B. Um proxy que termina TLS possui dois contextos, mesmo com nomes ou certificados iguais. Aceitar pela aparência do certificado eliminaria a principal propriedade do mecanismo.

Cruzar o terminador exige delegação própria, com emissor, audiência, validade e custódia, ou duas provas independentes ligadas por outra decisão. Reconexão e failover também encerram a fronteira antiga; o privilégio deve ser provado novamente ou reduzido.

Recusa autenticada é um resultado próprio

Quem não possui identidade adequada ou não quer apresentá-la pode devolver empty authenticator: Finished permanece, Certificate e CertificateVerify somem. O MAC autentica a recusa, mas não produz identidade válida.

Separe esse estado de silêncio, bytes malformados, assinatura ruim e cadeia rejeitada. A aplicação pode continuar com menos privilégio ou parar. Repetição infinita transforma recusa legítima em loop de negação de serviço.

Evidência em quatro livros

Registre conexão; pedido e contexto; validação criptográfica e X.509; decisão de autoridade. A última deve nomear operação/stream, privilégio anterior e novo, momento efetivo, expiração e rollback.

Taxa de sucesso isolada engana. Pode subir durante reutilização de contexto e elevação excessiva. Uma falha por conexão diferente pode provar que a fronteira funcionou.

IANA registra labels, e OpenSSL/BoringSSL mostram o substrato exporter. Isso não prova implantação do RFC 9261. A realidade exige execução reconstruível do pedido à decisão.

Fontes