A última linha sem compressão: como o IMAP mudou cada byte que veio depois

Resumo

• O IMAP COMPRESS só ativava DEFLATE depois de um OK etiquetado: o servidor comprimia após o CRLF final da resposta e o cliente começava no comando seguinte.
• A memória que encurtava comandos, cabeçalhos e texto também prendia os bytes futuros a um estado oculto. A orientação posterior mostrou riscos de comprimento observável, sem provar uma exploração específica do IMAP COMPRESS.

A mesma corrente ganhou outra leitura depois do CRLF

O IMAP já construía a conversa com comandos etiquetados, dados sem etiqueta e resultados finais que repetiam a etiqueta do cliente. O RFC 4978 não criou uma nova espécie de resposta. O servidor anunciava COMPRESS=DEFLATE, o cliente enviava COMPRESS DEFLATE, e os conhecidos OK, NO e BAD davam o veredito.

A aparência comum escondia uma espera obrigatória. O cliente não podia mandar outro comando enquanto o resultado estivesse pendente. Com OK, comprimia o primeiro comando posterior. O servidor ainda enviava a própria resposta de sucesso sem compressão, mas ligava o codificador imediatamente após o CRLF que encerrava a linha. Uma recusa mantinha a leitura anterior nas duas direções.

Uma posição exata do fluxo passou a exercer autoridade. Um cliente precoce entregaria texto aberto ao descompressor. Um servidor atrasado faria bits comprimidos parecerem gramática IMAP. O TCP poderia entregar tudo, em ordem e sem perda; ainda assim, a sessão falharia porque os extremos atribuiriam significados diferentes aos mesmos bytes.

A capacidade concedia permissão, não resultado

O anúncio só afirmava que o servidor conhecia o algoritmo. Não garantia redução para aquela caixa postal, custo razoável de CPU nem confidencialidade. Cada remetente escolhia seu esforço de compressão; o outro extremo precisava decodificar a corrente correspondente.

As recusas preservavam esse significado estreito. Se o mesmo mecanismo já estivesse ativo em outra camada, o servidor podia responder NO com COMPRESSIONACTIVE. Tentar ativar a extensão duas vezes era inválido. Duas superfícies capazes de negociar uma transformação não autorizavam duplicar o mesmo estado.

Também não havia um único dicionário para toda a conexão. Comandos repetidos formavam o histórico do cliente para o servidor. Respostas, nomes de campos e mensagens formavam o histórico do sentido oposto. Cada emissor lembrava os bytes que ele próprio produzia.

A ordem das camadas não era a ordem dos pedidos

Uma sessão ainda podia ganhar uma camada de segurança SASL ou TLS. O envio seguia uma pilha fixa: primeiro COMPRESS, depois assinatura ou criptografia SASL quando presentes e, por fim, TLS. A recepção desfazia as operações em ordem inversa.

Essa pilha não mudava se o cliente tivesse solicitado as funções em outra sequência. A cronologia da negociação e a ordem de transformação eram fatos diferentes. COMPRESS precisava participar da máquina de estados do IMAP, em vez de fingir que era um tubo invisível.

O núcleo atual do IMAP4rev2 conserva a disciplina geral nas transições de segurança: a resposta bem-sucedida marca o ponto exato de início da nova camada. Uma conexão duradoura pode trocar representação ou proteção somente quando ambos os lados reconhecem uma fronteira única.

Repetição tornava o histórico útil

O IMAP oferecia material favorável. O cliente repetia poucos verbos. O servidor repetia formas de resposta e nomes de cabeçalho. Mensagens de uma conversa recitavam trechos anteriores. Um histórico crescente trocava sequências repetidas por referências curtas.

Anexos quebravam o padrão. Um arquivo já compactado ou uma imagem JPEG podia quase não encolher, expulsar vocabulário útil e gastar CPU enquanto o compressor aprendia dados que não voltariam. O RFC discutia limpezas completas perto de literais grandes e esforço menor diante de formatos aparentemente incompressíveis. Eram escolhas locais, não novos comandos.

A proximidade com a aplicação era a vantagem. O IMAP sabia se os próximos bytes eram sintaxe, cabeçalhos, texto ou um literal. Esse conhecimento melhorava a economia e também tornava a aplicação responsável pelo contexto conservado.

A criptografia não eliminava o comprimento

Em 2007, a seção de segurança do RFC 4978 apenas remetia às considerações contemporâneas sobre compressão TLS. Ataques estudados depois mudaram a avaliação. CRIME e trabalhos relacionados mostraram que o conteúdo pode estar cifrado enquanto seu tamanho permanece observável. Se um segredo e texto influenciado por um atacante entram no mesmo histórico, tentativas repetidas podem revelar quando uma suposição se aproxima do segredo.

Os casos resumidos pelo IETF tratam de TLS e da Web. Não comprovam um ataque ao IMAP COMPRESS nem vulnerabilidade universal. Comprovam que “comprimir e depois cifrar” não encerra sozinho a análise de sigilo.

A prática TLS atual desaconselha a compressão comum no TLS 1.2, exceto para aplicação demonstrada como segura e ainda sob extrema cautela; o TLS 1.3 a retirou. A mesma orientação alerta que compressão acima do TLS pode criar vazamentos que o TLS não corrige. Conhecer melhor o protocolo aumenta o ganho e a obrigação de decidir quais entradas podem compartilhar memória.

Estado escondido precisava de responsável

As mensagens lógicas continuavam sendo IMAP, mas os bytes codificados passaram a depender do passado. O benefício existia apenas enquanto os extremos concordassem sobre ativação, direção, algoritmo e contexto. Falha de decodificação, esgotamento de recursos ou suspeita de vazamento não apareciam de modo simples numa captura cifrada.

A lição duradoura não é uma proibição vaga. É preciso nomear o contexto, quem influencia suas entradas, quem observa o tamanho de saída, quanto tempo o histórico vive, quais recursos a expansão pode usar e como desligar a função sem corromper a sessão. Uma otimização que se lembra já é uma máquina de estados.

Fontes e limites

O formato DEFLATE está no RFC 1951. A capacidade IMAP, a fronteira, a ordem das camadas e os ajustes vêm do RFC 4978. O RFC 7457 resume a classe de ataques; o RFC 9051 define o núcleo atual do IMAP; o RFC 9325 traz a orientação TLS vigente; e a capacidade permanece no registro IMAP da IANA. Essas fontes não medem adoção atual nem relatam uma invasão específica por IMAP COMPRESS.