Resumo

  • Depois de TLS e SASL, o XMPP substituía o fluxo XML sem enviar o fechamento normal </stream> e sem encerrar a conexão TCP subjacente.
  • Cada fluxo novo recebia cabeçalhos, ID e recursos compatíveis com a etapa atual; socket aberto, criptografia, autenticação do par, sucesso SASL, vínculo de recurso e entrega continuavam sendo fatos diferentes.

A conexão continuava, mas a conversa precisava se apresentar de novo

Um cliente abre um fluxo XMPP, recebe a oferta STARTTLS e conclui o handshake. Os próximos bytes já podem trafegar protegidos. Ainda assim, o protocolo não permite que o mesmo fluxo simplesmente atravesse a fronteira.

O iniciador envia um novo cabeçalho de fluxo pela conexão criptografada. Não manda antes a tag de encerramento do fluxo antigo. O servidor responde com outro cabeçalho, gera um ID novo e apresenta os recursos que fazem sentido depois de TLS.

O <success/> de SASL repete a forma, mas muda outra dimensão. O resultado favorável encerra a utilidade do fluxo que transportou as credenciais. O cliente abre um terceiro contexto no mesmo TCP; só então o servidor mostra os passos destinados a uma entidade autenticada.

O desenho preserva uma distinção rara em interfaces modernas. A continuidade física pode ser real sem tornar contínua a autoridade de tudo que apareceu antes.

Um TCP podia sustentar várias gerações XML

RFC 6120 trata o fluxo como objeto de aplicação. TCP é bidirecional; um fluxo XMPP, em sentido rigoroso, vai em uma direção. As duas entidades combinam fluxos opostos sobre o transporte.

Quando a negociação de um recurso exige reinício, as partes consideram o fluxo anterior substituído. Elas não o fecham pela gramática usual e não derrubam TCP. Reutilizam a conexão, possivelmente em um estado novo, e trocam cabeçalhos. O receptor deve criar um ID de fluxo diferente.

Chamar isso de reconexão confunde custos e evidências. Reconectar TCP cria outra associação de transporte. Reiniciar o fluxo limpa o contexto XML mantendo o caminho. Também não é retomada de mensagens: a regra não confirma entrega anterior, não ordena replay e não informa o que a aplicação remota fez.

Uma única conexão carregava, portanto, relógios diferentes: vida do TCP, entrada de TLS, desfecho SASL e geração do fluxo. Um campo único chamado connected não dizia em qual relógio o sistema estava.

Recursos anunciados valiam para aquela etapa

Stream features indicavam negociações obrigatórias e opcionais. Enquanto houvesse uma obrigatória, o iniciador ainda não estava liberado para o tráfego comum de estrofes. Uma lista vazia ou apenas voluntária indicava que a etapa podia ser considerada concluída.

A ordem TCP, TLS, SASL e XMPP criava dependências. O conjunto de mecanismos SASL podia depender de TLS. O vínculo de recurso para clientes só surgia após a autenticação. Assim, repetir sem alteração a oferta antiga seria atribuir ao novo estado uma permissão produzida sob condições diferentes.

O servidor precisava enviar recursos atualizados a cada novo fluxo. Essa atualização transformava a lista em resposta contextual: o que este par deve ou pode negociar agora. Ela não era um inventário eterno da implementação.

A ausência também tinha alcance limitado. Um recurso podia ainda não estar disponível ou já ter sido consumido. RFC 7590 acrescenta que um atacante pode remover a oferta STARTTLS ou o marcador required. A captura mostra o que chegou por um caminho; não prova sozinha o que o servidor sabe fazer.

O passado pré-TLS não ganhou proteção retroativa

Quando TLS termina com sucesso, RFC 6120 obriga os dois lados a descartar informações acima de TCP obtidas de modo inseguro antes da proteção. Exemplos incluem endereço from, ID do fluxo e recursos anunciados anteriormente.

Sem essa limpeza, um intermediário poderia alterar uma afirmação no trecho aberto e vê-la sobreviver dentro do canal cifrado. O novo fluxo não era cerimônia. Ele obrigava endereços, identificadores e ofertas relevantes a reaparecer sob o regime que lhes daria valor.

Mesmo assim, criptografar não resolve automaticamente a identidade do par. Versão e parâmetros TLS, credencial apresentada, nome verificado, resultado da validação e decisão de política permanecem separados. RFC 7590 endurece as práticas do XMPP, exige autenticação de servidores por clientes e de clientes por servidores e recomenda fortemente autenticação entre servidores. Também reconhece como caso mais fraco a conexão cifrada sem autenticação.

Um fluxo post-TLS prova que a transição ocorreu. A identidade exige a prova específica da validação.

SASL confirmava credenciais, não o direito a qualquer ação

RFC 4422 define SASL como uma estrutura de mecanismos substituíveis. Distingue identidade de autenticação, identidade de autorização, resultado do intercâmbio e eventual camada de segurança de dados. Os mecanismos não entregam todos as mesmas propriedades.

No perfil XMPP, o sucesso SASL exige outro fluxo sobre o TCP existente. O servidor devolve um ID novo e os recursos da fase autenticada. Mas autenticação bem-sucedida não completa todo o estabelecimento da sessão de cliente.

Ainda falta o vínculo de recurso. Ele associa um resourcepart à conta e ao fluxo, diferenciando conexões simultâneas. O servidor só anuncia essa possibilidade depois de SASL.

Antes do vínculo, se o cliente mandar uma estrofe para alguém além do servidor ou da própria conta, o servidor não deve processá-la e precisa encerrar o fluxo com not-authorized. O transporte pode estar vivo, TLS protegido e SASL aprovado; a autorização operacional ainda está incompleta.

Essa separação evita transformar a autenticação em um passe universal. Ela também impede que o ID de fluxo seja confundido com identidade de usuário ou que uma estrofe aceita localmente vire comprovante de efeito remoto.

O vínculo encerrava a preparação sem pedir novo fluxo

Depois do resource binding, RFC 6120 proíbe reiniciar o fluxo. Essa frase negativa impede uma leitura simplista: nem todo êxito destrói seu contexto.

TLS e SASL mudam as condições de segurança ou identidade sob as quais as informações anteriores foram obtidas. O vínculo já ocorre dentro do fluxo autenticado; completa o endereçamento sem invalidar seus cabeçalhos.

Uma implementação não pode, portanto, codificar apenas “se sucesso, reinicie”. Deixar de reiniciar após TLS ou SASL viola a sequência. Reiniciar após binding também pode violá-la. O estado precisa expressar o motivo da fronteira.

Para diagnóstico, isso gera uma matriz clara. TCP aberto não equivale a TLS. TLS não equivale a par autenticado. SASL bem-sucedido não equivale a recurso vinculado. Recurso vinculado não equivale a entrega. Cada transição tem fonte, dono e erro próprios.

A norma de 2011 explicitou uma ideia que já existia em 2004

RFC 3920, de outubro de 2004, já mandava abrir um novo fluxo depois de TLS e do <success/> SASL. Também registrava a ordem TCP, TLS, SASL e XMPP, considerando o fluxo antigo encerrado nesses pontos sem exigir sua tag final.

RFC 6120 substituiu o documento em 2011 e apresentou a arquitetura com mais clareza: o fluxo é substituído, a conexão é reutilizada, um novo ID é gerado e os recursos são reenviados. Não houve uma passagem histórica de continuidade para reinício; houve a consolidação de várias sequências numa regra geral de negociação em estágios.

RFC 7590 reforçou em 2015 a operação de TLS diante de ameaças mais maduras. Seguir a sequência de fluxo e escolher criptografia, validação e resistência a downgrade adequadas continuam sendo avaliações diferentes.

O legado é uma forma cuidadosa de economizar estado. O transporte caro permanece quando ainda serve. O contexto que perdeu sua base de confiança não recebe permanência só porque viaja pela mesma conexão.

Fontes