Resumo

  • A compressão bidirecional começava logo após o CRLF da resposta 206 e permanecia até o encerramento da conexão.
  • Depois desse ponto, STARTTLS, AUTHINFO e MODE READER ficavam indisponíveis; TLS, autenticação e compressão só podiam coexistir nessa ordem.
  • Como a compressão precedia SASL e TLS no envio, dicionários, comprimentos observáveis, flush e corrupção passaram a integrar a superfície de segurança.

O atalho que exigia uma nova conexão

O primeiro cliente não usou uma palavra desconhecida. COMPRESS DEFLATE havia sido anunciado, e 206 confirmou o sucesso. A surpresa estava no custo da confirmação: aquela conexão já não podia ser remontada para inserir TLS ou credenciais antes do compressor.

Não existia uma operação inversa. Para abandonar a compressão, o cliente enviava QUIT e abria outra conexão. O reinício não era punição; era a única forma inequívoca de ambos os lados voltarem a concordar sobre como interpretar o próximo byte.

RFC 8054 transformou o caminho correto em uma sequência explícita. Quem quisesse as três funções deveria executar STARTTLS, depois AUTHINFO e, por fim, COMPRESS.

Uma linha de sucesso fora do fluxo comprimido

O texto de 206 Compression active ainda era uma resposta NNTP comum. A compressão entrava em vigor imediatamente depois do CRLF que a encerrava, para cliente e servidor. Assim, a linha anunciava a transformação sem já depender dela.

O cliente não podia colocar COMPRESS em pipeline. Precisava receber a decisão antes de mandar o próximo comando. Se houvesse recusa, continuaria com linhas normais; se houvesse sucesso, cada octeto seguinte pertenceria ao fluxo comprimido.

Nome malformado, algoritmo não aceito e incapacidade de ativar tinham respostas próprias e não atravessavam a fronteira. O sucesso era diferente: mudava o estado compartilhado pelo restante da vida da conexão.

Uma transformação abaixo de todos os comandos

Mecanismos anteriores e não padronizados comprimiam respostas específicas do servidor. Eles não reduziam o tráfego no sentido contrário e multiplicavam variantes. RFC 8054 colocou uma única camada sem perdas sob todas as mensagens NNTP subsequentes.

Comandos repetidos, listas longas, cabeçalhos e corpos de texto podiam explorar repetição. A seção informativa da RFC encontrou ganhos muito diferentes conforme o conteúdo: respostas multilinha podiam encolher bastante, enquanto respostas curtas ou anexos já codificados ofereciam menos. Isso não estabelece um índice universal nem adoção atual.

DEFLATE, de RFC 1951, tornou-se o único algoritmo definido e obrigatório na extensão. Cada remetente escolhia parâmetros razoáveis no próprio sentido, e o descompressor remoto se ajustava. A camada era bilateral; a política de CPU e razão de compressão não precisava ser igual.

As capacidades desapareciam quando deixavam de ser possíveis

Com uma camada de compressão ativa, o servidor removia COMPRESS e STARTTLS da lista. Outra compressão ou uma negociação TLS posterior recebia 502. MODE READER também não podia ser executado depois.

RFC 3977 define capacidades como estado presente, sujeito a mudanças durante uma sessão. Como compressão pode enfraquecer a confidencialidade do ciframento, RFC 8054 proíbe confiar em uma lista guardada de outra conexão.

O desaparecimento distinguia suporte do servidor e alcançabilidade na conexão. A implementação podia conhecer TLS e COMPRESS, mas o estado atual já havia fechado aquelas transições.

A senha precisava passar antes da memória

Compressão compara o texto novo com o histórico. A criptografia esconde o conteúdo, mas um observador ainda pode ver o tamanho produzido. Se um adversário controla parte do texto e mede os comprimentos, coincidências com um segredo podem alterar o resultado. CRIME e BREACH são exemplos citados pela RFC.

Por isso, autenticação não podia acontecer depois de COMPRESS. Para um cliente ainda anônimo, o servidor omitiria AUTHINFO ou o mostraria sem argumentos utilizáveis. Um comando de autenticação sintaticamente válido seria recusado com 502.

RFC 4643 define a autenticação de NNTP. COMPRESS não autentica; apenas impede que a credencial seja introduzida tarde demais em um contexto cujo comprimento comprimido será transmitido.

Três camadas mantiveram três responsabilidades

RFC 4642 define a transição TLS. Ela protege o transporte, mas não concede automaticamente os direitos de uma conta. AUTHINFO identifica o sujeito aceito pelo servidor, mas não cifra. COMPRESS muda a representação, mas não faz nenhum dos dois.

No envio, os dados eram comprimidos primeiro, passavam por uma camada SASL existente e então por TLS. Na recepção, a sequência era invertida. O compressor precisava atuar antes da criptografia para enxergar repetição.

Assim, a ordem operacional não misturava autoridades. Primeiro vinha a proteção do canal, depois a identidade, e só então a decisão de permitir que uma memória de padrões processasse o restante da sessão.

O dicionário também separava domínios

Material público conhecido e artigos confidenciais não deveriam compartilhar a mesma história comprimida sob uma camada segura. Uma entrada pública controlada pelo adversário poderia fornecer a comparação para medir um segredo.

A RFC também recomenda evitar, quando possível, que dois artigos confidenciais distintos usem o mesmo dicionário. Limpar o histórico DEFLATE é uma das mitigações. A medida limita quais dados anteriores podem influenciar o próximo comprimento; não altera identidade ou chaves.

Compressão sob criptografia não foi declarada sempre proibida. A norma preferiu impedir a ativação automática sem escolha informada. A decisão depende do conteúdo, da capacidade de influência do observador e das fronteiras do dicionário.

Um fluxo corrompido não podia ser adivinhado

Todo dado entregue ao compressor precisava aparecer na saída e ser corretamente liberado para descompressão completa. O remetente podia variar o nível diante de conteúdo pouco compressível, mas não deixar uma interação presa no buffer.

Ao receber dados comprimidos inválidos ou corrompidos, a ponta fechava imediatamente a conexão. Não procurava uma próxima linha aparentemente válida. Depois que os dicionários divergem, uma coincidência de sintaxe não restaura o histórico perdido.

Reconectar criava um ponto inicial verificável. Tanto para desligar a compressão quanto para se recuperar de corrupção, o protocolo atribuiu autoridade ao novo começo, não à tentativa de adivinhar o fluxo antigo.

Menos bytes exigiam uma sequência atribuível

O registro de parâmetros NNTP da IANA registra COMPRESS e DEFLATE. Ele estabelece nomes comuns e referências, não implantação, desempenho ou segurança de uma configuração.

A camada geral simplificou o protocolo e aproveitou redundância nos dois sentidos. Em troca, um sucesso passou a retirar opções futuras e a ligar o tratamento de segredos à ordem.

A contribuição histórica foi reconhecer que uma otimização com memória muda a superfície de confiança. A compressão precisava chegar por último porque, depois de começar a lembrar a conversa, já não podia receber com segurança decisões e credenciais que deveriam ter vindo antes.

Fontes