Resumen

  • El certificado admitido en una conexión TLS puede convertirse en campos que hagan demasiado grande la petición enviada al servidor de origen. El proxy cambia el mensaje después de recibirlo.
  • El tamaño binario del certificado, los bytes de los campos textuales sin comprimir y el coste de transmisión o de una tabla dinámica no son la misma magnitud.
  • Reservar margen exige acordar qué añade el proxy y qué admite cada receptor. Ni comprimir mejor ni omitir silenciosamente información conserva por sí solo el contrato de la aplicación.

La petición que llega no es la que salió

Supongamos una petición que el cliente envía dentro del tamaño que su proxy está dispuesto a aceptar. La conexión exterior ha negociado TLS con autenticación mutua. El proxy prepara la petición para la aplicación y le incorpora el certificado del cliente. A partir de ese momento, la aplicación recibe un conjunto de campos mayor que el enviado originalmente.

Si ese conjunto rebasa su límite, no hace falta imaginar que haya fallado la negociación TLS. Han intervenido dos representaciones y dos decisiones de admisión. Esta situación es hipotética: no procede de un incidente observado ni de una prueba realizada para el artículo. Sirve para localizar la responsabilidad por el crecimiento, no para atribuir una avería a un producto.

RFC9440 describe los campos Client-Cert y Client-Cert-Chain para que un proxy inverso que termina TLS pueda trasladar a la aplicación información del certificado de la conexión original. Publicado en julio de 2023 como RFC Informational de la IETF, codifica una práctica con el objetivo de facilitar la interoperabilidad. No es una especificación de Internet Standards Track ni una certificación de capacidad operativa.

El certificado descrito pertenece al cliente que estableció la conexión mutuamente autenticada con el proxy de terminación. Los saltos interiores no convierten el campo en una descripción del certificado del último intermediario. La aplicación puede utilizar la información original sin que la conexión del cliente se prolongue físicamente hasta ella. Este artículo no vuelve a desarrollar toda la cuestión de confianza del trayecto; examina el espacio que consume ese traslado.

Un mensaje que cabe antes de ser enriquecido no tiene garantizado que quepa después. El cliente quizá no pueda reducir los datos añadidos por el proxy, y un origen que protege su capacidad no está obligado a admitirlos solo porque el intercambio exterior funcionó. La pregunta práctica es qué margen se reservó entre una etapa y la siguiente.

Una capacidad del analizador no fija la capacidad del servicio

Hay un detalle de Structured Fields que impide razonar solo a partir de un tamaño aparentemente respaldado por una especificación. RFC8941 y su sucesor RFC9651 exigen que los analizadores de Byte Sequences soporten al menos 16.384 octetos después de la decodificación binaria. Se trata de una exigencia del tipo de datos, no de una obligación de admitir cualquier petición HTTP completa que contenga un objeto de ese tamaño.

La petición incorpora nombres de campo, valores, sintaxis de listas y otros datos. Además, el certificado no se transmite como el objeto DER binario sin más. RFC9440 lo representa mediante base64 delimitado por dos puntos, sin saltos de línea ni espacios. Los bytes que aparecen en los campos textuales deben calcularse sobre esa representación.

Por tanto, copiar el mínimo del analizador a un ajuste de cabeceras mezclaría unidades. La capacidad de interpretar un valor después de decodificar su base64 no establece cuánto texto puede aceptar un servidor, ni cuántos campos pueden acompañarlo. Un servicio puede disponer del analizador requerido y aplicar una envolvente operativa menor a cierta petición sin que ambas afirmaciones sean contradictorias.

También se produce una confusión cuando se llama «decodificado» a dos resultados distintos. HPACK o QPACK reconstruyen nombres y valores textuales a partir de una representación comprimida. El valor del certificado sigue siendo base64 en ese resultado. Decodificar después ese base64 para obtener DER es otra operación. La sección de campos sin comprimir y el certificado binario no han pasado a tener el mismo tamaño.

Los costes de transmisión y estado añaden más diferencias. Una referencia a una entrada existente puede reducir lo enviado por la red, aunque el campo reconstruido continúe siendo grande. Una representación literal puede no crear una entrada retenida, pero el receptor sigue teniendo que procesar el campo. Hablar de un único «tamaño del certificado» oculta qué recurso se está protegiendo.

El acuerdo útil identifica la unidad y el punto de medida. El equipo que gestiona los certificados puede pensar en DER; el proxy, en valores serializados; el transporte, en bytes comprimidos; la aplicación, en toda la sección de campos. Todos pueden contar correctamente y, aun así, no haber acordado lo que la aplicación recibirá.

Los límites pertenecen al receptor que los aplica

RFC9110 no establece un máximo universal para una línea, un valor o una sección completa de campos. Reconoce límites elegidos por los receptores y exige una respuesta adecuada de clase 4xx cuando los campos de una petición superan lo que el servidor quiere procesar. Su advertencia sobre ignorarlos se refiere al aumento de la exposición al contrabando de peticiones. No autoriza a borrar información para considerar el problema resuelto.

HTTP/2 utiliza SETTINGS_MAX_HEADER_LIST_SIZE. Según RFC9113, ese valor orientativo se calcula con las longitudes no comprimidas de nombres y valores, más 32 octetos por línea de campo. El receptor puede aplicar a una petición concreta un límite menor que el anunciado. El valor inicial sin límite no demuestra que todos los componentes o aplicaciones acepten volúmenes ilimitados.

HTTP/3 emplea SETTINGS_MAX_FIELD_SECTION_SIZE, con el nombre propio de ese protocolo. RFC9114 también cuenta los nombres y valores sin comprimir, más 32 bytes por campo. El par que conoce ese parámetro debería evitar superarlo. Sin embargo, cada implementación del trayecto aplica sus restricciones por separado: una petición por debajo de un anuncio no tiene garantizada la aceptación por los demás participantes.

Estos límites no son límites del tamaño comprimido de una trama. Que un bloque resulte pequeño en el enlace no elimina el texto que el receptor reconstruye, ni impide que otro componente tenga una envolvente distinta. Tampoco corresponde sustituir el nombre del parámetro HTTP/2 por el de HTTP/3 como si ambos fueran una etiqueta genérica.

La consecuencia es importante para quienes interpretan un ajuste como una promesa. Un número anunciado es información útil sobre un extremo y una magnitud. No es una reserva irrevocable para cada ruta ni una afirmación de que todos los componentes intermedios están coordinados. La conformidad con una envolvente no prueba conformidad con las restantes.

El proxy tiene que reservar su propio añadido

La capacidad se vuelve una cuestión bilateral cuando el proxy transforma la petición. Si anuncia al cliente todo el espacio que le ofrece su origen, el cliente puede ocuparlo antes de la incorporación del certificado. El proxy habrá recibido un mensaje admisible y preparado otro que ya no lo sea. En esa situación ilustrativa, reproducir el mismo máximo a ambos lados no coordina los costes.

RFC9440 recomienda que los intermediarios capaces de anunciar el tamaño máximo aceptable tengan en cuenta los campos que añaden y comuniquen a sus clientes un valor suficientemente menor. No fija una cantidad que haya que restar en todas partes ni convierte esa recomendación en una nueva obligación universal. El margen depende de la transformación y del destino efectivos.

Una conversación operativa debería identificar qué se añade, cómo se cuenta y qué podría alterar el cálculo. Un cambio de cadena de validación puede modificar los campos sin que se rompa TLS. Otra ruta puede desembocar en un receptor con otra política. Más campos ordinarios pueden compartir el espacio inicialmente previsto. Nada de esto se presenta como un cambio observado en una infraestructura real.

El presupuesto también debe distinguir una estimación útil de una garantía. Haber preparado margen para cierto conjunto de información no demuestra que cualquier sustitución futura tenga el mismo tamaño. Los responsables locales necesitan conocer las condiciones de revisión del acuerdo, no solo una cifra que se conserva mientras cambia su significado.

La forma de la cadena también cuesta

Client-Cert contiene el certificado final y solo se utiliza en peticiones. Es un campo único: no puede convertirse en lista ni repetirse. Client-Cert-Chain, por su parte, es una lista opcional de Byte Sequences, mantiene el orden de certificados TLS y excluye el certificado ya enviado en Client-Cert. No debe aparecer si falta este último.

La opcionalidad permite elegir un modo de funcionamiento. No permite concluir que una aplicación dependiente de la cadena recibirá lo mismo si esta desaparece para ahorrar espacio. Una representación más corta puede haber cambiado el contenido que la aplicación necesita. El resultado de tamaño debe evaluarse junto con la semántica declarada, no como su sustituto.

RFC9440 permite omitir la raíz cuando se sabe que el origen destinatario posee el ancla de confianza omitida. Es una condición sobre el destinatario, no sobre la necesidad de ahorrar bytes. No es una regla general para retirar elementos esperados hasta que la petición quepa.

La lista de cadena puede repartirse en varias apariciones del campo y el RFC señala una posible ventaja de compresión. Pero el cómputo de líneas también añade nombres y costes fijos por cada aparición. Una decisión favorable para la reutilización de valores puede aumentar otro componente del presupuesto. La representación debe elegirse sabiendo qué contador decide la admisión.

Comprimir, retener y admitir son decisiones diferentes

RFC9440 plantea un caso específico: una conexión entre proxy y origen que comprime campos y multiplexa peticiones de distintos clientes. Los valores de certificados grandes y variables pueden reducir de forma importante la eficiencia de compresión. Es una consideración condicionada por la carga, no una medición de un proveedor ni una afirmación sobre todas las conexiones posibles.

El documento contempla que el origen aumente su tabla dinámica. También indica que, si el proxy considera insuficiente la tabla del origen, podría resultar beneficioso enviar la información siempre como literal en lugar de introducirla en la tabla. Una opción busca más espacio para reutilizar estado; la otra puede evitar entradas poco útiles para la carga existente. Ninguna viene acompañada de una ganancia universal garantizada.

En HPACK, RFC7541 cuenta una entrada con las longitudes de nombre y valor antes de aplicar Huffman, más 32 octetos. El protocolo fija la capacidad máxima permitida y el codificador puede utilizar menos. Es una contabilidad de estado de compresión. Aumentar ese techo no obliga a la aplicación a aceptar una sección de campos mayor.

QPACK también dispone de un límite de tabla controlado por el decodificador mediante SETTINGS_QPACK_MAX_TABLE_CAPACITY. RFC9204 impide las inserciones cuando el máximo es cero. Ese parámetro no es el límite de sección de campos de HTTP/3. El artículo no presupone que QPACK bloquee necesariamente las peticiones con certificados ni prescribe un ajuste común para todos los servicios.

La repetición importa. Muchos valores diferentes y un valor estable reutilizado ofrecen oportunidades distintas. Los responsables pueden ponderar memoria retenida y bytes enviados sin que ese cálculo decida cuánto mensaje quiere procesar una aplicación. El límite del receptor sigue siendo otro compromiso, incluso cuando una sola organización controla todos los componentes.

Hacer caber la petición no basta para conservarla

RFC6585 define 431 para un servidor que no quiere procesar cabeceras demasiado grandes, sea por el conjunto o por un campo individual. Permite volver a enviar la petición tras reducir los campos y recomienda señalar el campo responsable cuando corresponda. Pero ese código es opcional. El texto contempla que, bajo ataque, un servidor prefiera cerrar conexiones o actuar de otra forma; no existe una respuesta 431 garantizada.

La reducción puede requerir cooperación porque el cliente no controla todo lo incorporado en el siguiente salto. Repetir la misma petición no modifica la ocupación. Eliminar el certificado para pasar el límite podría cambiar la entrada de autenticación de la aplicación. «Más pequeño» no equivale automáticamente a «el mismo mensaje».

Una aplicación puede tener un arreglo válido sin esos campos, por ejemplo si utiliza otro mecanismo de autenticación. No se propone negar toda petición sin certificado. Se propone declarar ese arreglo de forma explícita y no dejar que una solución de capacidad lo invente accidentalmente. El límite técnico no tiene autoridad para redefinir por sí solo la autorización aplicativa.

La reanudación de sesión plantea otra continuidad que debe decidirse. Algunas implementaciones TLS no conservan la información del certificado al reanudar. RFC9440 recomienda a quienes no puedan proporcionar valores coherentes desactivar la reanudación para esas conexiones o no enviar desde el principio un campo que podría faltar más tarde. Son alternativas condicionales de diseño; no instrucciones para cambiar servicios actuales ni una conclusión sobre toda reanudación.

Las cachés de respuestas requieren además su propio tratamiento. Si Client-Cert selecciona una respuesta, RFC9440 exige que esta no pueda almacenarse o que su reutilización se limite al mismo valor mediante Vary: Client-Cert. Un proxy de terminación que encuentre campos de certificado en Vary debería cambiar su valor a * para impedir el almacenamiento por el agente de usuario. Las respuestas 431 no deben guardarse en caché. Nada de esto se consigue simplemente ampliando una tabla HPACK o QPACK.

La confianza del trayecto sigue siendo necesaria: el proxy debe impedir la inyección de esos campos y el servidor solo debe aceptarlos por el camino confiable previsto, protegido frente a observación o alteración indebida. Superar una prueba de tamaño no demuestra estas condiciones. El presupuesto se añade al contrato de despliegue; no sustituye su seguridad.

Fuentes y límites de la evidencia

Los ejemplos son hipotéticos y no ejecutados. El análisis utiliza especificaciones publicadas, no telemetría de producción. No identifica un incidente, un límite seguro universal, una configuración típica de proveedor, una mejora cuantificada ni una prueba negativa completada. Las implicaciones operativas son razonamiento editorial separado de las exigencias de cada documento.