Resumen

  • ALPN hizo que el cliente ofreciera identificadores de protocolo dentro de ClientHello y que el servidor eligiera uno de los valores comunes sin añadir otra ida y vuelta.
  • La lista del cliente expresa preferencias, pero no manda sobre la política del servidor. Si no existe intersección, la respuesta es la alerta fatal no_application_protocol, no una gramática predeterminada inventada.
  • La elección rige una conexión. Reanudar una sesión TLS no conserva la selección anterior, y seleccionar un protocolo no equivale a autenticar un origen ni a autorizar una operación.

El silencio compatible habría sido una mentira

Un cliente ofrece dos protocolos. El servidor no admite ninguno. Hay tres salidas imaginables: cerrar con una razón precisa, continuar sin decir qué hablará o elegir un tercer protocolo que el cliente nunca mencionó.

Las dos últimas parecen tolerantes sólo mientras no circulen datos. En cuanto llega el primer mensaje, cada extremo necesita saber qué delimitadores, marcos, estados y errores gobiernan sus bytes. TLS puede proteger la integridad del canal y aun así entregar fielmente un mensaje a un intérprete equivocado.

RFC 7301 escogió la primera salida. Si el servidor no soporta ningún identificador anunciado, debe enviar la alerta fatal no_application_protocol. El acuerdo inexistente queda registrado antes de que una aplicación actúe.

La negativa tiene una virtud histórica: no oculta el costo de retirar un protocolo antiguo. Una organización ve cuáles clientes dejaron de compartir un valor. Puede restaurar capacidad, corregir preferencias o aceptar la incompatibilidad. El fallback silencioso produciría una cifra de éxito más bonita y una frontera semántica imposible de auditar.

Un mismo puerto ya no nombraba una sola aplicación

Los puertos conocidos habían permitido inferir durante años qué protocolo encontraría un cliente. La concentración de aplicaciones dentro de TLS, y en particular sobre 443, volvió esa inferencia menos fiable. Era útil compartir acceso, certificados y equipos; no era aceptable pedir a cada servidor que adivinara el parser después de recibir datos cifrados.

Una negociación posterior a TLS podía resolverlo, pero agregaba latencia. ALPN reutilizó el handshake. El cliente incluyó su oferta en ClientHello; el servidor respondió dentro del mismo establecimiento. Así el primer byte de aplicación llegó a una conexión que ya poseía una gramática acordada.

RFC 8170 sitúa la decisión en la transición a HTTP/2. La variante protegida necesitaba negociar sin otra ida y vuelta y adoptó ALPN. La variante no cifrada intentó Upgrade. Con el tiempo, ALPN quedó identificado como el mecanismo principal para negociar versiones HTTP futuras.

Eso no convierte ALPN en una historia general de HTTP. Su aporte duradero es anterior a cualquier request: separar la posibilidad de compartir un puerto de la obligación de compartir una interpretación.

La primera preferencia del cliente no era una orden

La oferta ALPN es una secuencia de nombres opacos y no vacíos. El cliente los ordena de más a menos preferidos. Sería fácil implementar la respuesta tomando siempre el primer valor conocido. El estándar conserva, sin embargo, la política del servidor.

Se espera que el servidor tenga su propia lista y elija el valor que más prefiere entre los ofrecidos que también soporta. La autoridad se distribuye en dos pasos. El cliente delimita qué puede entender; el servidor decide qué servicio común quiere prestar. Ninguno obtiene permiso para añadir un valor por su cuenta.

La respuesta contiene una selección única. Ese valor es definitivo para la conexión. Si el servidor anuncia h2, no puede empezar a enviar HTTP/1.1 porque le resulte conveniente después. La negociación no describe todas sus capacidades; contrae un compromiso para este canal.

La telemetría debe respetar esa estructura. Saber que un cliente ofreció h2 no demuestra que el servidor lo prefiriera. Saber que una imagen de servidor soporta h2 no demuestra que la instancia que respondió lo tuviera habilitado. El hecho útil es la intersección concreta, la política aplicada y el valor devuelto.

El ticket no heredó esa decisión

TLS permite reanudar sesiones y usar tickets para reducir trabajo. ALPN podría haberse convertido en una propiedad de ese estado reanudable. RFC 7301 lo excluyó expresamente: el contenido anterior de la extensión es irrelevante y sólo cuentan los mensajes del nuevo handshake.

La regla admite cambios legítimos. El cliente puede retirar un protocolo vulnerable. El servidor puede preferir una versión nueva. El ticket puede llegar a otro nodo. Una política regional puede diferir. Obligar a reproducir la selección antigua convertiría una optimización criptográfica en un bloqueo de la aplicación.

También mejora el diagnóstico. Si una conexión fresca elige h2 y una reanudada elige http/1.1, la diferencia no prueba un error del ticket. Hace visible la política o capacidad encontrada por cada establecimiento. Hay que comparar ofertas, instancia y configuración, no suponer que “reanudado” significa “idéntico”.

El ticket demuestra, como máximo, lo que la política TLS acepta reutilizar. No autentica por sí solo un origen HTTP, no concede acceso a un recurso y no nombra el parser futuro.

TLS 1.3 protegió la respuesta, no borró la oferta

El diseño original colocaba la lista del cliente en ClientHello y la selección del servidor en ServerHello. RFC 7301 admitía esa visibilidad y advertía que un identificador sensible podía permitir perfiles. Los equipos de red podían observar el marcador cuando el puerto dejaba de identificar la aplicación.

En RFC 8446, TLS 1.3 lleva la respuesta ALPN del servidor en EncryptedExtensions. Es el primer mensaje del servidor cifrado con claves derivadas del secreto de tráfico del handshake. La lista del cliente continúa en ClientHello en el flujo normal.

Por eso una auditoría no debe declarar que ALPN es siempre visible ni que TLS 1.3 lo oculta por completo. Debe identificar versión, dirección y mensaje. El cambio protege la selección del servidor; no transforma retrospectivamente los ClientHello anteriores ni oculta automáticamente la oferta inicial.

HTTP/2 necesitó dos pruebas distintas

RFC 9113 define h2 para HTTP/2 sobre TLS y obliga a negociarlo mediante ALPN. h2c representa una modalidad sin TLS y está prohibido como selección ALPN en TLS.

Después del handshake, ambos extremos todavía envían un prefacio de conexión HTTP/2. El cliente abre con una secuencia deliberada y SETTINGS; el servidor abre con SETTINGS. El prefacio no repite inútilmente ALPN. Confirma que la aplicación que recibió el canal ejecuta la gramática elegida y establece sus parámetros iniciales.

Una selección h2 con prefacio inválido indica una falla posterior a la elección. Un prefacio correcto capturado sin el handshake no explica cómo se llegó a esa gramática. Operaciones necesita ambas capas para distinguir una preferencia mal configurada de un componente que selecciona HTTP/2 pero entrega el flujo al backend equivocado.

Los datos tempranos no podían cruzar un cambio de gramática

En una reanudación TLS 1.3, el cliente puede enviar 0-RTT bajo condiciones estrictas. Los datos salen antes de conocer toda la respuesta del nuevo handshake. Esa anticipación aumenta la importancia del nuevo ALPN.

RFC 8446 prohíbe que TLS retransmita automáticamente datos tempranos cuando la conexión terminada elige un protocolo ALPN diferente. Un mensaje construido para HTTP/2 no puede ser vuelto a emitir mecánicamente dentro de HTTP/1.1, aunque ambos usen el mismo endpoint y ticket.

Que el ALPN coincida tampoco resuelve el replay. La aplicación debe considerar idempotencia, credenciales, estado y si el primer intento pudo ejecutarse. La igualdad de protocolo sólo preserva el lenguaje; no prueba que repetir la frase sea seguro.

Esta distinción impide que una regla de capa inferior se arrogue una garantía de negocio. TLS sabe qué protocolo fue seleccionado. La aplicación sabe qué operación representa el contenido. Cada una debe negar únicamente lo que puede demostrar.

QUIC convirtió la falta de acuerdo en cierre de conexión

RFC 9001 usa TLS para asegurar QUIC y exige una negociación autenticada del protocolo de aplicación, normalmente ALPN. Si no se obtiene un protocolo, ambos extremos cierran inmediatamente con el error correspondiente a no_application_protocol.

Además, el protocolo de aplicación puede estar restringido a determinadas versiones QUIC. El servidor debe elegir un valor compatible con la versión que el cliente seleccionó, y el cliente también debe rechazar una combinación incompatible.

La intersección ya no es sólo cliente versus servidor. Incluye las capacidades del transporte concreto. Un nombre compartido no basta si la versión que lo portará no cumple su especificación. El cierre conserva esa incompatibilidad como un hecho explícito antes de que la aplicación acumule estado.

Las recomendaciones de RFC 9325 refuerzan el principio incluso fuera de QUIC: soportar ALPN y no aceptar una selección ajena a la oferta reduce el terreno para la confusión entre servicios TLS.

Un registro estabiliza bytes, no demuestra uso

El registro IANA de extensiones TLS e identificadores ALPN asigna el tipo de extensión 16 y mantiene nombres de protocolo bajo Expert Review. Incluye http/1.1, h2, h3 y la reserva h2c con su prohibición en negociaciones TLS.

La tabla permite que implementaciones independientes usen la misma cadena de octetos. No indica cuántos clientes la ofrecen, cuántos servidores la prefieren, qué porcentaje de tráfico la usa ni si el backend que la recibe está bien aislado.

El registro y el handshake forman dos clases de evidencia. El primero dice qué significa una cadena asignada. El segundo dice qué se ofreció y eligió en una conexión. Sólo la observación de la aplicación dice si los bytes posteriores siguieron la gramática y la política esperadas.

ALPN funcionó porque no intentó convertir una de esas pruebas en todas las demás. Una sesión podía reanudarse, una nueva conexión podía elegir de nuevo y una incompatibilidad podía terminar sin disfrazarse de éxito.

Fuentes

Estas fuentes fijan normas, recomendaciones y registros. No son un censo contemporáneo de implementación o tráfico.