Resumo

  • NewSessionTicket entrega uma identidade PSK opaca para um handshake futuro. Sua aceitação liga criptograficamente uma conexão nova à negociação que produziu o ticket; não reabre o transporte antigo nem confirma que decisões de aplicação continuam atuais.
  • Vida útil, idade ofuscada, nonce, hash KDF, SNI, modo PSK e binder respondem a perguntas diferentes. Nenhum deles, isoladamente, prova autorização vigente, mesmo backend, aceitação de 0-RTT ou permissão para reutilizar uma decisão anterior.
  • Retomada defensável exige contrato de estado versionado, domínio limitado de chaves e serviços, decisão 0-RTT independente, revalidação de autoridade mutável e retorno observável ao handshake completo.

Quando o atalho recuperou informação demais

Seis horas após a emissão, uma mudança de região levou o cliente a outro nó. O ticket foi aberto, a PSK foi escolhida e o handshake terminou como retomado. Nesse intervalo, o sistema de identidade havia removido o papel administrativo.

A aplicação não consultou a fonte atual. Leu o papel guardado no estado protegido e transformou resumed=true em uma decisão de acesso. TLS não validou o papel; validou a posse de um segredo derivado do handshake anterior.

Dois relógios foram tratados como um. O relógio criptográfico ainda aceitava a PSK. O relógio da autorização já tinha expirado. Integridade preserva a origem de uma afirmação, mas não impede que uma afirmação verdadeira envelheça.

O ticket identifica uma nova PSK

TLS 1.3 substituiu os antigos mecanismos de sessão por uma troca PSK comum. Depois do Finished do cliente, o servidor pode enviar NewSessionTicket. Cada mensagem associa o valor opaco a uma PSK derivada do segredo de retomada e de um ticket_nonce exclusivo.

O valor pode ser uma chave para buscar estado no banco do servidor. Também pode carregar estado autocontido, cifrado e autenticado. Em ambos os casos, o protocolo enxerga uma identidade PSK, não a conexão antiga nem sua chave de tráfego.

Uma conexão pode produzir vários tickets para conexões paralelas ou corrida entre interfaces. Nonces diferentes geram PSK diferentes. O registro operacional precisa identificar emissão e época de chave; “mesma sessão” é uma descrição larga demais.

Retomar cria transcript, chaves de tráfego e números de registro novos. Socket, processo, transação, caminho de rede e memória da aplicação não voltam com o ticket.

A duração limita o cliente, não obriga o servidor

ticket_lifetime começa na emissão e não pode passar de sete dias. Zero significa descarte imediato. O cliente pode apagar antes, e o servidor pode aplicar duração menor.

O campo define até quando o cliente pode tentar. Não promete aceitação durante todo o intervalo. Rotação de chave, exclusão de banco, mudança de região, revogação ou nova política podem exigir handshake completo antes do prazo.

ticket_age_add soma um valor aleatório à idade para reduzir correlação passiva. O servidor subtrai esse valor e compara com o tempo decorrido. Uma cópia do ticket preserva a mesma conta; o mecanismo não é um token ativo de uso único.

Idade fora da tolerância afeta frescor e 0-RTT. O servidor pode negar dados antecipados e ainda aceitar retomada ordinária. Descriptografia, seleção PSK, retomada e aceitação antecipada precisam de campos separados.

O binder autentica a cadeia criptográfica

O ClientHello oferece identidades PSK e binders correspondentes. O binder conecta a PSK ao handshake atual e, pelo segredo de retomada, à negociação que a originou.

Essa prova estabelece continuidade de posse. Ela não confirma que conta, dispositivo, assinatura, rota de locatário ou risco permanecem iguais. Um fato autenticado pode estar vencido.

Em retomada autenticada por PSK, o servidor não envia novamente Certificate e CertificateVerify. O contexto anterior realiza esse trabalho criptográfico. A aplicação deve dizer quais fatos podem sobreviver e quais exigem consulta atual.

OpenSSL pode emitir tickets novos após autenticação de cliente pós-handshake. Eles ficam associados à identidade atualizada. Essa nova geração não atualiza retroativamente os tickets antigos.

O serviço pedido ainda é o atual

O ClientHello de retomada traz o SNI atual. O cliente só deve retomar se o certificado original for válido para esse nome e, em geral, deve manter o mesmo SNI. A aplicação deve receber o valor novo, não um nome histórico.

RFC 9525 também prende a identidade ao serviço solicitado no presente. SNI e ALPN ajudam a indicar nome e protocolo. Conseguir abrir um ticket não o torna válido para todos os nomes, locatários ou protocolos da infraestrutura.

Compartilhar a chave de envelope entre regiões melhora failover e amplia o conjunto de nós capazes de aceitar estado antigo. BoringSSL trata retomada entre nomes como política explícita. Capacidade de descriptografar não é autoridade automática.

O hash KDF é outra fronteira: a suíte nova deve usar o mesmo hash da origem. Compatibilidade criptográfica não congela autorização, roteamento ou parâmetros de aplicação.

Retomar não é executar cedo

O ticket pode carregar early_data e um limite de bytes. Isso permite ao cliente oferecer 0-RTT; não exige aceitação nem declara uma operação segura contra replay.

A telemetria deve separar ticket localizado ou aberto, PSK selecionada e 0-RTT aceito. Idade duvidosa, memória antirreplay ausente ou parâmetros diferentes podem negar o terceiro evento enquanto a retomada normal termina.

HTTP 425 atua numa camada posterior: a origem pode recusar a execução de uma requisição com proveniência antecipada. Ele não define a autoridade do estado no ticket. O problema deste relatório existe mesmo com 0-RTT completamente desligado.

QUIC acrescenta continuidade de parâmetros de transporte e aplicação. Ticket TLS válido não prova que limites QUIC ou SETTINGS HTTP/3 antigos continuam compatíveis.

O armazenamento escolhe o domínio de aceitação

Um ticket baseado em banco pode ser consumido, apagado e auditado sob uma autoridade central. Disponibilidade e replicação do banco tornam-se dependências. Atraso pode criar rejeição indevida ou nova aceitação.

Um ticket autocontido tolera melhor perda de nó. Porém, qualquer nó com a chave de envelope pode interpretar seu estado até a chave sair de uso. Distribuir chave também distribui capacidade de aceitar.

Não existe divisão simples entre “com estado seguro” e “sem estado inseguro”. Cada escolha desloca falhas. Banco central pode ficar indisponível; chave amplamente compartilhada pode prolongar estado velho; sobreposição de épocas pode esconder rotação incompleta.

OpenSSL expõe resultado de abertura, nome de chave, dados de aplicação, quantidade emitida e supressão. GnuTLS controla chaves e tickets adicionais. O código do BoringSSL gera nova idade e separa a condição de dados antecipados.

Essas superfícies provam que há meios de controle. Não provam configuração efetiva, claims carregados, rotação completa ou revalidação de autorização.

Levar referências versionadas

Identidade PSK, hash KDF, modo de retomada e referência limitada ao handshake autenticado são fatos criptográficos relativamente estáveis. Papel do usuário, confiança do dispositivo, assinatura e rota mudam.

A aplicação pode transportar ID de usuário e versão de autorização, consultando a versão atual antes de conceder acesso. Pode incluir rota com vencimento ou emitir nova geração quando a autenticação do cliente muda.

O desenho perigoso guarda a conclusão nua: administrator=true, “dispositivo confiável”, “assinatura ativa”. Cifra e autenticação impedem alteração clandestina. Não impedem que uma conclusão correta ontem seja falsa hoje.

EAP-TLS usa um ou mais tickets para retomar autenticação e respeita o teto de sete dias. O perfil deve definir o significado da retomada e seus eventos de invalidação. TLS transporta o estado; o sistema atual decide o acesso.

Evidência que resiste ao failover

Registrar correlação segura ou nome de chave, nó e região de emissão, horário, expiração declarada e efetiva, época, modelo de armazenamento, hash KDF e modo PSK. Na oferta, guardar idade, resultado de abertura, índice selecionado, SNI e ALPN atuais, resultado e fallback.

Registrar 0-RTT à parte: oferta, elegibilidade, aceitação ou rejeição, limite, estado antirreplay e decisão da aplicação. resumed=true nunca deve implicar early_data_accepted=true.

Para o estado de negócio, guardar versão do esquema, autorização, revogação, rota e fonte da decisão atual. A correlação une emissão e aceitação sem registrar ticket ou PSK.

Testes negativos incluem ticket expirado, validade encurtada, chave retirada, falha de autenticação, linha apagada, replay entre regiões, SNI/ALPN alterado, KDF incompatível e usuário revogado com ticket ainda aberto corretamente.

O fallback também precisa funcionar. Rejeição deve cair para handshake completo quando permitido. A resposta de emergência deve retirar uma época ou versão sem interromper serviços TLS não relacionados.

Fontes