Resumo

  • ALPN colocou a escolha do protocolo de aplicação dentro da negociação inicial do TLS: o cliente oferece identificadores em ordem, e o servidor seleciona um único valor comum segundo sua própria preferência.
  • A seleção pertence à conexão, não à sessão retomável. O conteúdo ALPN antigo é irrelevante numa nova negociação inicial, ainda que o mesmo tíquete, endereço e certificado participem dela.
  • TLS 1.3 proíbe retransmissão automática de dados antecipados se o novo ALPN mudar. Igualdade de ALPN preserva a gramática, mas não autoriza repetição, origem ou operação.

Os bytes saíram antes da resposta nova

0-RTT permite que um cliente elegível envie dados durante a retomada, antes de receber toda a resposta da nova negociação inicial. A vantagem é concreta: uma aplicação pode começar sem esperar outra travessia da rede. A dívida também é concreta: o conteúdo foi preparado sob expectativas herdadas de uma conexão anterior.

Se a nova conexão escolher outra gramática, repetir automaticamente esses bytes troca o significado antes de perguntar à aplicação. RFC 8446 impede esse salto: a implementação TLS não pode retransmitir dados antecipados automaticamente sem que a conexão negociada selecione o mesmo protocolo ALPN.

“Mesmo protocolo” não significa “mesma operação”. Uma requisição pode já ter sido processada, um token pode ter expirado e um método pode não ser idempotente. A aplicação ainda decide a repetição. A regra TLS oferece uma barreira mais estreita: se até a gramática mudou, a camada inferior não tem base para reenviar coisa alguma.

O caso revela a natureza do tíquete. Ele pode ajudar a retomar a criptografia. Não guarda autorização de negócio, estado exato do serviço interno nem o protocolo que a próxima conexão será obrigada a falar.

Uma propriedade da conexão, não da sessão

RFC 7301 define ALPN com uma frase decisiva: a extensão estabelece uma propriedade da conexão, não da sessão. Na retomada ou no uso de tíquetes de sessão, o conteúdo anterior é irrelevante; contam apenas as mensagens da nova negociação inicial.

Isso permite que cliente e servidor mudem. O cliente pode retirar uma gramática insegura. O servidor pode promover uma nova versão. Um balanceador pode entregar o tíquete a outro nó. Uma conexão retomada não precisa reproduzir a seleção antiga para ser válida.

Obrigar o tíquete a carregar o resultado anterior transformaria uma otimização criptográfica em aprisionamento da aplicação. Também esconderia divergências: nós diferentes pareceriam coerentes porque o passado decidiria por todos, mesmo quando a preferência atual não tivesse convergido.

A observação correta compara as duas conexões. O vínculo do tíquete explica por que são relacionadas; oferta, seleção, nó e política explicam por que podem ser diferentes.

Uma porta compartilhada precisava de acordo antes dos dados

Os números de porta funcionaram durante muito tempo como indício da aplicação. Com várias gramáticas protegidas por TLS no mesmo ponto terminal, especialmente na porta 443, o indício deixou de ser definitivo. Negociar depois do TLS custaria uma rodada adicional. Tentar reconhecer os primeiros bytes entregaria dados a interpretadores concorrentes antes de existir acordo.

ALPN usa a negociação inicial que já ocorreria. ClientHello leva uma lista de nomes opacos e não vazios. O servidor responde com uma única escolha comum. Quando começam os dados da aplicação, cada lado sabe qual interpretador deve recebê-los.

RFC 8170 registra o papel de HTTP/2 nessa transição. A forma protegida adotou ALPN para evitar nova rodada; a atualização de protocolo ficou ligada à forma sem TLS. ALPN tornou-se o caminho principal para versões HTTP futuras.

Isso difere de mudar uma conexão HTTP/1.1 com 101, que confirma a troca de protocolo. Ali existe uma conversa de aplicação antes da troca. Aqui, a gramática é escolhida durante o estabelecimento protegido, antes de uma requisição.

A lista do cliente delimitava, mas não governava

O cliente ordena seus identificadores por preferência. O servidor mantém outra ordem e escolhe seu valor preferido dentro da interseção. A primeira posição do cliente não é ordem administrativa para o servidor.

As competências se completam. O cliente recusa qualquer gramática que não ofereceu. O servidor conserva a escolha local entre as que ambos entendem. A resposta contém um valor e passa a ser definitiva para aquela conexão; anunciar um protocolo e transmitir outro viola o contrato.

Sem interseção, RFC 7301 exige o alerta fatal no_application_protocol. Um recuo silencioso poderia melhorar a taxa aparente de sucesso, mas deixaria os dois interpretadores sem um fato compartilhado. A conexão estaria protegida criptograficamente e indefinida semanticamente.

RFC 9325 exige suporte a ALPN em implementações TLS modernas e recomenda aplicação estrita da lista e do erro. A preocupação inclui ataques entre protocolos: bytes destinados a um serviço podem produzir efeitos inesperados quando outro os aceita.

ALPN não autentica uma origem nem autoriza o usuário. Ele garante algo anterior: o servidor não pode chamar de acordo uma gramática que o cliente nunca propôs.

TLS 1.3 mudou a superfície visível

No desenho original, a oferta do cliente e a seleção do servidor apareciam em ClientHello e ServerHello. RFC 7301 reconhecia que o marcador ficava visível, o que ajudava equipamentos quando a porta já não identificava a aplicação, mas também podia permitir a criação de perfis.

TLS 1.3 moveu a resposta do servidor para EncryptedExtensions. Essa é a primeira mensagem do servidor protegida pelas chaves da negociação inicial. A oferta continua no ClientHello comum. Portanto, não é correto dizer que ALPN é sempre público nem que TLS 1.3 esconde toda a negociação.

Os registros devem indicar versão, direção e ponto de observação. Um sensor externo pode ver a oferta e não a seleção; o ponto terminal pode ver ambas. Perder essa distinção cria falsos incidentes ou promessas de privacidade que a conexão não cumpre.

HTTP/2 ainda confirmou a escolha

RFC 9113 reserva h2 para HTTP/2 sobre TLS e exige ALPN. h2c, ligado à forma sem TLS, não pode ser oferecido ou selecionado no ALPN TLS.

Depois da negociação, cada ponta envia um preâmbulo de conexão. A seleção indica qual gramática pode começar; o preâmbulo confirma que a aplicação realmente começou nela e estabelece SETTINGS. Um nó de borda pode escolher h2 corretamente e ainda encaminhar o fluxo ao serviço interno errado. Só a combinação entre a negociação inicial e o preâmbulo mostra a fronteira rompida.

ALPN também não substitui 421, autorização HTTP ou validação de certificado. Ele identifica o protocolo da conexão. A origem atendida e o direito de executar uma operação continuam sendo decisões posteriores.

Separar essas provas impede que um indicador de desempenho vire uma credencial universal.

QUIC vinculou aplicação e versão de transporte

RFC 9001 requer negociação autenticada do protocolo de aplicação em QUIC, normalmente com ALPN. Se nenhum protocolo for negociado, a conexão fecha imediatamente com o erro correspondente.

Uma aplicação também pode restringir as versões QUIC que aceita. O servidor deve escolher um protocolo compatível com a versão selecionada pelo cliente, e o cliente rejeita combinação incompatível. Não basta encontrar o mesmo nome nas duas listas; o transporte concreto precisa poder sustentar seu significado.

Essa disciplina mantém o erro antes do estado de aplicação. Cliente, servidor e versão do transporte formam a interseção real. Nenhum tíquete antigo amplia essa interseção.

Registro não era censo

O registro IANA de extensões TLS e identificadores de protocolo ALPN mantém o tipo de extensão 16 e os identificadores opacos sob revisão especializada. Há entradas como http/1.1, h2, h3 e a reserva h2c com proibição no contexto TLS.

Uma entrada prova a atribuição dos bytes e a referência normativa. Não prova oferta por clientes, seleção por servidores, participação no tráfego ou segurança da implementação. Essas perguntas exigem registros das negociações iniciais e evidências da aplicação.

O mesmo cuidado vale ao tíquete. Sua presença prova que algum estado de retomada foi apresentado; aceitação prova apenas o que a política TLS permite reaproveitar. O protocolo precisa nascer novamente na conexão.

Selecionar uma linguagem não autorizava o interlocutor

Há uma sequência tentadora de atalhos. O endereço respondeu; o certificado foi aceito; o tíquete funcionou; ALPN escolheu h2. Logo, o ponto terminal estaria autorizado a atender qualquer origem coberta e qualquer requisição compatível com HTTP/2. Cada premissa oferece evidência real, mas a conclusão combina decisões que pertencem a superfícies distintas.

O endereço demonstra que o destino pode ser alcançado naquele caminho. A validação do certificado demonstra identidade conforme a política de confiança do cliente. O tíquete participa da retomada segundo regras TLS. ALPN escolhe o interpretador da conexão. Nenhum deles, isolado ou em conjunto automático, descreve locatário, serviço interno, recurso ou permissão do usuário.

Essa separação importa em infraestrutura compartilhada. Dois nós podem usar o mesmo certificado e aceitar o mesmo tíquete, mas manter preferências ALPN diferentes durante implantação gradual. Um terminador pode selecionar h2 e encaminhar para um serviço interno que só compreende HTTP/1.1. Uma conexão HTTP/2 válida pode receber 421 porque o contexto não tem autoridade para responder pela origem solicitada. São defeitos e recusas diferentes, que exigem registros diferentes.

O modelo de evidência deve acompanhar a ordem real: estabelecimento de transporte, identidade TLS, oferta e escolha ALPN, primeiro preâmbulo, seleção interna de serviço, origem e autorização da operação. Um painel que resume tudo como “conexão segura” reduz trabalho de leitura e aumenta o risco de atribuir autoridade à camada errada.

Também não se deve tratar a preferência do servidor como inventário de capacidade. Um nó pode suportar h2 sem escolhê-lo para determinado conjunto de clientes; outro pode anunciar a escolha e estar com a rota interna incompleta. A oferta e a seleção demonstram um acordo no fio. A execução precisa de sua própria prova.

Por isso ALPN foi útil precisamente por não resolver tudo. O protocolo eliminou a ambiguidade do interpretador antes dos dados. Deixou autenticação, roteamento e autorização para os mecanismos que possuem contexto suficiente. Expandir sua interpretação depois do fato seria desfazer essa disciplina.

Fontes

Essas fontes definem padrões, recomendações e registros; não medem participação atual de tráfego ou adoção de produtos.