Resumen

  • IMAP COMPRESS activaba DEFLATE solo después de un OK etiquetado: el servidor comprimía justo después del CRLF final de esa respuesta y el cliente comprimía su primer comando posterior.
  • La memoria que acortaba comandos, cabeceras y texto también hacía depender cada byte futuro de un contexto oculto. La guía de seguridad posterior explicó el riesgo de longitudes observables, pero no documentó un ataque específico contra IMAP COMPRESS.

Una respuesta terminó bajo una regla y el flujo siguió bajo otra

IMAP ya alternaba comandos etiquetados, datos no etiquetados y resultados finales que devolvían la etiqueta del cliente. RFC 4978 no inventó una respuesta nueva. El servidor anunciaba COMPRESS=DEFLATE, el cliente pedía COMPRESS DEFLATE y los conocidos OK, NO o BAD comunicaban la decisión.

La apariencia sencilla escondía una frontera estricta. El cliente no podía enviar nada más mientras esperaba el resultado. Ante OK, su siguiente comando debía salir comprimido. El servidor todavía enviaba sin compresión la respuesta de éxito, pero activaba el codificador inmediatamente después del CRLF que la cerraba. Un rechazo mantenía el modo anterior en ambas direcciones.

Así, una posición concreta del flujo adquiría autoridad. Un cliente adelantado entregaría texto plano al descompresor. Un servidor tardío haría que el cliente tratara bits comprimidos como gramática IMAP. TCP podría transportar todos los bytes en orden y sin pérdida; la sesión fallaría porque cada extremo les habría asignado un significado distinto.

La capacidad concedía permiso, no eficacia

El anuncio solo afirmaba que el servidor entendía el algoritmo. No prometía que ese buzón se reduciría, que el gasto de CPU sería razonable ni que el canal sería confidencial. Cada emisor escogía su propio esfuerzo de compresión y el receptor correspondiente debía poder decodificarlo.

Las negativas protegían ese alcance estrecho. Si la misma compresión ya estaba activa en otra capa, el servidor podía responder NO con COMPRESSIONACTIVE. Activar dos veces la extensión era inválido. Dos lugares capaces de negociar una transformación no autorizaban a apilar dos memorias iguales.

Además, no había un único diccionario para toda la conversación. Los comandos repetidos alimentaban la historia que viajaba hacia el servidor. Las respuestas, nombres de campos y mensajes alimentaban la historia contraria. Cada dirección tenía su propio estado.

El orden de las capas no imitaba el orden de los comandos

Una sesión también podía incorporar una capa de seguridad SASL o TLS. La salida seguía una secuencia fija: primero COMPRESS; después, la firma o el cifrado SASL si existían; por último, TLS. La recepción deshacía las operaciones en sentido inverso.

La secuencia era la misma aunque el cliente hubiera solicitado las funciones en otro orden. La historia de negociación no decidía el orden físico de las transformaciones. COMPRESS formaba parte de la máquina de estados de IMAP, no de un tubo transparente añadido sin contexto.

El núcleo vigente de IMAP4rev2 conserva la misma disciplina general en los cambios de seguridad: la respuesta exitosa fija el punto donde empieza la nueva capa. Una conexión duradera puede cambiar su protección o representación solo si ambas partes reconocen una frontera única.

La repetición daba valor al diccionario

IMAP ofrecía material excelente. El cliente repetía pocos verbos. El servidor repetía formas de respuesta y nombres de cabecera. Los hilos de correo volvían a citar frases enteras. Un historial progresivo podía sustituir esas repeticiones por referencias cortas.

Los adjuntos rompían el patrón. Un archivo ya comprimido o una imagen JPEG podía reducirse poco, expulsar vocabulario útil y consumir CPU mientras el compresor se adaptaba a datos que no volverían. La especificación describió vaciados completos alrededor de literales grandes y menor esfuerzo para formatos aparentemente incompresibles. Eran decisiones locales, no comandos visibles.

La ventaja de acercar la compresión a IMAP era precisamente ese conocimiento. La aplicación sabía si venían sintaxis, cabeceras, texto o un literal. Esa cercanía mejoraba el ahorro y, al mismo tiempo, transfería a la aplicación la responsabilidad por el contexto que conservaba.

El cifrado no borró la longitud

En 2007, la seguridad de RFC 4978 se despachó con una referencia a las consideraciones contemporáneas de compresión TLS. Los ataques analizados más tarde cambiaron la evaluación. CRIME y trabajos relacionados mostraron que el cifrado puede ocultar el contenido y dejar visible su longitud. Si un secreto y texto influido por un atacante comparten historial, variaciones repetidas pueden revelar cuándo una conjetura se parece al secreto.

Los casos resumidos por el IETF pertenecen a TLS y a la Web. No prueban una explotación de IMAP COMPRESS ni que todo contexto IMAP sea vulnerable. Sí muestran por qué comprimir antes de cifrar no cierra por sí solo el análisis de confidencialidad.

La práctica TLS actual desaconseja la compresión ordinaria de TLS 1.2 salvo una demostración excepcional de seguridad; TLS 1.3 la eliminó. También advierte que la compresión por encima de TLS puede crear filtraciones que la capa criptográfica no puede reparar. El conocimiento del protocolo produce mejores ratios, pero obliga a decidir qué datos pueden recordar juntos.

El estado oculto necesitaba dueño

Los mensajes lógicos seguían siendo IMAP, aunque sus bytes dependieran de bytes anteriores. El beneficio sobrevivía solo mientras ambos extremos coincidieran en activación, dirección, algoritmo y memoria. Los fallos de decodificación, el agotamiento de recursos o una sospecha de fuga no podían leerse directamente en una captura cifrada.

La lección no es una prohibición universal. Hay que nombrar el contexto, quién influye en sus entradas, quién observa el tamaño resultante, cuánto dura la historia, qué recursos puede consumir y cómo desactivarla sin corromper la sesión. Una optimización con memoria ya es una máquina de estados.

Fuentes y límites

El formato DEFLATE está en RFC 1951. La capacidad IMAP, la frontera, el orden de capas y los ajustes proceden de RFC 4978. RFC 7457 resume la clase de ataques; RFC 9051 define el núcleo IMAP actual; RFC 9325 contiene la guía TLS vigente; y la capacidad sigue en el registro IMAP de IANA. Estas fuentes no miden el uso presente ni documentan una intrusión concreta mediante IMAP COMPRESS.